Technical documentation basically has two goals: firstly, it must provide users with the information they need to perform their tasks safely and efficiently.Secondly, this user information needs to safeguard product manufacturers against being sued for damages in the event of human error on the part of the user. The goal is then to provide “legally watertight” technical documentation.
Technical documentation cannot provide absolute legal certainty. However, it can help to significantly reduce the risk to the manufacturer by complying with the requirements set out in laws, directives and technical standards.
European product safety directives play an important role here. They must be translated into national law by the individual members of the EU and are often used even outside the EU as a guide when product safety requirements are regulated.
The following directives are relevant to technical documentation:
These guidelines contain numerous detailed rules for user information. In addition, these regulations are further elaborated and specified in the standards harmonised under the Directives.
Next to product-specific type C standards that sometimes contain very precise requirements for individual product types, there are standards that apply to technical documentation overall. These include, for example:
In my daily work as a Project Leader, it is my job to take into account the needs of customers and the regulatory requirements and to make sure that editors are properly prepared to fulfil their work. After all, they have to record and implement all the relevant requirements. The documentation check’s checklist can help here, even though it is actually designed to evaluate our customers’ user information. It lists the basic requirements for user information sorted by topic. Experienced editors will of course know the requirements by heart.
Numerous templates and standards that exist in-house help with the actual specific implementation. Since every product is different, it is important to build an individual standard for the customer or the product on the basis of these standards. For new projects, we also need to read up on the product standards and adapt the sometimes very specific requirements when implementing them in the user information.
The risk assessment, which is carried out either by our customers’ design departments or by our own CE team, helps to ensure that safety aspects are not neglected. That is because a risk assessment supplies plenty of useful information for the user information – as well as residual risks, it contains information about maintenance tasks, inspections, personnel qualifications and much more.
In the end, all these ingredients ensure that the editor can deliver the user information with a clear conscience – it may not be a legally watertight document, but it is certainly one that meets the relevant requirements specified in laws, directives and standards and that reduces the customer’s liability risk.
But much more importantly, the user information needs to serve the needs of users. And this is where the real skill comes into our job: “How can I combine a focus on the user with the need for legal certainty – seemingly such disparate requirements at first glance?”
There is no one-size-fits-all solution – but maybe that is the secret of really excellent technical editors.