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.
As someone else noted, most of the responses on this thread have been about
_writers_, but Janice Gelb's comment (that Sean Hower asked about) was
regarding _editors_. Gene Kim-Eng also observed, "I have traditionally
satisfied any need for such a person by borrowing an
admin or other non-technical person already in the company to attempt to
use my document to operate the equipment or software. I hardly ever
encounter a situation where there's such a shortage of ignorance that I
have to go out and hire it."
In my experience, the main difference with having documentation "usability
tested" or "usability edited" by an experienced editor who knows the
audience's subject domain (accounting, for example) but not the product
being documented, and using someone else to fill that role, is that an
editor is more likely to be able to ask specific questions or explain to
the writer just what appears to be missing, or articulate the logical
flaws, or otherwise make constructive solution-oriented comments, not just
be confused or not understand. Gene's solution can be a good one, but
(especially for backup on less-experienced or less-skilled writers) using
an editor can be even better.
Janice later gave an example of what she meant. Here's another example.
I've had experienced editors work on the books I've written. In some cases,
the editor had no familiarity with the product at all (but was familiar
with the concepts from the audience's point of view), but still did a good
job of spotting (and explaining to me) what was missing in the draft.
People more familiar with the product are far more likely to spot errors in
what _is_ there, but far _less_ likely to spot what _isn't_ there. So both
approaches can be quite valuable.
However, some levels of ignorance are not helpful. If editors don't know
enough about the subject matter from the _audience's_ point of view, then
they won't be able to spot some problems. If those editors _also_ don't
know the product, they're reduced to being grammar police. Even worse, some
of them end up attempting to convince the writer to make changes that are
of no use to the audience at all, thus (at best) wasting everyone's time or
(worse) making the documents less useful.
I call the useful type "strategic ignorance" -- a difficult concept to
explain, especially since it's very situation-dependent.
Regards, Jean
Jean Hollis Weber
jean -at- jeanweber -dot- com
The Technical Editors' Eyrie http://www.jeanweber.com/
Order RoboHelp X3 in May and receive a $100 mail-in rebate, PLUS
free RoboScreenCapture and WebHelp Merge Module.
Order RoboHelp today: http://www.ehelp.com/techwr-l
ATTENTION FrameMaker Users: Fill-out the following survey
to receive a chance to win a FREE RoboScreenCapture.
FM users only please: http://www.ehelp.com/techwr-2
---
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 http://www.raycomm.com/techwhirl/ for more resources and info.
