Reducing writer errors

By | 2013/08/17

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.


Series Navigation << Revision, Waste, and EvennessDumb vs. Smart Revision >>

10 thoughts on “Reducing writer errors

  1. Marcia Riefer Johnston

    Lots to consider here. I especially appreciate this insight: “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?”

    1. Mark Baker Post author

      Thanks for the comment, Marcia.

      Actually, that point touches on what I believe is a much larger defect in common tech writing process. When tech writers work on the interview-the-SME principle, the person they choose to interview is often not the SME on how the product will be used, but the SME on how a particular feature of the product is implemented. On this model, therefore, neither the writer nor the engineer actually knows anything about the use of the product. No wonder the docs produced this way are of little value!

  2. Alex Knappe

    As I’m working for a documentation service company, I think I’ve got a pretty good insight in what is causing lots of errors in the writing process.
    This ranges from rediculus DTP systems (i.e. Word with special add-ons), to bugs in software (Framemaker), to horrificly organized Content Management Systems and stupid information architecture.
    Then there’s always the communication issues between the involved parties. You don’t get all information, outdated information or wrong information. Worst case here is, that nobody actually knows what’s the right information at all.
    Always a good source of errors are rushed prototypes, last minute changes or unmentioned features.
    On the writers side, there’s too many projects in parallel, bad training, too many organizational duties or generally too much workload.
    The revision process usually tends to correct spelling, grammar and style – but content wise it usually makes things worse than better.
    oh, and I nearly forgot one thing – NEVER EVER let the legal department have a look at your docs!
    The only solution to this dilemma I see is, that the tech writers need to take full control of their ressort.
    They need to decide, which software they use, they need proper training and appropriate decisions on the what and how.
    They also need to know about every project in developement and the accomplished milestones on those.
    They need control over how many personel they need and according budgets (I know this will be the hardest part).
    They also need access to a solid base of test customers, that can do usability tests on the documentation.
    And finally they need control over the release date – and this is the most important point.

    1. Vinish Garg

      Alex, many organizations would love to give all that control to writers (which software they need, how many resources, project plan details, and everything that yo listed).

      However, the question is who validates what the writers need; this is where organizations are stuck!

      1. Mark Baker Post author

        Thanks for the comment, Vinish.

        That is indeed the question. We need a new approach, and I don’t think it will come from the old big-iron DTP programs nor from the current big-iron CMS programs. Technical writing today is burdened with complexity. We need to simplify and streamline.

    2. Mark Baker Post author

      Thanks for the comment, Alex.

      Yes, all of the above are issues that contribute to waste in the pubs process. Horrendous tools are a particularly significant issue IMHO.

      But I’m not sure that writers taking control is the whole answer. To begin with, if you put most writers in control today, I fear they will create an isolated artisan process (I hope I’m wrong about that, but that is my fear). What we need is an integrated industrial process. I think there is a lot of leaning that has to happen, and a lot of negotiation that has to take place before we can make that transition.

      On the other hand, writers do have to take control in the sense that they have to take the initiative to get these changes rolling. Personally, I think writers should regard these changes as an essential self-preservation measure. I don’t think the enterprise is going to continue to allow us to work as we used to do.

  3. Eileen Bator

    Mark, maybe your next book should be on best practices for technical writing 😉

    1. Mark Baker Post author

      Thanks Eileen. I’d love to write a book on Lean Content Development, but I think we need to see more cases in which people actually apply lean principles to content development work.

      By the way, I would love to hear from anyone who is applying lean principles to content development. Equally, I would love to hear form anyone who is applying agile principles to the writing process (as opposed to simply fitting content development into development’s agile process).

  4. Michelle

    What about bringing a technical editor on to the team, whose primary focus is quality assurance? When writers can collaborate with editors, and can come to rely on editors as part of the information development process, the reader wins. When I say technical editing, I mean more than light copy editing; I mean full comprehensive editing that looks at the larger issues than just grammar and punctuation, such as structure, and flow, and navigation. Developers work with testers, so writers need to work with editors, to reduce the errors that make it out to the readers.

    1. Mark Baker Post author

      Thanks for the comment, Michelle

      I think a technical editor can bring a lot to the table. A technical editor can catch more errors sooner in the process, and thus reduce the cost of fixing them. That can be a significant win for relatively little investment in people or process change. The biggest challenge may be finding the right person with the right knowledge and aptitude.

      However, by itself adding an editor does not reduce our reliance on human inspection of every piece of content, which is inherently expensive and error prone. I think we have to look beyond this and start looking at ways to build error reduction and detection into our tools and processes.


Leave a Reply