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.
Subject:Re: Field Tests From:RoseRead -at- AOL -dot- COM Date:Wed, 20 Jul 1994 16:57:52 EDT
**Nora (or anyone else) the Mail Daemon is bouncing your mail back to me. I
tried to reply to you direct at the following address:
merhar -at- alena -dot- corp -dot- rockwell -dot- com**
Anybody know what the deal is?
Nora asked for suggestions on field testing documentation.
One approach I used while being trained to write software
documentation was to do "protocol reviews" (huh? sounds like jargon to me).
I don't know how workable those are in your work setting - anyone within
company probably knows more about the product than your average user would
know, and would not be able to render a realistic response to the
Perhaps your company could send you to one or more of the individuals or
companies involved in the field trial, to observe the user in the process of
testing the software with the documentation.
When I did this, I sat the user down with my manual and the software, and
told them to "think out loud" as they went through the instructions, but to
NOT ask me any questions directly. I chose people that had a low common
denominator of computer knowledge (i.e. knew how to turn the thing on and use
- this was for macintosh, so the interface always carried pretty well from
one piece of software to the next).
When I compose task-oriented documents for staff in the clinic where I work,
I often use the same method for testing the documents. One thing I've learned
is that I have to write most of this stuff with the assumption that the last
thing these people are going to do is CTFM.
Hope this helps, it might be pretty lame for what you are doing, but it has
worked well for me in testing documents aimed and users with a zero level of
knowledge about the computers/software I'm writing about.