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:QUESTION: The Role of the Tech Writer From:WandaJane Phillips <wjp -at- WRITELIVELIHOOD -dot- COM> Date:Thu, 6 Nov 1997 17:38:03 -0500
I've been contemplating a philosophy for a while now and it is, apparently,
time to go public with my musings and get some *real life* feedback.
I've been reading some communication theory, including Marshall McLuhan. I
can't remember the exact passage or even the book, but one day something I'd
read surfaced and became a question. McLuhan was talking about the social
changes that occur when a new idea is introduced. The most dramatic shifts
are probably manufacturing and computer.
I began to wonder about the smaller shifts, the quakes that happen when
people are forced to change their habits. It may be something like data
warehousing which is a fire burning bright these days. The trade rags are
full of prophesies and products that will take you into the new world order.
If you are an early adopter, it is not a problem, you enjoy digging and
figuring and it isn't really disruptive because change is a key part of your
working methods. But, what about the rest of the world, folks who've cut
wood the same way all their lives are faced with a computer console ten
years away from retirement. What kind of stress is involved in that? And how
can I, as a technical writer, mitigate the shock of that shift?
Actually, I'm thinking even smaller than that. For example, my first
experience with a typical documentation product was a difficult
introduction, it was difficult to learn and worked very differently from the
process I was accustomed to. There was no documentation to hold my hand
through this transition time. Nothing to emphasize that what I was getting
was a tool that would make my processing easier, allow me to be more
creative in my presentation, and would deal with larger documents more
efficiently than what I'd been using. I was left with a functionally-based
document that described the system, not what I was doing.
Okay, since that day (which, although it seems so long ago, was not that
long ago) we've begun to make a shift towards orienting our information
towards the user. But are we really smoothing the transition? What if we
know that using the product will be difficult for a user? What if we told
them how to correlate existing processes to the new product? Where you once
pulled this lever after centering the boards, now you select *alignment*
followed by the command *cut*.
Third party books address some of this, particularly for big software
titles. But is there any benefit to integrating this type of assistance, or
user advocacy, into our manuals and guides?
Happy customers don't call tech support, they call their friends.
WandaJane
/* Write Livelihood - Documentation that solves problems
/* WandaJane Phillips wjp -at- writelivelihood -dot- com
/* Visit our web site at http://www.writelivelihood.com/
