Duplicated content is expensive. Where would you like to apply reuse? How much structure do you need to make this work? What breaks when you apply reuse to your documentation processes but continue to work as before in your content creation?
The real cost of duplicated content is in review, not authoring
A safety warning is only a few hundred words and can be written in a few minutes. However, after writing, it needs to be reviewed by 2 people. This review needs to take place in 2 different documents. The subject matter experts who write the warning can be different from the ones who review it. After that, it also needs to be translated and approved by 2 people. On a regulated product, every instance of duplicated content is a separate audit surface and also a separate area for divergence from original content.
The cost differential therefore increases in direct proportion to the number of times a given paragraph of content is used in the set of manuals under consideration. That is to say, a single paragraph of content used in 3 manuals will cost approximately 3 times the sum of the costs to maintain that same paragraph of content as a single use throughout the lifecycle of said product had it been written in the first place. When translation is involved, the differential cost will naturally increase because translation costs on a per-word basis and every duplicate string of content (used in different manual(s), translated into different languages, etc.) is charged per word.
Where divergence actually starts
A simple copied procedure can diverge from the original after a while. Many people are not even aware they copied in the first place. After several months it is impossible to determine which version is correct. The above problems with copied information are eliminated by design when information is reused.
Structured authoring is the precondition, not the outcome
So content with clear boundaries (e.g. Background information + procedures + troubleshooting) can be re-used in full. Content with mixed elements (e.g. Background information + procedures) cannot be re-used in full in other publications.
A good unit of reuse is copyable material, i.e. Material that an author can simply copy and paste into another document without having to alter it to fit in with the surrounding content. To be copyable in this sense, such material will typically have been written as completely self-contained standalone material. It is a skill that most authors learn within a few months, and will need to be checked against explicit review criteria as opposed to being left to the style guide as a footnote.
Granularity decisions that matter
- Topic level. The default unit. Works well for procedures, reference tables, and concept explanations that stand alone.
- Element level. Individual warnings, notes, or paragraphs pulled by reference. Useful for compliance text, but creates fragile dependencies if overused.
- Variable level. Product names, version numbers, part codes. Cheap to implement and often the highest immediate return.
- Map or assembly level. Entire chapter structures shared across product families, with conditional filtering for variants.
Variables or even entire topics like product descriptions are excellent candidates for a first start into reuse. Measure and then refine.
Choosing a reuse mechanism
There are different techniques to solve different problems on your content and most larger teams are using several of them in parallel.
| Mechanism | Best suited to | Main trade-off |
| Direct topic reference | Identical procedures across product lines | No tolerance for variation; forces exact match |
| Conditional filtering | Variants sharing 80 percent of content | Source becomes hard to read as conditions multiply |
| Content references (conref) | Regulatory text, standard warnings | Broken references surface only at build time |
| Variables and key references | Names, numbers, URLs, branding | Low risk, limited savings on its own |
| Branching and merging | Long-lived forks, such as legacy versions | Merge conflicts and manual reconciliation |
Repository implications
Support follow up work such as to display “where-used” for a single component. Before committing to a repository, it is worth weighing the benefits of a component content management system, which is usually far better equipped to support such follow up work than a simple file repository. In addition, for smaller teams (up to a few hundred topics) Git in combination with a build pipeline may also be sufficient to support “where-used” for components.
Changing the workflow, not just the format
K5, Describe changes in work of authors using re-use. The work of authors using re-use will increase for searching and entering metadata.
- Require a reuse check before any new topic is created, backed by a searchable component inventory.
- Assign ownership of shared components to a named role, so changes have a single approver.
- Review shared components once, at the source, rather than in every assembled deliverable.
- Run reference integrity checks in the build, failing the publication rather than shipping a gap.
Measuring whether it worked
Track % reuse for specific deliverables, average # of words in translation for newly written content, and average time to publish newly updated content. This will tell you if you have shifted costs from authoring to reviewing or if you’ve just moved the problem.
