Re: What else to tech. communicators do?

["Doug, Data Librarian at Ext 4225" <engstromdd -at- PHIBRED -dot- COM>]

Julie Fisher wrote:

**************************
I am really interested in this topic [Defining Technical Communication],
not as a practioner but as an interested researcher in the area of tech
communication and systems development. I would also be interested in
what other things tech communicators do apart from writing.  I know there
is more to the job such as talking with users about the system (user
advocate), training, managing the change process etc.  Your comments would
really help clarify the picture for me.
**************************

Since you asked...

An important role I have often played, both formally and informally, is to
make the decisions of the design team explicit so they can talk about
them; both to each other and to future users.  There are good ways and bad
ways to do this.

The bad way is to write end-user docs late in the development process, and
begin ciculating them for review.  In some cases, the light suddenly
flashes on and various interested parties realize for the first time how
the system is going to work.  They may also realize that they can't live
with it.  This usually produces a flurry of last-minute changes, much angst
in the design team and trepedition in the user community.  Since this
activity is often initially communicated as "some problems with the
document" (before everybody realizes it's "problems with the *system*")
it's good for a rush of andrenaline at tech pubs, too.

The good way to do this is to be involved in facilitated design sessions as
the "scribe."  (At least that's what we call it; YMMV.)  A facilitated
design session brings together the design team, users, and other interested
parties, like Data Administration and Technical Architecture folks.  The
session is run by a neutral third party trained in meeting facilitation
techniques.  The goal is to get everybody's ideas, feelings, needs,
affectations, wants, solutions, problems and whatnot out on the table; then
the group makes decisions about the system.

It's maddeningly time-consuming to do this up front, but not nearly as
maddening as doing it halfway (or more) through the development process.
Anyway, the scribe furiously records all this activity, court-reporter
style, during the meeting, and then creates a document that succinctly and
clearly describes what the group decided, how the group decided it, and
what the remaining issues are.  Typically, this goes on for several
meetings, each requiring a supporting document.  There may also be
preliminary documents to help participants prepare for the meeting.

Adding to the ocean of knowledge, one teaspoon at a time,

Doug                            "Women are designed for long,
ENGSTROMDD -at- phibred -dot- com           miserable lives, whereas men are
                                 designed for short, violent ones."
                                  - Estelle Ramey