Home - Contact Info - Articles
- Files - Links - Adventures - Other Stuff
What do I mean by content? It's the information - the main reason for your help file's existence. The
most beautiful and easy-to-navigate help file won't help a bit if the information is just plain wrong.
This information must be tested to insure its correctness. One way to accomplish this is to have a technical
Every topic that describes how to use the program's interface should be reviewed by technical personnel.
Typically, this would be an interface designer, software engineer, and/or support tech. The goal of this
review is to make sure the critical information on how to run the application is presented accurately.
Another good way of testing content, particularly procedures, is to try them out on a non-power user.
They don't even have to run the app - just have them read the procedure and tell you if they think they
can follow it.
Many help files contain topics best described as marketing fluff. These topics, ranging from product information
to company backgrounders, should of course be reviewed by a marketing, public relations, legal, or executive
Most authoring tools have spell checkers built in, but you wouldn't know it based on some of the help
files I've seen. Yes, the user can work around a typo, but how much reliance are they going to place in
information presented by someone who ought to know better? Unfortunately, spell checkers can only go so
far - the word may be spelled right but be in the wrong place, or it may be the wrong word. Grammar checkers
can detect some problems, which brings us to the best way to test content - peer review.
Some help authors work in a vacuum. Many, however, are members of small teams. Each team member should
review each others work. It needn't be a formal review - informal is fine as long as the help system is
improved in the process.
Multi-author projects often suffer from too many styles. This is where a style guide comes in handy. Your
company may already have a style guide for things like internal documents, press releases, or printed
documentation. This guide should be expanded to cover online help.
The style guide should cover, among other things:
Preferred fonts and sizes
Styles for various purposes
Method for creating or capturing graphics
Methods for describing actions such as selecting, choosing, or clicking
Following this style guide, and testing to make sure you're following it, will result in a much more consistent
Copyright © 2009 by Dana
Last Updated Monday, April 06, 2009
Website hosted by 1and1