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.
>The problem that arises is that in
>our user manuals, there tends to be
>a lot of duplication of very simple
>information, as writers try to cover
>all possible bases in each section/
>procedure... we also tend to illustrate
>every freakin' move a user has to make
>in a procedure... even a simple
>"Click OK."
Lynne...normally, I'd agree with you. However, the addition of those
three little words "emergency response center" completely changes my
opinion.
If I were responsible for designing that type of documentation from
scratch, I imagine my first take would be to identify each individual
task, then describe that task completely from step 1 to step 20. If a
second task was identical except for something at step 18 of 20, I'd
create a complete sequence from 1 to 20 all over again.
Why?
I'd imagine a response operator needs the set of instruction tight in
front of them without having to switch back and forth between
instructions, with the possibility that at step 128, where one says call
the fire department and the other set, at step 18, says call the police
department, that they are certain to call the right department.
Besides...ya can't change something that works simply because you don't
like it...does it work for the customers? What improvement will your
customers realize with the change. Has field testing shown that the way
it's currently being done is a problem for your customers?
