Doing New Things New Ways

[Mindy Kale <gpscom!mkale -at- PLAINS -dot- NODAK -dot- EDU>]

Caryn Rizell wrote:

It is essential that
tech communicators get involved at the very earliest.  At a
previous job, we writers were helping design the product.
This was a result of several years efforts to move us up
in the development process.  When I started there, we wrote
the documentation from the product as it was being developed
and had to make changes over and over. As the rest of the
company saw what we had to offer (QA, UI design, user
perspective) we were allowed to become involved earlier and
earlier.

I know, however, that some writers were not too thrilled
about the idea of earlier involvement because it meant
'more work'.  They just wanted to write, not be involved
in anything else.

But, in my view, it made my job easier and allowd others
outside the department to see what we could offer, increasing
our value.

So, for me, the question is not 'Should technical communicators
be involved?', but 'How to get them involved?'

There are still many employers out there who do think of
writers as glorified typists (evidenced by the classified ads)
and are reluctant to let communicators 'be all they can be'.

It would be interesting to find out the numbers of us who
are involved early in development vs those who are still
having to wait to get info until the very end.

***

Our technical writing department recently reorganized to be called Design and
Documentation Department. It now includes not only writers and editors, but
product designers. Some of our writers are now responsible for writing
functional specifications as well as product documentation. Some writers think
this is just requiring them to do more work, but overall most people think it is
beneficial because it gets writers involved in the design process, and by the
time they are ready to write end-user documentation they know the product well
and can save their time as well as programmers' time doing research. I think
it's a good idea, but it requires a commitment from the company to give the
writers extra time on each project. If your company wants to quickly move
writers from one project to another in the middle of projects, it won't work.

As a writer I found the projects that were most successful were those where I
was involved from the beginning and where writers and programmers worked
together closely. In addition, specs can be more complete and writers may be
able to write from spec. In this case the writer often saves the entire team a
lot of time and money because the writer finds design flaws before time is spent
coding it. For example, when writing for the end-user, I would find myself
trying to explain complex procedures or procedures that didn't seem to make
sense. At this time programmers and managers could be made aware of the problems
and the software design could be changed. Very often, if a procedure is
difficult to explain, it's probably also difficult to use and should be changed.

Just a few of my observations.

Mindy Kale
Great Plains Software