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.
-----Original Message-----
From: David Downing
To: TECHWR-L
Sent: 8/9/02 3:01 PM
Subject: DON'T DO IT!!!
The procedure for programming number into
the phone's memory is essentially the same un both places, except that
the cheat sheet has "Do NOT lift the handset" as the first step. The
author of the official manual apparently thought that was implicit the
omission of "Lift the handset," but the trainer told us that everybody
just automatically lift the handset -- and the procedure doesn't work.
------ ---------
In a previous job, I split my time between training and manual-writing. With
my experience and after reading David's story, I am reminded of the major
difference between trainers and manual writers. Trainers write their
procedures and refine them with practice. They watch how people use a
system, then write the procedure again. Trainers add little tips they find
themselves repeating in class. Another trick I found myself doing when
training & writing manuals was icorporating answers to FAQ's into my docs.
That is, if a question was asked several times in several courses, I figured
my explanation wasn't quite enouth, so I'd add a tip.
My manuals at that previous company were very well-read and well-regarded.
"No, really, the help files ARE helpful," I'd hear tech support people
saying on the phone to customers. Heh.
The bottom line is that trainers -- or anyone with customer "touch" for that
matter -- are in a great position to help write practical procedures. In my
current position, I wrote a user's guide that I still regard as
inferior...mainly because I don't see how customers use the product, don't
see how they learn to install it, and don't hear their questions about the
product. All of these add to improving the documentation.
>From my experiences, I'd theorize that the practicality of documented
procedures improves with more time spent with actual users.
Regards,
Meg Golding
Technical Writer, recovering Trainer
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Save up to 50% with RoboHelp Deluxe. Get 2 great products for 1 low price!
You'll get RoboHelp Office PLUS RoboDemo, the software demonstration tool
that everyone's been talking about. Check it out and save! http://www.ehelp.com/techwr-l
---
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.
