ABOUT US

SourceOne is passionate about producing effective product and service documentation using plain language, efficient task and workflow automation, and using best practice single-source documentation techniques and tools.

We have implemented and honed our content creation and control techniques since the late 1990's with experience in diverse organisations such as New Zealand central government agencies and Defence, various crown entities, New Zealand software companies and larger internationals, and community-driven organisations such as body corporates and charitable trusts including Māori-led organisations and marae.

We encourage Te Tiriti o Waitangi principles of mahi tahi/partnership, participation and protection, and support the nurturing of te reo Māori as well as tailoring plain language content free of cliché and idioms able to be efficiently translated to diverse audience requirements.

What we do differently

Most organisations are unaware of modern single-source component content creation tools and techniques and instead rely on legacy document-centric solutions such as Microsoft Office. These older tools and techniques result in duplication or conflicting information, inefficient maintenance, poor content workflow, and little to no automation or ability to easily offer translations of content to multiple languages. Organisations will find it difficult to keep their content up-to-date, cannot innovate in their content, and do not have flexibility to publish tailored content to different formats or diverse audiences.

Research by Gartner, Aberdeen Group, and others, have shown that organisations with documentation pressures perform better when they use plain language techniques and implement single-source, reusable component content tools. Examples of research whitepapers are available upon request.

TIP: For more background into various New Zealand Plain Language efforts, see Commerce Commission guidance about contracts using plain language, NZ Government draft legislation and guidelines for digital services, and the fantastic Plain English Awards.

In addition, we have frequently seen organisations fail to lead by example where everyone's roles should be required to produce plain language actionable information, do not use task and workflow tools (or have leveraged them poorly) and do not effectively manage staff who should be doing these things.

We identify content-creation blockers and recommend change, such as strongly urging:

A culture of everyone playing their part in clearly documenting their roles and actions they require of others, the CEO, product owners/CTO, designers, developers to testers all need to produce clear actionable information in their roles. This can include business/stakeholder "user story" requirements for any product or service's features or changes, as well as the resulting development and testing notes. Without this, documentation efforts will always be stymied (see GIGO) and the product or service itself will likely be poorly received by users.
Adequate management of staff key performance indicators and internal service level expectations (including that all staff provide clear information as described), which is essential to identify and address bottlenecks and performance issues affecting information flow through to documentation staff.
Automation of JIRA (or similar task management tools) to create separate development sub-tasks assigned to relevant testing and documentation personnel to ensure that all changes are not missed, and to automatically raise the priority of those tasks when they are ready to be worked on.
Also enforcing task management required fields (and placeholder "prompting" content) to ensure that ALL task creators provide enough detail for developers, testers and documentation staff to work to efficiently. There should always be clear and authoritative user requirements (and acceptance criteria) for changes and new features that can be referred back to. Too often these are only communicated verbally with one or two staff, which are then often misremembered, or are never written down and are lost forever due to staff turnover.
Linking task management tools to source control so that developer commits and comments are also automatically visible in the originating issue, which can provide useful context for development, testing, and documentation staff alike.
Ensuring externally published documentation content is also made available internally for staff to encourages internal review and feedback (for example using SharePoint, Confluence, or similar Wiki tools).
Making REST API content "self documenting" using tools such as OpenAPI annotations throughout the developer's source code to programmatically generate accurate API documentation. Documentation staff can maintain this single version of truth and ensure plain language is used.

Implementing documentation best practices is what we do.

The documentation processes, tools and single-source techniques that we implement are tailored to the organisation's requirements.

We write authoritative component content that is reused (not duplicated and requiring separate maintenance) for an organisation's many publishing outputs such as technical documentation, user guides, training and online help and expanded/re-branded content for partners.

We deliver content and changes more rapidly with fewer resources by removing stale and duplicated content and implementing automation to the publication processes.

These documentation techniques are also designed to be highly robust in the face of traditional infrastructure outages.

Making content creators more agile is what we do.

By implementing plain language writing, using a company style guide, and a modern single-source component authoring framework with automation as outlined previously, organisations can sustainably inform their customers clearly, concisely, and on time, and be able to manage their content in multiple languages efficiently.

What we do not do

SourceOne staff are not marketing/legal/patent copywriters, graphic designers, end-user trainers, video or animation creators or dedicated testers.

These roles are outside the scope of the SourceOne services offered, although we may be comfortable with minor examples of these types of tasks on a case-by-case basis. We consider these to be specialist skills that should have dedicated staff focused in those careers, even if only employed in part-time roles. For example, we encourage use of local marketing and design schools or tertiary institutions that are great resources for finding suitable up-and-coming personnel who deserve their first start in the New Zealand workplace. We are keen to see organisations hire and grow new local talent to succeed in these kinds of roles.

Note: Our documentation personnel will of course help to identify bugs in products and services or inefficiencies in workflow processes, and report these to the client's testers, developers and/or management. This incidental testing by SourceOne should only ever be seen as the last line of defence, and not a substitute for rigorous prior testing by dedicated personnel using professional tools and automated testing techniques.

Estimates for any scope of work are based on the expectation that client products and services are relatively stable, have been thoroughly tested, and that effective workflow is in place.

Next Steps