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: Messages. . .and new thread From:sanders_j -at- TBOSCH -dot- DNET -dot- GE -dot- COM Date:Fri, 28 May 1993 09:46:50 EDT
Hi all,
Lisa Kaytes:
>I'm interested in finding
>out how other writers have made the transition from writing feature-oriented
>software documentation to process-oriented documentation.
Well, when I was working at a software firm a few years back, we had a very
large set of programs which made up some corporate accounting software. At the
time, everything was documented on a program-by-program basis, with the poor
accountants basically figuring things out as they went along, I imagine mainly
from the program names. When we moved to process-oriented documentation, with
an accompanying reference manual, we had to sit down and go through the system
in a way that would follow proper accounting procedures. In effect, we
simulated the tasks that the end users would have to accomplish and did them
using the software. A few weeks later, we started using the software for the
in-house accounting entirely, and found out all sorts of neat things (bugs,
mis-named programs, yucko reports, etc.).
Nothing beats usability testing in real time.
The manual started taking on a whole new form, and I started writing documen-
tation that reflected accounting procedures rather than program procedures.
A lot of that old documentation was still useful, especially in the reference
manual, but interweaved with the new instructions covering a wide variety of
issues over a number of programs, particularly system administration programs.
Since we had a division between the standard user and the administrative user,
we often had cues in the standard user text telling them that the admin would
have to be involved at a certain point, and in the admin text telling them
what overall system considerations were involved in making those changes, or
starting that process.
We also ended up explaining a lot more of the design of the system, and
explaining the theory behind the way the system was setup. I think a lot of
that helped. We also found that concrete examples were like gold in developing
a process-oriented manual.
Hey, I hope this helps. A lot of it seems kind of vague looking back, but I
hope you get the idea.
