TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Hi, Jennifer! I've written several Reviewer's Guides; I sympathize with your
questions.
<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
reviews.
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!
--Kimber
Kimberly Hebert Miller
Affiliated Computer Services
Dallas, Texas
214.887.7408
kimber_hebert -at- acs-inc -dot- com
