I'm not particularly proud of the first two years of my professional career. I don't remember much from that time, but what I do remember is a certain uncertainty about what was required of me in technical documentation projects and a latent dissatisfaction with my own results, which didn't just go away, due to the lack of feedback.
This changed abruptly when the objects to be described became smaller and the target audiences more real and thus more tangible. Suddenly I knew which questions to ask, what was relevant, and what wasn't. The insecurity that had previously held me back vanished, and even when the products to be described got larger again, I went to work much more exhilarated than before, driven by the realisation that I was not writing for our (feedback-weary) clients, but that their customers could (potentially) depend on me (to be in top form) at any time.
Only later did I realise that the decisive moment in my career as a technical editor was precisely when I realized that everything I do must be geared toward the needs of the target audience. That was in 2006 – long before DIN EN IEC/IEE 82079-1:2021-09 with its now approximately 100 references to the topic of "target audience".
I was inspired in a similar fundamental way 16 years ago the other day. And that had partly to do with my analysis of the new 26514:2022-01, the revised basic standard for the design and production of user information for software and systems, which appeared earlier this year.
The 26514 emphasises, and in doing so, borrows completely from the state of the art, doctrine, and the requirements of 82079-1, that the three basic pillars for good user information are the following:
The standard once again raises awareness of the need not to underestimate interdisciplinary interlocking and the associated early proactive stakeholder and interface management. It strongly advocates that the development of concepts for user information should best take place in parallel with the development of the software itself (pp. vii, 10, 11). This is because, of course, user information can't be integrated in a user-friendly way towards the end or after completion of the software. Thus, this well-intentioned hint can be new and valuable for one or the other manufacturer who wants to handle their first project within this context.
Reading all of this in black and white once again (in this form and with this level of explicitness) may give ambitious technical editorial teams and Quality Managers much-needed tailwind, which is also helpful for all of us on our mission and in our quest for better-informed users. However, other aspects also caught my eye as being inspiring.
Overall, 26514 has much more to offer in terms of demystifying and operationalising target audience and activity analysis, as compared to 82079-1. A circumstance that is equally surprising in view of the more global claim of the 82079-1 as it's really positively surprising, in relation to the 26514.
One of the most motivating highlights of the standard from my point of view is that in examples for addressees of information products, very real, concretely named target audiences are used (Chapter 6.2.2), which consequently no longer appear so inhomogeneous and abstract as is the case, for example, with the more widespread undifferentiated target audience agglomerations à la "technical personnel" or similar, which usually make a truly target audience-adequate description and instruction impossible, right from the outset.
In order to be able to determine the potential target audiences as completely as possible, the standard suggests approaching them both "bottom-up" (i.e. evaluating the various use cases that arise) and "top-down" (i.e. evaluating the respective organisational structure). Such systematic approaches are enormously helpful for kick-off events, in which respondents to the involved target audiences otherwise tend to answer in monosyllables, due to a lack of imagination.
If this – admittedly – ideal situation of narrowly defined, homogeneous target audiences cannot be applied and it's necessary to address rather heterogeneous target audiences, then the standard comes up with the following practical tip: It recommends making use of "layering" in such a case, in which more in-depth content is offered step-by-step, which only needs to be accessed and consumed as required (i.e. for those parts of the target audience that are dependent on more detailed information), for example, by linking or opening up.
Chapter 8.14 makes a value-added case for designing on-screen information offerings to enable the creation of user-generated content (additions or adaptations to existing content, opportunities to convey feedback). The kothes "Insight Report Service 2021" (available in German, only) confirmed, moreover, that 92% of the Service personnel surveyed would like to see feedback functions and 36% would like to see an offer to be able to create user-generated content.
Chapter 9.14.4 pleads, in a way that is pleasantly tolerant of standards, for consideration of whether, instead of complex screenshots, there could be deliberately simplified, (possibly editable) replicas of them, for the sake of better focus and easier localisation. This is an impulse for which readers who wouldn't have come up with the idea on their own or for whom the legitimacy of this approach hasn't yet been established will be grateful.
This article shouldn't be (mis)understood as an unconditional purchase recommendation for the new 26514. Organised technical editorial departments will have already dropped the approximately 200€, anyway.
More "autonomous" technical editorial offices, on the other hand, will decide to forego the purchase, since they place a higher value on their own creativity and competence and are convinced of their analyses, concepts, and evaluation results. In my view, the latter is also completely legitimate, because one can always be better than the norm and the only measure for this is actually the success that one has achieved on the part of the users with one's solution. So if you can demonstrably claim these successes with the target audience, the standard, which of course not only strings together inspiring highlights but also has tough passages full of banalities, is superfluous.
In any case, the tech giants have long since proven this and are simply shifting the state of the art without even having heard of 26514: The manual for my new printer was less than half a page. Nevertheless, it was set up in just under a minute (with the help of a really smart Wizard).
Independent of the rather pragmatic question of whether (and how I would like) to promote the standard within my circle of colleagues, another, more revolutionary insight for dealing with standards in general matured in me, which I don't want to withhold from you:
The fact that standards, in addition to hopeful highlights and gratifying demands with a tailwind-like character, also demand at the same time much that's inapplicable, banal, old-fashioned, redundant, too restrictive, is not new. One could tear down any standard by focusing only on its weaknesses. Often, however, these weaknesses don't survive a new amendment anyway, so why waste energy on them? Why risk the potential of a possible spirit of optimism in the sense of more creative approaches for more target audience orientation by unnecessarily relativising the positive or focusing on the weaknesses of standards?
For this reason, I'd like to encourage you to study standards holistically, but to put them in the context of corporate/departmental goals in good time and, on the basis of an internally conducted or externally commissioned strengths-and-weaknesses analysis, to discuss which of the identified internal weaknesses should be transformed into strengths (e.g. with the aid of standard highlights). The rather weak requirements of a standard thus become irrelevant requirements (since the company's own, better solutions are to be weighted higher), which are better ignored in the interest of the noble goals.
The 26514, for example, legitimises this approach (in rudimentary form) itself by expressly permitting "tailoring" (probably within certain unspecified limits) (p. 9).
This selective implementation has predominant advantages, in particular:
These generalisations and deductions have motivated me in a comparably fundamental way, as they did back in 2006, as it once again (and perhaps now more clearly than ever) brought home to me, who is now the Head of Quality Management, that successful, sustainable Quality Management shouldn't be based on restriction and control, but on inspiration.