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:Substantive Issues From:Bonni Graham <Bonni_Graham_at_Enfin-SD -at- RELAY -dot- PROTEON -dot- COM> Date:Wed, 29 Dec 1993 09:53:00 EST
Saul Carliner notes:
"I'd like to make a painful observation, however. I find that, on this list,
it is easier to get a discussion going about an "easy" subject--such as
the tool of choice (a subject we repeat at least once a month) or the
term to use for mainframe operating systems--than on more substantive
subjects, such as uses of multimedia, quality initiatives, and the value
of technical communication."
I agree to an extent (I've seen some other useful issues come up, such as
how to best address naive/technophobic users, some of the postings on
multimedia, etc.). However, we must remember that this has been (so far,
and in my experience), a question-based forum. If no one's asking the
substantive questions, no one is going to respond Maybe we should
occasionally include a ruminative posting? I don't know.
I'll try to start a thread, though. How do others "prove their worth" to
At my first company, I had to do it by keeping statistics on support
calls. No one did it for me. I got into the database and looked at the
kinds of questions being asked before my manual was release and after. I
was able to prove in a salary review that I had reduced the number of
"How do I?" calls (calls in which the customer simply needed directions
on a procedure) by over 25%.
At my second company, the truly horrific awfulness of the earlier manuals
did it for me. They'd been written in "Germlish" by engineer (speaking
English as a third language -- German, Smalltalk, then English <g>). No
one could use them, and sales were demonstrably down because of it. For
the new product I'm working on, I was able to not only prove the worth of
a tech writer, I was able to justify their sending me to Dallas -- I
brought back some doc testing procedures that helped us create a more
usable product (we're not selling any yet, but I'm pretty sure that
that's a marketing problem -- everyone who's used the program has
commented on how easy it is to use with the manual).
At my contracting job, the naivete of the users did it for me, although
I'm also showing that producing new technical sales material (data
sheets, technical overviews, etc.) helps invigorate the sales staff and
increases sales. I'm also proving that word of mouth about the manual is
helping sales. Of course, one of the VPs is a good friend of mine, and
he already believes in good technical manuals, so I've had it easy.
What has anyone else done? (I may not always be this lucky!) How are
people defining quality documentation? How are people proving that it
adds to the value of the product? I know STC is studying this formally,
but what do we know informally?
Bonni Graham |
Technical Writer |
Easel Corporation, ENFIN Technology Lab | Never tell people how to
Bonni_Graham_at_Enfin-SD -at- relay -dot- proteon -dot- com | do things. Tell them
President, San Diego STC | what to do and they will
| surprise you with their
NOTE: apparently my email address needs | ingenuity.
to be typed exactly as it appears here, |
punctuation and all, or the system gets | --George Patton