LogicSmith

 Home  - Contact Info - Articles  - Files - Links - Adventures  - Other Stuff  - Dual Monitor Wallpaper

Test the Content

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 review.

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 person.

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 help file.