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: Establishing a documentation process From:"Susan W. Gallagher" <sgallagher -at- EXPERSOFT -dot- COM> Date:Tue, 12 Mar 1996 10:55:25 -0800
Geoff Hart wrote:
> After months of nagging, I've finally convinced Management
> to create a structure for producing documentation for our
> software...
[snip]
> Here's the simplistic outline that I'd like you folks to
> help me fill in, modify or otherwise debug (I'll try to
> participate in each stage, right from the start):
> 1. Define product features
Formalize target market and target audience profile.
> 2. Create mockup of user interface
Create documentation plans including outlines for
paper manual and online help/doc (if any).
Decide whether online or paper-based tutorials are needed
and create formal outlines for them, too.
> 3. Begin documentation of features and interface
> 4. Freeze features/interface (if not already done)
This should be an interim freeze -- allow yourselves the
liberty of integrating changes suggested during beta phase.
> 5. Complete documentation
(...for beta)
Participate (with marketing and product development)
in developing a questionnaire for gathering beta feedback.
> 6. Begin beta testing
Collect beta feedback. Call beta testers for qualification/
clarification of feedback comments. Remain in close contact.
See if you can get to a beta site (perhaps there's one close-by)
to watch users install and use the software (this is the
beginning of usability testing!). Concentrate on areas of the
software you're uncomfortable with and collect user comments
while they figure things out. Suggest UI changes based on
feedback.
> 7. Revision and final distribution
Formalize list of UI changes & bugs based on user feedback.
Schedule UI changes and bug fixes, new UI and code freeze
dates, and completion dates for paper and online doc.
Good luck with it, Geoff!
-Sue Gallagher
sgallagher -at- expersoft -dot- com
