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: What does a tech writer do? From:Kathleen Padova <kpadova -at- ASICENTRAL -dot- COM> Date:Tue, 9 Sep 1997 11:55:00 -0500
<snip>
>Others have done both user and tech doc, and I would like to hear how
>this is done.
I am writing both specifications documents _and_ user doc for software
applications. I actually insisted to be involved at the proposal/specification
writing stage of projects becuase by the time I would be assigned to write the
user doc for a project, the project was an information nightmare. I claimed
that 75% of my time was taken up by rewriting user documentation because:
Information was late in coming.
Some features/functionality weren't documented ANYWHERE and I hadn't
stumbled across it while playing with the application.
Unbeknownst to the Project Manager (or anyone else), the programmer was
adding things he/she thought would make the application a better project.
The project overview documents were not always updated or contained
complete information. Often I would describe a feature that had changed
(been axed) and only 3 people knew of the change.
Sometimes development and the project manager had different ideas of what
an application was going to do.
Yes, this indicated a greater problem. I decided that as someone who was
supposed to know alot about effective communication I could do something about
this.
I offered to write and maintain a specifications document at the start of a
project that would contain enough information for the other members of the
project team to do their job or at least ask more questions. It was also
important to document all functionality on every screen (even the text on the
title bar) so everyone working on the project knew exactly what the end result
should be.
Often, writing specifications documentation is tedium for me; but writing the
user doc later on is soooooo much easier.
What I hoped to prove was that the actual time spent writing the user
documentation would drop because I had already understood the purpose and
planning of the project. And I had pretty much written everything already.
I haven't been able to measure the success of this document in terms of time
saved yet. Mostly because the projects I started writing specifications
documents for were preexisting and I had to spend alot of time sorting through a
mass of old information. And none of the brand new projects I'm working on have
been completed.
However, many people in other departments have now come to expect such
documentation and offer advice about what would make it more useful to them. The
first time I went to a project meeting and everyone showed up with a copy of a
spec doc in hand I just about fell out of my chair.
My 2 cents,
Kathleen P
kpadova -at- millstar -dot- com
My opinions, not Millstar's.
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
