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: QUESTION: The Role of the Tech Writer From:Elna Tymes <etymes -at- LTS -dot- COM> Date:Thu, 6 Nov 1997 15:32:09 -0800
WandaJane-
> But is there any benefit to integrating this type of assistance, or
> user advocacy, into our manuals and guides?
Nothing *should* succeed like sales. In our case, the very fact that
the computer book industry is one of the biggest and most profitable
segments of the book publishing industry *should* be be one of the most
eloquent pieces of evidence that most company-generated computer
documentation doesn't really help users. However, few engineering
managers seem to recognize that. And therein lies the problem.
Think about your average software project. Most of the developers
involved will agree that any new software product needs documentation.
They may disagree about just what kind of documentation is needed, but
the war over whether *any* is needed has pretty much been won. (Believe
me, that is progress over where things were 5-10 years ago!) When you
ask your average developer what kinds of documentation he/she finds
useful, you'll get all sorts of suggestions, sometimes presented
emphatically. And based on a synthesis of those suggestions, there will
eventually emerge some ideas about what kinds of documentation this
product should have - note, however, based on the personal experiences
of the developers. Who are not your average users, normally.
Your average software company isn't likely to spend money on focus
groups and user testing up front, in order to find out just how
documentation should be presented. Most of the time they don't have
time or money to do that. And if they do pay attention to user input,
it's likely to be on the user interface, not the documentation.
Many of us who have been fighting this problem for years can cite war
stories illustrating the difficulty in getting appropriate attention. I
can remember a former VP of Applied Materials, who was then president of
the little software company where I was the lone writer, yelling
"Bullshit!" at me for suggesting that white space and layout and
typography mattered in a user manual. (It was a wry form of justice
that the company folded shortly after I left.)
No, we don't get no respect. Well, not enough anyway. We're
user-advocates. We try to think like the user of THIS product, in THAT
setting, and then devise documentation and Help files and other
quasi-teaching material that will help that user learn to use the
product in dealing with his/her business problems. But until we have
believable experience dealing with users, AND the company can see the
relationship between tech support and good documentation, it's an uphill
battle.
Any new learning situation is going to be difficult for most users.
It's our job to take the user from where he/she is to a state where the
tool is comfortable to use.
