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:What is a technical writer? From:Kathy Eyster <kathy -at- NEVADA -dot- EDU> Date:Fri, 30 Apr 1993 14:23:11 -0700
Hi All,
The following article was posted to the newsgroup misc.writing in
response to a "what are you called" discussion on technical writer job
titles.
I feel it's relevant to the recent thread (in techwr-l) about what a
technical writer's mission is. It describes almost exactly what I feel
my responsibility is as a technical writer (aka "documentarian").
I think it's also pertinent to the recent discussions about
punctuation, word choices and syntax in copyediting-l. After all,
we're copyediting with the goal of improving understanding of the
writer in the reader's mind, aren't we?
K. Steele writes:
> A lot of companies are calling tech writers/courseware developers/trainers
> Information Engineers. The logic being that communication is the
> cornorstone of good business, and it is the business of efficiently
> moving information from source to consumer. Also, as more and more
> communication occurs in a manner other than the printed page, the term
> technical writer may become somewhat archaic. Most of us spend at least
> part of our time programming the help files and constructing the training
> files. Writing (in this type of environment) has then become one of
> several duties involved in achieving effective communication.
The following is an article I recently co-wrote for the newsletter of the
Santa Barbara STC chapter (commenting on a recent program meeting on Total
Quality Management):
Our Product: Understanding
by Yvonne DeGraw and Angela Howard
Nancy Tomhave asked us to list things we produce at our March program on
Total Quality Management. I believe that our ultimate product should be
understanding in the minds of our audience, and that thinking about
"understanding" as a product can improve the physical products we create.
At the meeting, Angela said our product is "information." She was thinking
of our conceptual products, not just physical products like "manuals" and
"online help". If we think only of physical products, we limit the ways in
which we can communicate information.
After the meeting, we decided that "understanding" is an even more important
product. Our suppliers give us "information" in the form of specifications,
software, or hardware. Our job is to provide ways for people to understand
this information.
Thinking about what our audience needs in order to quickly understand
information points to new methods of communication. In addition, such thoughts
provide ideas for ways to improve documents we already produce.
For example, maybe a better user interface -- not necessarily a better
manual -- is needed to promote better understanding of a software system.
Once the user interface is improved, the manual can in turn reflect a better
product design, making it clearer and easier to understand.
Or, maybe a good way to help someone understand the system is to demonstrate
it to them. Often, technical communicators don't get that close to users.
But what about building a demonstration for the sales people to use? Just
thinking about how you would explain something face-to-face with a user may
help you write a better tutorial. If you've already written a tutorial, you
may have new insights on how to improve it after visualizing how you would
explain the product in person.
Think about "understanding" as a product. What is the best way to create
understanding in the minds of our audience? It will be many years (maybe
decades or centuries) until we can put understanding on a computer chip that
our audience can simply plug into their brains. Until then, we are faced
with the challenge of getting as close to creating instant understanding as
possible.
What are ways of creating understanding painlessly? Here are some ideas we
came up with:
o Products that are easy to understand
o Computer-based training
o Tutorials
o Online help that leads people at first and then supports continued learning
o Examples, examples, examples
o Documentation for people who don't read documentation
o Visually-oriented documents
o Indexes, indexes, indexes
o Well-organized reference material
We should strive to improve both our physical products and our ultimate
product -- understanding.
Yvonne DeGraw, Technical Writer
SmartStar Corporation yvonne -at- smartstar -dot- com
120 Cremona Dr. (805)685-8000
Goleta, CA 93117
----------------------------------------------------------------------------
Kathy Eyster Internet: kathy -at- nevada -dot- edu
System Computing Services Bitnet: kathy -at- nevada2
4505 Maryland Parkway Phone: (702) 895-4587
Box 454016 FAX: (702) 895-3791
Las Vegas, NV USA 89154-4016
