Getting Good Reviews

Subject: Getting Good Reviews
From: "Suzanne Chiles" <suzchiles -at- pobox -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 27 Mar 2002 10:06:53 -0800

We've had a lot of discussion lately about the problem of errors in our
documentation and who's at fault or not at fault.

It seems to me that the real question is what we can do to get better
reviews of our work.

There are some processes of reviewing that are, at least to me, a recipe for
complete disaster. In some companies I know of, writers wait until they've
finished their deliverable and then send out that deliverable to all of the
people who are stakeholders and ask for a review. I've only work with
computer software, but usually at the stage when the completed document is
given out for review is an extremely busy time for the intended reviewers.
Usually they are very deep in the QA cycle fixing bugs or working hard on
last-second new requirements. And who isn't intimidated by someone dropping
a few hundred pages of documentation on their desk wanting detailed review?
Under these circumstances, I think it would be impossible to get a decent
review out of anyone.

Another problem with sending out a completed document to lots of people is
that the reviewers aren't always sure what they should be reviewing. So,
like most of us, they start at the beginning and get as far as they can
until it's time to hand in the comments. I've seen so many manuals where the
first two chapters have been reviewed and corrected sublimely, and the
remainder of the manual are lucky to have been read by anyone except the

Over the years, I've come to believe in handing out small amounts of
information (a chapter, a section, a "book topic" in online help) early and
only to those people who are directly involved with that feature set
(developers, designers, interface specialists). Knowing they only have to
work with a relatively small number of pieces of paper is a great relief to
them. And, because they're asked to read and review only the information
they are familiar with, they are typically not averse to reading and
returning their comments quickly. I've seen turnaround of less than a day
about 75% of the time.

Of course, there will always be some people who should and must read the
entire deliverable; good scheduling and negotiation can help ensure a good


PC Magazine gives RoboHelp Office 2002 five stars - a perfect score!
"The ultimate developer's tool for designing help systems. A product
no professional help designer should be without." Check out RoboHelp at
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit for more resources and info.

Previous by Author: RE: Health Coverage for Contractors
Next by Author: RE: Ethical Companies (no flame wars, please)
Previous by Thread: Re: Consequences of inadequate docs/training?
Next by Thread: Re: How to look good in your customer's eyes

What this post helpful? Share it with friends and colleagues:

Sponsored Ads