Re: Grammar and rhetoric...

[Andreas Ramos <andreas -at- NETCOM -dot- COM>]

> 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).

yrs,
andreas