Reducing writer errors

One of the most consistent responses I have received to my posts on revision as waste (Improving First Run Quality, and Revision, Waste, and Evenness) is some variant of “mistakes happen”. Some felt I was blaming writers, or even questioning their integrity. (Such comments were much more prevalent on LinkedIn than on the blog itself.)

Actually, this has very little to do with either the integrity or the diligence of individual writers. Writers are human, and they do make mistakes. The problem is that they tend to work in environments that make mistakes more likely, and that make discovering them less likely. If we want to reduce waste in the content creation process, we should be looking not at individual writers, but at the process and environment in which they work.

I want to start by making it clear that while to err is definitely human, our environment plays a huge role in how often we make mistakes. Traffic engineers, for instance, spend a lot of time studying how road designs contribute to driver mistakes, and to designing roads differently so that drivers make fewer mistakes, and thus cause fewer accidents. These design changes save lives.

Product designers, similarly, spend a huge amount of time studying usability of products. Usability, essentially, means designing products so that users make fewer mistakes trying to use them.

Pilots use checklists to make sure they have not forgotten anything in the preparation and operation of a plane. As Alan Siegel and Irene Etzkorn relate in Simple: Conquering the Crisis of Complexity, other safety-critical fields are adopting the same approach:

By adapting airplane checklists first devised by Boeing, a number of hospitals are now using a checklist approach to make sure that during surgery there is a specific, brief set of questions and procedures to follow at all times.

Siegel and Etzkorn also report on the work of Deborah Adler, who, inspired by an incident in her own family where her grandmother got sick taking pills prescribed for her husband, worked to design better prescription labels (and better pill bottles to attach them too) in an attempt to reduce the number of mistakes people make with their medication, mistakes that reportedly cost $290 billion in medical expenses each year (I’m assuming those are US figures, though Siegel and Etzkorn don’t specify).

So, while to err may be human, we can drastically reduce the incidence and cost of mistakes by engineering our systems and environments to reduce the likelihood of making a mistake, and/or to make mistakes more obvious and easier to detect when they do occur.

And, of course, helping people to avoid mistakes is what technical writing itself is all about. Siegel and Etzkorn report what technical communication commonly claims:

Companies that do a better job of simplifying their communications spend far less time— and money— talking on the phone to confused (and possibly angry) customers. Future sales can also be affected: Our own “Perplexity Polls” show that as a result of unclear product instructions, consumers were not only more likely to contact the manufacturer or seller of a product; they were also less inclined to purchase another product from that company.

But if the role of technical communication is to reduce the number of mistakes that users make, then it follows that we should be especially concerned with the mistakes that technical writers make, because if writer’s mistakes make it all the way through to the information people read, they will cause customers to make mistakes. If we care about engineering systems, including documentation, to reduce the number of mistakes consumers make, we should care doubly about engineering systems to reduce the number of mistakes that writers make.

By and large, though, the effort that documentation groups put into reducing the number of mistakes that writers make is slight. Many groups do put varying levels of effort into reducing the number of style and presentation errors that writers make, either through the use of style guides, or through the use of structured publishing solutions. But similar efforts to address omission and errors in the technical content are much less common.

Some efforts are made to find factual errors and omissions after the fact through SME review, even though we know that such reviews are of limited use in finding real errors and omissions, especially when they are done in one lump at the end of the development cycle.

In some cases, though not often, usability testing is done. This is a wonderful thing, when the resources exist to do it (and do it right), and can help prevent user errors due to lack of clarity. But such tests are only partial, and often the results are not fully cycled back into the development process — we fix the instance, but not necessarily the process that created the instance.

What we need, to reduce writer errors, including errors in fact, omission, usability, and style, is a systematic approach to building a writing environment that reduces errors, detects errors more quickly, and continuously improves itself to reduce the causes of error still further.

Some possible approaches (some of which I will expand on in later posts):

• Treat every revision as a symptom of a potential problem somewhere in the process and do a root cause analysis to find out why the revision became necessary, and look for ways to eliminate that cause.
• Simplify the writers’ working environment. The more things you have to think about, the more likely you are to make a mistake. Writers often have to work with complicated desktop publishing and/or content management systems that require significant mental energy which cannot then be focused on getting the content correct. Look for ways to take publishing and content management concerns off the writer’s plate.
• Consider the importance of evenness in your content process. Are you so focused on optimizing one part of the process (such as reuse) that you are creating unevenness in the rest of the process (generalizing text in a way that make it less clear, for the sake of being able to reuse it in more places; creating a complex reuse process that requires so much mental energy from writers they can’t focus on the subject matter itself), and thus allowing errors to creep in?
• Work on smaller, simpler units. Writing a manual is writing a book. Books are very hard to write. (I know this because I am, painfully, writing one.) Create Every Page is Page One topics instead. They are simpler for the writer to write and for the reader to read. Books have their place, but most technical communication is better handled with Every Page is Page One topics.
• Develop, implement, and test reliable design patterns that work for your audience. Implement a writing system that guides writers in creating content according to those patterns, and that allows you to audit the content for conformance to the pattern. Subject the patterns themselves to continuous improvement. Structured writing techniques can be of enormous help here, but be careful not to introduce yet more complexity into the writers’ lives. Implement structured writing in a way that reduces, rather than increases, the overall complexity of the writing process.
• Consider if you are hiring the right people to write your documentation. Are you hiring them more for their knowledge of your ridiculously complex publishing system than for their understanding of the reader’s task domain? Perhaps by changing your writing environment, you can change who you hire to write.
• Look at the relationship between the writing team and the development team. Are wasteful revisions being caused by problems in the way information flows between groups? Is lack of access to software or hardware a problem?
• Look at the review process. Is there a way to do review better? Particularly, can you do review in small pieces earlier in the process so that errors are found sooner, and reviewers are not asked to review a whole book at a time, which often leads to fatigue and skimming. Are you having the right people do review? Developers are not necessarily any more aware of the reader’s task domain than the writers, and often less aware. Are they the best people to be doing review?

Above all, though, don’t be satisfied with “mistakes happen”. Mistakes happen for a reason, often for specific reasons that can be found, diagnosed, and fixed. Work on creating a writing environment that is specifically designed to reduce writer errors, and a working culture that is dedicated to continuous improvement of the writing process.