Degree question (What does a technical writer need to know?)

Subject: Degree question (What does a technical writer need to know?)
From: Steve Owens <uso01%eagle -at- UNIDATA -dot- COM>
Date: Fri, 7 Jan 1994 11:32:44 +0700

I've done a little thinking about this myself, recently, because we've
been looking at how the technical writing field carries over to
usability testing.

I think the essence of the technical writer can be boiled down to three
areas, three stages. Of course you can have an ideal personification of
a technical writer, but this quickly approaches the point of being an
ideal person in general, so I'm keeping the focus narrow.

A technical writer has to be able to rapidly and effectively
assimilate, organize, and convey information. To put it in more human
terms, a technical writer has to be able to do three things:

1) Learn on her feet.
2) Put herself in the reader's shoes.
3) Get the message across to the reader.

Those tasks break down of course:

1) Learn on her feet.

You have to be able to tackle complex, technical topics from a standing
start. Aside from the obvious (good study skills, etc), you need:
a grounding in the heuristics of learning.
good interpersonal skills to handle people in an interview.
good interviewing skills to handle information in an interview.

2) Put herself in the reader's shoes.

Once you've acquired the information, you need to be able to deliberately
(but only temporarily) FORGET the information. You need to be able
to pretend that you're the user, that you don't know anything, and
figure out what questions will occur, and when.
One of the things that results from this stage is the organization of the
material, the structure of the document.
Part of putting yourself in the reader's shoes is knowing who the reader
is, being able to do audience analysis - at least knowing the right
questions to ask (Who is this for? What will they be doing?)

3) Get the message across to the reader.

Obviously you have to take all of that meaning and transmit it clearly.
This includes micro- and macro-organization of your document,
writing style, the ability to step back outside yourself and
look at what you've written, familiarity with the language, etc.
This also includes being able to use your tools. Not just familiarity
with software, but the ability to quickly become competent with
the software as necessary (refer back to step 1, learning!).
You might also include project planning and management here, and
familiarity with the tools for that, like document plans,
feasibility studies, status reports, and so forth.



This is only one approach, and it's rather narrowly focused at
that. I'd really like to hear from some of the list members who've
been at it for a decade or two. Sometimes I feel like we're an orphan
industry.

Steven J. Owens
uso01 -at- unidata -dot- com


Previous by Author: (2) authoring tools
Next by Author: Translation, International Documents
Previous by Thread: More ASI Info
Next by Thread: Translation, International Documents


What this post helpful? Share it with friends and colleagues:


Sponsored Ads