re: Software Manual Overview

Subject: re: Software Manual Overview
From: Sean Hower <hokumhome -at- freehomepage -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 12 Jun 2002 08:09:00 -0700 (PDT)

Tom Green asked about what goes into a quality manual:

Here's a little outline of stuff that I like to see in a manual:

Introduction (short, about 2 or 3 pages)
--Brief description of the purpose of the software (I like this because if you end up turning the docs into help files, people who download a demo copy of the software will get a clear description of the purpose of the software, rather than the marketing description)
--Breif description of what the manual contains/doesn't contain
--Breif description of any conventions the manual uses

Getting Started
--Installation (could be as simple as "put CD in computer"
--Tutorial that gets the user performing an easy but common task. Make the explanations of what's going on a little more thorough than usual, this may be the only time the users ever read the book, so you might as well try to get some good info to them while you have the chance.

Reference Chapters
--Chapters that detail the interface, every field, button, switch, toggle, or smiley face. Personally, I like it when the reference is organized by related tasks (task-oriented), like the PhotoShop manual. You can also include how-tos for short tasks throughout the reference material.

--Longer how-tos that cover a range of tasks.

--UI reference
--File formats supported
--Support information, such as RGB values if you're dealing with graphics software (this is always a nice touch, and well appreciated by me)
--Any information that can be presented in the form of a table that the user might need at a moment's notice
--Contact information

--Error codes and meanings
--Known issues and work-arounds

--Including industry terms, software terms, synonims for terms, company terms that mean the same thing as industry terms, yada yada yada


For more information, check out the books I have listed on my web site
Try "Starting a Documentation Group" (haven't read it, but it seems appropriate to your situation), "Writing Software Documentation: A Task-Oriented Approach" and "The User Manual Manual."

Also, check out other manauls. Try using those manuals to accomplish tasks. Borrow the ideas that work, and ignore the ideas that stink on ice. :-) Also, take notes on your own learning experience with the software you're documenting. Jot down things that you had a hard time with, concepts that were particularly difficult to understand, or just plain out in left-field somewhere. Those are probably going to be the same issues your users have, so you might want to make a little more effort to include that information. Also, if there is already a user forum for the software, check it out. That might give you ideas of what to include and not to include. Be warned, forums are sometimes nothing more than whining sessions, so you should turn on your ...... well, your mental bs filter to extract the good information.......mmmmm, I apologize for offending anyone with that...but I just can't think of any other way to put it.

Hope that helps. Remember, when in doubt, check out what's already been done and see if it works. :-)

Sean Hower - tech writer

"Whatever you do, do NOT let your editorial decisions be made by the squiggly spell-checking lines in Word!" ~Keith Cronin, Techwr-l irritant ;-)

Create your own web site for FREE at

Promote your group and strengthen ties to your members with email -at- yourgroup -dot- org by

Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to

Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.

You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit for more resources and info.

Previous by Author: RE: When Good RoboHelps Go Bad
Next by Author: re: favorite technical style guide?
Previous by Thread: Software Manual Overview
Next by Thread: Help with Word templates and "conversion"

What this post helpful? Share it with friends and colleagues:

Sponsored Ads