A Content Management System is part of the basic equipment of many technical editorial departments. For the system to fulfill its purpose, the content must be documented, structured, and published in a meaningful way. One aspect plays a special role here: the correct modularisation of content. In the following article, we'll explain what exactly this term means and what's important when it comes to practical implementation.
More product variants, more languages, tight deadlines:
The increasing requirements in technical documentation creation demand a high output from technical editors. The right content management is a crucial success factor here. Essentially, this means that the content in the system should be organised in such a way that it can be reused as efficiently as possible. The prerequisite for this is a sensible modularisation of the content.
Individual content modules instead of one large continuous document - the Content Management System is usually modular. The modules are information components such as sub-chapters, paragraphs, words, or images. Depending on the target audience, product variant, or media format, the individual modules can be combined to create customised information products. A key advantage of modularisation is that you can reuse content that has already been created in other documents by simply referencing it. This makes it very easy to incorporate technical changes into documentation without generating redundancies. For example, if the technical value of a component changes, you only need to adapt the corresponding module.
The change is now automatically adopted in all places where a link to the original module has been created. This procedure not only reduces the creation effort, but also increases the security of your processes and the quality of your content.
Modules and topics
This modular approach is particularly effective when using so-called topics. These are modules that deal with exactly one topic and are self-contained, in terms of content. Topics fulfill the specific information needs that users have in a certain situation (e.g. when an error message appears in software). Because topics are independent of each other, they can be easily combined and reused in different contexts. They are often used in software documentation (e.g. in the form of Online Help).
Modules are ideal for neatly documenting different variants of a product, as the following example demonstrates: A robot manufacturer sells its new 6-axis robot in three different sizes. Instead of creating separate instructions for each of the three variants, the technical editor documents all content in a so-called master document. Modules with size-specific information - for example on assembly or the danger area - are provided with a filter in the CMS. When publishing instructions, the technical editor only needs to select the filter with the desired robot size to publish the correct document.
Example of filters in a CMS
The master document principle is just one of many ways of mapping content variants in the Content Management System. How exactly the content is structured and managed in the system depends largely on the information model used. This model determines the specific rules according to which the modules are created and classified. Some of the best-known standards for technical documentation are:
When it comes to modularisation, we're often asked: How large should the modules of a manual ideally be? The answer depends on the product variants that need to be described. Other important factors are the scope and content structure of the documentation. In short, finding the right modularisation concept is a very individual task.
Basically, however, you can remember the following context: If you divide your content into many small modules, you'll be able to reuse them well in different projects. However, you should allow for more effort and time for creating and managing the modules.
With larger modules, this effort is reduced, but there is a risk that the modules contain project-specific content and therefore can't be reused in so many ways.
As you can see, it takes know-how and technical editorial experience to find the right balance here.
Long-living products with a large number of variants that are constantly being expanded are particularly worthwhile for modularised documentation creation. But even with a manageable number of products and versions, it makes sense to consider a suitable modularisation concept. In contrast, individual bespoke products – e.g. in special machine construction – are less suitable for a modular approach. Here, it may be more financially prudent to create the instructions in a single large document and not waste time unnecessarily managing modules that can't be reused anyway.
Standardisation is the be-all and end-all in technical documentation. When it comes to modularisation, this means:
Modules of the same type – e.g. safety instructions or instructions for action – should be uniformly structured and formulated. This increases the quality of your technical documentation and ensures that you can use modules in a variety of ways.
It's worth taking a close look at linguistic subtleties in particular, as there is often great potential for improvement here. In the following example, it's a good idea to replace the number of screws with the neutral expression “all screws”. This allows the text to be reused for other product variants, if necessary.
Neutral formulations can increase the reuse of modules.
It's important to note that standardisation shouldn't be an end in itself, but should create real advantages in the creation of documentation. Also make sure that no important information is lost when standardising formulations. In case of doubt, the individual takes precedence over the standard.
Faster and better results with less effort: if you modularise your content correctly, you can fully exploit the potential of your CMS. Developing a suitable modularisation concept requires foresight and a strategic approach.
Do you have any questions about the modularisation of technical documentation or need specific support? Feel free to contact me and we'll discuss the individual situation of your technical authoring team together.