Single sourcing is an approach to technical writing that can help you produce documentation faster without sacrificing quality.
The secret to this approach is making content reusable by writing it just once and saving it in a single information source from where it can be reproduced according to your needs.
In this article, we’re bringing you an overview of the single sourcing method and discussing its basic principles, as well as the many benefits writers, editors, and translators stand to gain once they start using it in their work.
But first, what is single sourcing anyway?
What Is Single Sourcing
One of the biggest challenges technical writers face is having to produce large amounts of documentation within often very tight deadlines.
A lot of that documentation is repetitive and references the same set of information over and over again, so writing it manually is rather inefficient and, at times, even frustrating.
Fortunately, there is a smarter way of creating documentation. It involves writing pieces of content in one place (a single source) and then reusing that content across different contexts and in different formats.
This approach to documentation is called single sourcing.
With single sourcing, technical writers are able to “write once, publish everywhere” because pieces of information are treated as building blocks that can be fitted into different documents to produce meaningful content for end-users.
Single sourcing is a documentation technique that primarily focuses on helping writers, editors, and translators do their jobs more efficiently without sacrificing any quality for end-users.
How does it do that?
Well, it reduces the workload of technical writers by making content reusable, which means that it also reduces the amount of editing and document maintenance editors need to do.
Similarly, translators have an easier job because they have a unified source of materials for translation, so they don’t have to worry about discrepancies popping up during the translation process.
Single sourcing is a win-win situation for everyone involved in the documentation process. In the following section, we’ll see what its practical applications are.
When Is Single Sourcing Used
Single sourcing is particularly useful to organizations that produce massive amounts of documentation or have a large line of products that are similar to each other.
These kinds of projects usually need to repeat the same information in different places within the same knowledge base (or a printed user manual if the product in question is hardware.)
With a single sourcing approach, technical writers are able to write the information once, save it to a single space, and then reuse it whenever they need to.
For example, let’s imagine a software product that has usage instructions for novice users, advanced users, and developers.
Each of these audiences would have its own set of documentation needs, but the information would overlap in the definitions, procedural steps, and warnings that are the same for all users.
Those overlapping sections can be turned into blocks of information that are simply inserted into the documents instead of written out or copied and pasted every time.
The other use for single sourcing documentation that we mentioned is creating documentation for a series of products that are very similar to each other.
So let’s see a basic example with washing machines:
All of these machines work in roughly the same way and can be operated using one set of instructions.
However, each one of them is different because the number of features it has differs compared to the others (for instance, it has the EcoSilence Drive or the AutoStain feature).
The single sourcing method to create documentation for these washing machines would be to write a basic set of instructions that’s applicable to all versions of the product (the single source) and then customize that set with the variables that differentiate the machines.
As you can see, single sourcing in technical documentation is widely used in large-scale documentation efforts.
However, startups and SaaS companies can also utilize it, especially if they plan on expanding their technical documentation.
That being said, single sourcing is an extremely efficient way to write documentation, so it’s a good idea to learn its principles and apply them in your own technical writing.
Principles of Single Sourcing in Technical Writing
In the following subsections, we’ll talk about the five basic principles of single sourcing in technical writing.
Even if you’re working on projects that aren’t perfectly suited for single sourcing, these principles should give you a couple of ideas on advancing your technical writing practices and making them more efficient.
Let’s dive right in.
Reuse Principle
According to this principle, every bit of information that can be reused multiple times across multiple contexts is an opportunity to save time and effort.
To reuse content, simply create a space where you can collect bits of information that need to be included in multiple documents across your knowledge base.
Technology can help you with that.
For example, if you’re using advanced documentation software, such as Archbee, you can create and save “content snippets” that can be easily inserted into the document.
Here’s how the process works.
Source: Archbee on YouTube
The neat thing about this is that by changing the content snippet, technical writers can change the information across every document that holds that snippet.
That’s infinitely more efficient than going into every document separately and updating it by hand.
By reusing prewritten snippets of content, technical writers are able to write more efficiently and maintain the accuracy of their information, which is what single sourcing is all about.
Simplicity Principle
In order to make your content reusable, you’re going to need to boil it down to its simplest form because that’s the only way you’ll be able to use it in different documents without changing a single word.
This minimalist approach to documentation can be achieved by removing the elements that don’t help users achieve their goals, such as storytelling or embellishments, and just sticking to basic instructions.
For example, take a look at this Sign-In procedure for an IBM product:
As you can see, this is a bare-bones way to write out the procedure.
There are no descriptions of the environment from which to sign in (the sign-in page) or an explanation of what happens if the sign-in is successful, for example.
That way, this same procedure can be transplanted into any other document about any other IBM product that uses the same procedure and still work.
Simplifying your instructions won’t take away from the user experience, but it will help you make every piece of content more reusable because it will fit into a greater number of contexts.
Single Purpose Principle
According to this rule, every block of content you create should have just one, single use because that makes the information much easier to fit into multiple contexts.
For example, if you write a piece of content that’s meant to help users with a known issue, then that piece of content can be reused every time you explain to users how to tackle that specific problem, across different products or different versions of your product.
However, if that same piece of content contains, for instance, an installation guide, it might not be reusable in contexts where the aforementioned issue is present, but the installation procedure is different.
You’ll see this principle in all sorts of technical documentation. For instance, here it is in an article about connectivity issues in Slack.
This article contains instructions for managing connection issues specifically written for network administrators.
It doesn’t contain a list of common connection issues and their explanations because that would be a second purpose for the article (providing a rundown of connection issues and instructing the user on how to manage them).
However, since those two purposes are connected, a link is given that takes the user to another article about common connection issues, should the user need it.
By focusing on just one purpose per article, writers are able to safely reuse their instructions without worrying that a part of the article will give the reader the wrong information.
Users are well served as well because they’re getting exactly the information they were looking for and nothing else.
Generalization Principle
If you’re going to reuse a single piece of content over and over again, it would be a good idea to make it as generic as possible while keeping the information valid and useful to anyone accessing the content.
In technical documentation, this usually means omitting all specific information, such as product names and version numbers, from the documentation so that the information from the document can be applied to multiple products or product versions.
For example, IBM has different products that can be installed using IBM’s installation manager. So instead of writing out the instructions for every specific product, a generic installation guide was created and then inserted into the documentation for every product it applies to.
As you can see, there’s no mention of the name or version number for the product.
It’s referenced generically, only as “the product,” which makes it easier for the technical writing team to insert this part of the text into the instructions for every product that follows the same procedure.
Dependency Principle
In a previous section, we talked about how every piece of content should have only one purpose to make it easier to reuse.
We said that instead of packing too much information into one article, it might be a better idea to provide a link to a second article with more information.
This is a good practice to follow, but a word of caution is in order.
Interlinking pieces of information within a knowledge base creates relations of dependency between those articles that may make the content less reusable.
Why?
Well, because if understanding the information in the article depends on the reader following the link, then that link to a second article needs to be present every time the content piece is reused.
If the link is omitted, the article might not make sense anymore.
Therefore, it’s relatively safe to interlink articles within a single knowledge base for a software product, like in Mailchimp’s example below:
However, if you need to reproduce your knowledge base in a different format (a printed manual, perhaps), then it might be impossible to keep those links in working order.
And if understanding the content depends on the links working, you might not be able to reuse your content but will have to rebuild it from scratch.
So, as a rule of thumb, it’s a good idea to use links in your knowledge articles sparingly—unless you’re sure you’ll be able to keep those links intact every time you reuse the content.
Benefits of Single Sourcing
Making the shift to single sourcing in your technical writing practices is definitely not without its challenges.
This approach to documentation takes practice and is not as simple as sitting down and just writing out everything you know about a feature or issue of the product.
That being said, single sourcing comes with great benefits that can be very valuable to your writers and the company as a whole.
Let’s see what they are.
Improved Consistency
It only stands to reason that if you keep reusing a block of prewritten content instead of writing the information from scratch every time, your documentation will be more consistent.
But you might be wondering what the value is in more consistent documentation.
More consistency in documentation means that your users will be much less likely to get confused when reading your documentation and will have a much easier job spotting patterns and understanding how one piece of information fits in with everything else they know about the product.
A good example of this can be found in naming conventions.
Since the same concept can be referred to in several different terms, users can get confused and fail to realize they are reading about a single concept that is named differently in different parts of the knowledge base.
In fact, technical writers often have to use style guides and technical glossaries to prevent this from happening:
However, if the concept is only named once while writing the information block and then reused throughout the knowledge base, inconsistencies like this are highly unlikely to happen.
Therefore, we can conclude that consistency brings order to your documentation and improves the overall user experience.
The best part is that improved consistency is an unintended consequence of single sourcing which helps users as much as it does writers.
Reduced Repetition
As we said before, the work of a technical writer includes a lot of repetition.
Key concepts and common instructions need to be written out again and again because technical documentation is never read in a linear way.
Instead, users will only access the documents pertinent to their immediate needs, meaning they need every bit of information that will help them achieve their goal, regardless of the fact that that same information is also present elsewhere.
For technical writers, this can be somewhat frustrating and time-consuming because it means they need to repeat themselves endlessly.
However, within the single sourcing approach, writers are able to write down the necessary information just once and save it in a single place.
Then, every time they need to reproduce this information, they can just work the information block into the document and carry on with their work without having to input the same information over and over again.
This is of great help to the writer whose work is made much more engaging and less tedious, but it’s also good for the project because documentation is written faster, and it’s always accurate because it comes from a single, reliable source.
Flexible Formatting
In single-sourced documentation, knowledge is boiled down to the basics and recorded in its simplest form.
Another advantage of this simplicity of expression is that the information is easily reproduced in different formats to provide access to different audiences who will be consuming your documentation.
This benefit is especially important to companies whose customers need access to documentation on the go or offline.
For example, let’s imagine a product that has an online knowledge base that serves the users of the product while they are at their desks. Like this online help tutorial from Epson:
But what if those customers needed to be supported when they weren’t at their desks and didn't have immediate access to their computers?
In those cases, you would need to provide the same information in a different format they could take with them, such as a printed manual or a PDF file they can save to their mobile device.
If you have a single source of information that’s simply formatted, you won’t have any problems adapting that information so that it can be exported into other formats, such as Docx, PDF, HTML, and so on.
This flexibility will help you to quickly and easily create knowledge bases, manuals, and user guides in as many formats as you need to completely satisfy your user base.
Reliable Translation
In this discussion about the benefits of single sourcing documentation, we mentioned that having just one source of information can greatly improve the consistency of the knowledge base as a whole.
This benefit also extends into information translation and makes it much easier to do.
It’s easy to see why.
If your translators are using a single source of truth in their work, that means that their translations will remain consistent and closely tied to the original.
To put it differently, if translators need to translate just one block of information instead of multiple instances and versions of that block across the documents, the variations between the original and the translations will be kept under control, and you’ll produce reliable translations that are as close to the original as possible.
Translating technical documentation is impossible to do without at least some variation from the original.
However, in a single sourcing environment, these discrepancies are kept under control and won’t endanger the original information presented in the documentation.
Conclusion
In conclusion, it’s clear that single sourcing in technical documentation presents writers, editors, and translators with a fascinating set of challenges—while also offering some amazing benefits.
The five principles of single sourcing we described here are not easy to implement, but they should help you make large strides in making your technical writing efforts more efficient and the resulting documentation more consistent.
Single sourcing in technical writing is definitely worth considering, especially if you have a lot of documentation to write and want to keep it as accurate and user-friendly as possible.
