One of the things that makes quality documentation on a product is a review process. I think many technical communicators would agree with me, however, that sometimes the process becomes more cumbersome than beneficial. The more people involved, the harder it is to meet deadlines.

While I’m in favor of a limited review process, I think including four certain types of people will maximize the results. I’m not recommending a particular order here.

Reviewer #1: The Subject-Matter Expert

This person is helpful for verifying content about organization procedures or policies and how these things relate to the product. He verifies and clarifies context. For example, I may be able to write instructions for completing a certain task, but the SME helps me make sure I adequately explain why the user would need to dive into that task in the first place.

In my book, SMEs can be stakeholders, other workers in the group we’re producing for, or even business analysts. Interaction designers can fit this category if they are also acting in the business analysis role in order to put together their designs. The bottom line is that this person knows in detail why and how the users do what they do, either through personal experience or extensive research.

Reviewer #2: The Tester

The eyes of a quality assurance engineer contribute by verifying the accuracy of the instructions or other discussion about the product itself. She may know some of the context or business, but ultimately, she’s concerned with whether the product does what it is designed to do. Therefore, her scrutiny helps to make sure that their are no mistakes in how the documentation describes the product itself. And because testers come up with myriad test cases, they help think of the many ways that the users may exercise the product so that we can cover the most important ones.

I’ve also had testers occasionally find problems on the grammar level that got past me and the business analyst—the kind that are introduced when I start to word something one way, then change my mind and don’t clean up all the way.

Reviewer #3: The Editor

Of course, the editor is concerned with grammar, punctuation, and clarity. Perhaps knowing nothing about the product, he can read content purely for coherence and cohesion. Editors can tell when a sentence’s structure doesn’t make sense or is overly complicated even when they don’t understand what the sentence is talking about.

Reviewer #4: The End User

This is one, I’m afraid, that is normally left out of the process, including mine. My set of quick reference guides and Captivate demos for a particular project are going to be released soon to a beta office so they can give me feedback. I’m looking forward to getting their comments, though I’ll probably have to don a rhinoceros-skin suit. Most users don’t grace their comments with rose-colored frosting.

The end user is the one who has to digest the documentation and translate it into getting her job done. If there are holes in the context or missing steps, the end user will notice. If she is satisfied with the content, this is probably the most important approval we can get.

Satisfying yourself and these other people can be hard. When I send something out to several people, I hope that very few comments come back because I interpret silence as sign-off, especially when I’ve given the reviewers a deadline. The danger is the potential for the feedback to be as varied and substantial as the group to which I’ve sent content. It’s more manageable in stages, though, rather than a mass mailing and a mass reply—first the business analyst, then the testers, and so on. And involving these different types of people in the review process will help make sure that the documentation picture is more complete.