RE: Reviewer's guides

Subject: RE: Reviewer's guides
From: kimber_hebert -at- acs-inc -dot- com
To: <TECHWR-L -at- LISTS -dot- RAYCOMM -dot- COM>
Date: Wed, 20 Oct 1999 11:53:25 -0500

Hi, Jennifer! I've written several Reviewer's Guides; I sympathize with your
<quote>1. [snip] If my purpose is not, "here's how to use my product and what I
think you should concentrate on as you review it", what should it be? <\quote>

Well, the *marketing* department asked for the document-that's your first hint
that this is not tech writing as we usually know it (if there actually IS a
'usual'). Your purpose here is dual: the main task of the Guide would be to
impress the Reviewer with the summarized, well-thought-out functionality of the
software. The idea is that the Reviewer is impressed with the software even
before s/he tests it.
Your second priority in a Review Guide is to provide a common task list and the
best way to perform those tasks. If your software has "ooh-cool" features, make
sure that you include their use in the "common tasks."
<quote>2. audience sophistication level - <snip> Can I expect an audience of
technology reporters to be able to find their way around a GUI? <\quote>

Sometimes reviewers <gasp> don't know all that much about the field that the
software supports, and sometimes they are industry experts. It would help you to
know the reputation of the publication reviewing your product, and anything
about the reviewers. From my experience, I was able to find out who was
scheduled to conduct the review and get some bio on them from the publication's
site. Your marketing department hopefully has some of that info, too. Ask your
software development teammates what they think about the publication and it's
Then I suggest that you read some -reviews- rather than other Review Guides.
Find out what the result is, what the reviewers focused on, glean any sense of
method or consistency that you can.
I don't know whether you have any constraints on file size, graphics, etc. for
your Reviewer's Guide. I typically put in a few key screen caps, labeled. And I
put in any sort of statistical information about our market that I can get my
hands on (that also applies to the pertinent software).
If the Reviewer's Guide is going to be prepared to send out to anyone that will
review the software (as opposed for some known bake-off for a particular
publication) you should consider including whatever key INDUSTRY concepts the
reviewer would need to appreciate before s/he could fully grasp how brilliantly
your product is designed. You might want to embed these ideas anyway, just in
case the reviewer forgets, or needs a perspective-shift.
Well, I hope that this missive has had a couple of relevant nuggets. I enjoy
writing "technical marketing" material; I hope you will, as well!

Kimberly Hebert Miller
Affiliated Computer Services
Dallas, Texas
kimber_hebert -at- acs-inc -dot- com

Previous by Author: Help with PDF writing
Next by Author: Fodder for telecommuting requests
Previous by Thread: reviewer's guides
Next by Thread: WebHelp generated by RoboHelp 2000 (particulary on Unix)

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

Sponsored Ads