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

[Steve Owens <uso01%eagle -at- UNIDATA -dot- COM>]

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