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:Re: Doing New Things New Ways From:Karla McMaster <mcmaster%pcmail -dot- cti-pet -dot- com -at- CTI-PET -dot- COM> Date:Thu, 14 Jul 1994 16:21:48 EST
Way back when (June 27--I've been on vacation) Mindy Kale wrote:
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.
Two jobs ago I was deeply involved with the development team--to the extent
that I was writing functional specifications for some things--and definitely
influencing the design for others. I also made myself responsible to keep the
marketing and training departments up to date on what the product looked and
felt like (sometimes I did informal train the trainer sessions with preliminary
documentation). I found this type of work--in the design phase of the product--
to be the most satisfying (and hardest) I've ever done. I'd like to get there
again. Unfortunately, in most of the places I've been, technical writing is
regarded with less respect (almost, but not quite, as bad as the glorified
typist Mindy mentioned). In addition, I've come into companies who are behind
on documentation. I have to catch up (and earn the respect of the developers)
before I can get into proactive mode. Once I do, though, look out. I've got
even more to contribute than writing manuals (as if that weren't enough!).
Karla McMaster, technical writer
CTI PET Systems, Inc., Knoxville, TN
mcmaster -at- cti-pet -dot- com