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:Emru Townsend <emru -at- CORECO -dot- COM> Date:Fri, 7 Nov 1997 13:27:07 -0400
WandaJane, you've hit on a subject that is very dear to me. I just sort of
fell into technical writing; my previous professions centered on training
(Windows, DOS, Word, WordPerfect, animation software, etc.) and freelance
writing (mostly tech stuff for laypeople -- reviews, opinion pieces, and
such).
What ultimately got me hired was my ability to transfer knowledge from
point A to point B, in spoken or written form. What has been a constant
source of frustration is that few people here seem to consider their
audience, when writing software, publicity, or the manuals I sometimes have
to rewrite. I feel -- as you seem to -- that knowing and understanding
your audience is the first half of the job. This applies to anyone who has
an active hand in creating any kind of media. Would that more people
realized this.
wjp -at- WRITELIVELIHOOD -dot- COM on 11/06/97 05:38:03 PM
Please respond to wjp -at- WRITELIVELIHOOD -dot- COM
To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
cc: (bcc: Emru Townsend/Coreco Inc.)
Subject: QUESTION: The Role of the Tech Writer
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/
