Technical Writing – Peer Reviews, How To Get Them Right

As a technical writer you’ll need to engage constantly with others to ensure your documentation has the impact you intend. One of the more common stages in this process is the peer review. A peer review is essentially where you ask your colleagues (or peers) to read through your work and offer feedback. Here’s how to make the best of this opportunity.
Initial Meeting
It’s always a good idea to meet with the people who will review your document, prior to starting the review itself. At this meeting you want to convey what is expected from the process and provide your team with enough information to give constructive feedback. Here’s what to cover:
Outline the audience
Outline the purpose of the document
Provide supporting information – writing briefs, e-mail input, etc.
Address your goals for the process
Address any concerns you may have with the documentation as it stands
Set out a structure for the process (see example below)
Set a timescale for the whole review
The Structure for Your Peer Review
One of the easiest mistakes to make is to ask your team to read the whole document and amalgamate all their feedback into a single source, the trouble with this approach is that it becomes heavily disorganised and really valuable input can be lost in a sea of minor niggles.
Your team should make several passes during the process, and after each stage you should adapt the document and re-release it based on the feedback in the former stage.
I like to structure the stages as follows:
Audience Engagement – is the document interesting? Is it something people are likely to want to read? Does it address the stated needs of users from the research phase?
Purpose – is the material fit for purpose? Does it stand alone as a product or does it need further information? Is it clear how the document fits in with the whole offering?
Content and Organisation – does the content flow properly? Is it well organised so that each stage takes the user closer to their goals? What can be changed to improve the flow?
Language “High Level” – Do the titles, opening and closing paragraphs have maximum impact? Are they clear and accessible?
Language “Medium Level” – Are sentences and paragraphs well constructed? Are lengths acceptable? Is there a better way to convey any specific information?
Language “Low Level” – Spelling and grammar, is it all exactly as it should be?
Use of Graphics – Is everything laid out as it should be and are the graphics necessary and do they add specific value?
At each stage you should also agree grounds for feedback, which should be specific and come with examples of how to improve. Useful feedback is not “I don’t like that it seems disorganised.” but it is, “Paragraph 3 on page 2 could be swapped with paragraph 4 for a more logical flow, if you check the system specification you have to open a document before you can save it.”
Peer reviews can be massively useful in developing great user manuals, training courses, etc. but you need to ensure you structure it correctly to get the best from it.