Need to write a user manual, but don't know where to start?Our handy two-part guide takes you through the process, explaining theimportance of proper planning in the early stages and demonstrating howto build a consistent and usable stylesheet for document formatting.
Depending on who you speak to, documentation is either the best part ofa software project...or the worst.
Most developers wouldn't be caught dead writing a user manual - theymuch prefer spending their time building better, more efficientalgorithms. Their users, on the other hand, don't really care about thecode that powers a software application; they're more interested ingetting their work done quickly, with minimal errors.
That's where support documentation, in the form of a user manual, comesin. Usually considered one of the least important deliverables, it isslowly coming of age, as software companies begin to realize the valueof high-quality documentation that answers most user questions andreduces after-sales support calls (and expense).
Support documentation allows the user to use the delivered software withease and efficiency. Ideally, it comprises:
Interface text: The labels on interface elements like menu items,fields, instructions, confirmations, error messages et al.
Application messages: Operational error messages and warnings.
Online documentation: Online help, tutorial and searchable helppages.
Print documentation: User manual and technical reference manual.
These, in totem, are the user's support system for usage of thesoftware.
This article focuses on the user manual, explaining, from a technicalwriter's perspective, the process by which such a manual is developed,reviewed and delivered. I believe, though, that the process and planningtips are generic enough to apply to the other print documents, inaccordance with both their purpose and scope.
/ 40 
