Writing A User Manual (part 1) (Page 1 of 5 )
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.
Next: Step By Step >>
More Practices Articles
More By Deepa L, (c) Melonfire
