The final version of IEC/IEEE 82079-1, Edition 2 has already been available in English and French for almost a month now. Over the past few days, I’ve revised the seminar materials for a kothes academy seminar and have taken this as an opportunity to read a bit more, and at the same time take a step back. I was particularly interested in one question during my reading:
Does IEC/IEEE 82079-1:2019 offer any added value for routine technical editorial work?
First of all: The standard doesn’t completely reinvent the wheel, but it can be made to spin much better if the standard requirements are implemented in everyday work. The Technical Editorial department can make a small – but nevertheless important – contribution to this.
In addition to information products, the standard also considers processes in information management and the actors involved in the Technical Editing department. The fact that an information product is presented as the result of a targeted and planned process illustrates a fact. In my experience, many companies may not be fully aware of this fact: the finished information product is only the proverbial tip of the iceberg.
If this information product is to fulfil its task, which I will discuss later, documentation processes must be interwoven with many other processes and areas of responsibility within a company, which is quite clearly addressed by the standard. Documentation must become part of the product development process. In addition to technical expertise, other business areas must also contribute content such as design drawings or technical data, knowledge of markets or target audiences and, in more complex configurations, even legal advice. Technical expertise alone must be available before, sometimes during and even after content creation. This is because the Technical Editorial department needs information at the very beginning, will have questions during the authoring process, and it will require feedback as to whether the information product correctly portrays the technical facts. If changes are made to the product, all contact individuals must be available again, depending on the severity of the change.
Division of labour in the Technical Editing department
It also becomes clear that professionalisation in technical editing is indispensable. The standard lists the large number of requirements for the Technical Editorial department and emphasises that different tasks and responsibilities must also be distributed within the Technical Editorial department. What’s taken for granted in other areas of the company is sometimes questioned in technical editing: different requirements require different qualifications. It’s likely that Technical Draughtspeople at a mechanical engineering company will not select the materials or specify their own dimensions for a component. "Simple" engineers in the Design department will rarely determine the strategic direction of a modular product system. Of course, in small companies, the tasks mentioned can sometimes be performed by a single person. This may also be the case in the Technical Editing department, which is explicitly mentioned in the standard. My personal impression is that the one-person solution is chosen much more frequently than might actually be appropriate.
Within the context of the allocation of tasks, the standard requires that the capacities, skills and knowledge of the assigned personnel be appropriate to existing tasks. For many medium-sized companies, these requirements will present a great challenge. Technical Editorial departments often don’t sufficiently fill the level of (strategic) planning and conception or the level of actual content creation. This can be due to a lack of specialist expertise or simply to a lack of time and personnel.
Let's assume that a company decides to adapt its processes in a more documentation-friendly way, in order to provide sufficient capacities, and thus to create conditions for designing information products and populating them with content. Can the standard help to create good and meaningful information products? I think that yes, it can.
Target audience, usage situation and concrete implementation
An incredibly important step for the creators of information products, and in particular user information, is the realisation that the information should help real people with their tasks. The standard promotes this recognition by making it clear that, in addition to the target audience(s), the usage situation and objectives of the individual(s) involved must also be taken into account. Only if I give an appropriate level of thought to the characteristics, knowledge and expectations of my target audience can I decide what I want to focus on at all, what depth of information I provide and how I instruct. I can define how I formulate and illustrate from entire information products, down to the smallest action steps in a meaningful way. The characteristics of the target audience and the usage situations should continue to influence the distribution of content among different information products. This also includes the choice of appropriate output media: usage information can be much more than just printed instructions.
After it’s become clear what significance the reader has, one could justifiably ask: But how do I actually do that now?
Of course, the standard provides no guidance on individual cases, but there are certainly solutions available. First of all, the definitions of terms can help to classify facts. It should be no secret that usage information doesn’t only consist of instructions. It’s less obvious that the customer doesn’t necessarily have to be the target audience of the usage information. I also find the distinction between safety and warning notices described above quite understandable and also easy to implement in everyday life.
The standard also mentions some principles on how requirements for usage information can be met. To internalise these principles and apply them in everyday life can, in many situations, facilitate decisions in the technical authoring process.
Anyone who still wishes to have clear and unambiguous specifications will be best served by the standard with nominal values for typography, which, however, should not replace the target audience analysis with respect to readability.
Finally, approaches are described on how to assess the quality of the information created and the processes chosen.
Is there added value?
My conclusion to the question posed at the beginning is quite positive. I’m convinced that the requirements, recommendations and clarifications of the standard provide you with approaches that can be implemented in everyday work. Depending on the degree and quality of implementation, this will most likely contribute to better information on use, and thus lead to less frustration.
Unfortunately, in many points that I personally consider very important, the standard is too vague and a "should" is often interpreted by those responsible as "do not have to". Whether (and to what extent) the implementation will take place in Technical Editorial departments will probably also depend on whether the standard is harmonised.
