In this concluding article, take a look at a sample table ofcontents for a user manual, understand the importance of having yourwork reviewed by peers, and find out how to handle document versionmanagement.
The review is a crucial process for any document, and more so for the user manual. You are dependent on the SMEs for verification of the technical information, on peer writers for editorial comments on structure and flow, technical support guys for evaluation of whether you've covered the most common support requests, and - of course! - a sample set of actual users to tell you whether it works.
But before you get to the point where you release drafts for review by these groups, you need to review the document yourself. Here's a quick cheat sheet that assists in this process:
Is all the information there? Have all the key terms been defined? Are instructions to cover all tasks there?
Is the usage of paragraphs appropriate? Are they too long? On the other hand, guard against the paragraphs being so short and abrupt that the information seems unrelated.
Does the flow make sense?
Are the levels logical? Is the grouping together of modules sensible?
Are the descriptive headings apt? Could there be a summary at the beginning and end of each section to guide the user better?
Are there inconsistencies in usage of terms?
Is the tone consistent throughout? Are you shifting from the first to the third person and back again?
Are all topics covered to a consistent level of depth? Sometimes, at the time of writing, you may not have the same level of information on all topics covered (or you may just have been in a hurry to get the job done). This difference is very noticeable, and looks sloppy - watch out for it and fill in the consistent level of detail.
Once you've covered this ground, you can release the draft for review by the others involved.