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.
What is your process early on? Do you prepare an outline, or work from
the design documents?
Do you prioritize your topics?
What development model do you support? Are the products you work on
entirely new, or are you playing "catch up" and updating prior docs
for prior product versions?
It sounds to me that if you begin by getting your mental arms around
what the product is to do and how it functions in doing it, then
create a targeted outline that is logical and complete, you will write
from the position of knowing the direction you must take throughout
the project.
Using this kind of outline, with all the topics identified and a basic
understanding of how they interrelate, the writing begins to be more
automatic.
For many, simply "diving in" too early is counterproductive.
If you are working with a product that is a new version release of an
existing product, an analysis of existing docs for the previous
version is often helpful...especially if the product is new *to you.*
On some projects, I have begun with a careful examination of the
product in whatever condition it is in when I begin...with a version
upgrade, often that means becoming familiar with the previous version
first. I take notes of things that strike me during this phase, for I
realize that being new to a product is a gift if I am to write docs
for new users. Many of my initial attempts to use the product must
have some of the same questions involved that users confront every
day. If, for example, I have a problem that is not in the existing
help system and/or user guide, I make a careful note to consider
including its resolution in the new docs.
In a development group, much depends upon the methodology being used.
Since this is largely involving software documentation, a good grasp
of the development methods is needed if I am to fit my doc plan to the
development schedule.
During very early phases of a project, I also seek information from
customers...folks in the field, to determine what problems they must
solve. I have noted many times that no matter how advanced a developer
might be, there is often a disconnect with the way they view the world
and the viewpoint of the users engaged in their own business. In fact,
business knowledge is rather spotty in the developer community!
Thus, I seek to develop as much of a feel for the user's viewpoint as
possible. I work to understand any requirements documents with a
comprehensiveness that will make the questions later when examining
the product include "how has this objective been met in the
product...and *has it* been met?
I also make use of this early phase to become familiar with tech
support issues for existing product versions...another means of
understanding what problems confront users in the real world.
As portions of the product become usable and I begin to work through
them, I seek to understand what parts of the development plan and
requirements documents these portions address, and what user concerns
are involved as well.
If you work within an iterative development environment, especially of
the "extreme programming" variety, you should see the thorniest
problems solved early in the process. This may or may not translate
into large documentation issues...but it means that if properly
implemented, you may have less rework to do later in the development
cycle.
In additon, in this approach you should be working from very early on
with the test engineers. A hallmark of this kind of development is the
"test early and often" approach. Since you will also be running any
software as soon as it is available, you can develop a very positive
interchange with the QA people for your mutual benefit.
If you are in a more tradiitonal "waterfall" development environment,
you must rely more fully on the requirements documents and the
development plan to understand the product before a time much more
compressed before launch. In addition, mistakes made early in this
situation are often reflected in rework that changes many details of
the product...so be prepared for this to happen and be sure you are
"in the loop" for any changes throughout the process.
By the time the actual writing of the topics happens, in either case
you should be well enough on top of the product and how and why it
should work that you will have a level of mastery required for your
faster writing speed. With any luck and practice, you should find this
point happens much earlier in the process than you are used to, from
your description.
Personally, I have the opposite problem: I am a very fast writer, and
I must always work carefully to be sure that I edit and condense in
the best possible way...rather than going on at too much length.
(These posts, for example, are usually composed at 80-100 wpm or so
and the lack of logical organization may reflect the fact...)
The solution, though, is for me much the same...develop a good working
outline and work from it to be sure that everything is organized and
logically developed and presented.
ROBOHELP X5 - SEE THE ALL NEW ROBOHELP X5 IN ACTION!
RoboHelp X5 is a giant leap forward in Help authoring technology, featuring all new Word 2003 support, Content Management, Multi-Author support, PDF and XML support and much more! View an online demo: http://www.macromedia.com/go/techwrldemo
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
