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: Grammar and rhetoric... From:Andreas Ramos <andreas -at- NETCOM -dot- COM> Date:Mon, 6 Jun 1994 12:53:00 -0700
> John Brinegar suggested we discuss:
> >How can technical communicators learn to study their
> >users' world of work so that they can deliver what the
> >users actually need, instead
> >of what they and the users imagine they need?
I found it extremely useful to have done technical support for several
years. Especially when I was supporting the manuals which I had written.
I took a manual and marked it TechSupport and then kept notes in it on
all of the questions which I receieved. After a while, it was the same
ten questions. The manual would open by itself to those sections. Either
the sections were written with too much assumption (akin not writing "and
press <Enter>") or just poorly written. In the next version, I'd rewrite
the hell out of those sections: spell it out so there'd be no doubt. This
worked: the calls on those sections would disappear.
There's sections which always cause trouble. Better yet, there are types
of users which cause problems: the newbies and the power losers. A
newbie is okay; they just don't yet understand. It's the sections which
are basic for us which are obscure to them: installing a hard disk,
editing a CONFIG.SYS, etc. So I tend to write those sections with lots of
extra words: the experienced user will skip over it and the newbie will
appreciate it. As for power losers: well, there's always a few people who
never figure it out, and won't put any effort into it. If 99% of the
other users can figure it out, then it's the loser's problem for not
trying. There's nothing to do for those people. I've often written pages
of explanation just for a particular customer, to whom I'd fax the stuff.
He still couldn't figure it out. (I did t/s (tech support) for years;
there were always a few of these guys.)
There's nothing like talking with the readers of your work. Frankly, the
surveys, questionnaires, reader response cards, etc, all of which I
tried, were zero compared to even just a few weeks of doing
telephone technical support.
If you can, get a seat at the t/s dept for a few weeks. It'll give you a
good idea of how users are working with the program.
If that's not possible, then go and sit with t/s. Become buddies with
them. They know an awful lot about the way that customers have problems
with the product.
Borrow t/s's manuals. Look for the grimy pages. That's were the buggy
text is. And look for notes: t/s often has crossed out wrong text and
written in the correct text.
Ask t/s for their help sheets. They often write text for a user, and then
keep it to send to other users.
And ask t/s for their ideas on what should be covered. It won't sound
pretty, and maybe it'll be redundant or simplistic, but it'll
"pre-answer" the user's problems and questions.
I look at manual writing as "preemptive t/s". T/S is expensive. There's a
lot of humans sitting at telephones. If five extra pages on how to format
a disk can reduce the calls by 5%, then it's a hell of a savings. It also
frees up t/s so that other users don't get busy signals (which is one of
the things which most frustrate a user).