English

Is there such a thing as legally-reliable technical documentation?

A realistic assessment from the working life of a project manager.

CREATE
Is there such a thing as legally-reliable technical documentation?

Technical documentation has two objectives. On the one hand, it should inform users so they can perform their tasks as efficiently as possible. On the other, manufacturers of technical products want to protect themselves with user documentation in order to avoid being sued for damages if a user behaves incorrectly. So the aim is to create “legally-reliable” technical documentation.

Technical documentation cannot provide true legal certainty. However, it can considerably reduce the risk to the manufacturer by complying with the requirements specified by 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:

  • Machinery Directive 2006/42/EC       
  • Low Voltage Directive 2014/35/EU     
  • Pressure Equipment Directive 2014/68/EU
  • Directive on equipment for potentially explosive atmospheres (ATEX) 2014/34/EU      
  • Lifts Directive 2014/33/EU      
  • Medical Devices Directive 93/42/EEC

These directives contain numerous detailed rules regarding user information. In addition, these rules are further fleshed out and defined 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. Examples include:

  • DIN EN 82079-1 Preparation of Instructions For Use – Structuring, content and presentation
  • DIN EN ISO 12100 Safety of machinery
  • DIN EN ISO 17100 Translation Services – Requirements for translation services
  • ANSI Z535.6 Product Safety Information in Product Manuals, Instructions, and Other Collateral Materials, relevant for the USA

As a project manager I have to do justice to the needs and many requirements of our customers and prepare editors for their work as effectively as possible. Editors are the ones who have to record and implement all the relevant requirements. Here it can be helpful to consult the checklist used for the documentation check, which is actually designed to assess our customers’ user information. It lists the fundamental requirements for user information, all sorted by topic. An experienced editor will of course know all these requirements off by heart.

When it comes to the actual implementation, the company has plenty of templates and standards that can help. As every product is different, we need to develop an individual standard for the customer or product on the basis of these standards. In new projects, we also need to read up on the product standards and adapt the sometimes very precise requirements when implementing them in the user information.

The risk assessment, which is created either by our customers’ design departments or by our colleagues within the CE team, makes sure 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-reliable 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 what is even more important is that it provides information to the user. And that is the actual skill in our job: “How can I combine a focus on the user and a need for legal certainty, which seem so different at first glance?”

There is no general recipe – but maybe that is the secret of really excellent technical editors.

Martin Kleingrothe
Author:
Blog post Martin Kleingrothe