by Donna Timpone (New York Metro Chapter) timpone@useredge.com

I don't care what the end-users want--it's got to be in HTML!

This was the response from the IS manager when, after weeks of end-user focus-group sessions, I offered him a prototype of a revised design for their online documentation. The user community had been enthusiastic about the prototype, which was not in HTML, but the IS department could not see beyond technology to usability. This would prove costly. The HTML solution they chose, while providing a powerful search engine, did little to improve the end-user's performance.

In 18 years as a human factors consultant, I have never failed to observe this pattern. As a technology is introduced, the focus is on the technology itself--the tools, the features, the promises, the hype! There's typically lots of hoopla and gee-whiz excitement. But when the enthusiasm wanes (often the result of a reality check), there is a shift from the technology to what I call the psychology behind the technology. This shift to end-user concerns and usability issues is essential for effective help system design.

In fact, it is happening now as organizations struggle with Windows help systems. For the last few years the buzz has been about which WinHelp development tool to use (RoboHELP, Doc-to-Help, ForeHelp), how to incorporate the Windows 95 WinHelp features--or more recently the WinHelp-HTML capabilities--and most important, how to get rid of the printed documentation altogether. But the novelty is wearing off, printed help manuals have not disappeared; and lots of frustrated users are surfacing. Help developers are now asking, "How can I make sure that users will use the online help?"

After considerable trial and error, I've come up with a checklist that can help you evaluate and improve your help system. Each question represents an important usability issue.

Does my help system fit into an integrated performance support strategy?
One of the first things I look at when evaluating a help system is the degree to which it is integrated with the application's overall support strategy. If it is simply a shorter version of the printed manual and there is little or no cross referencing among the training materials, any remaining printed documentation, and other online support (wizards, coaches, reference), I know there's going to be a problem.

A well-designed help system is integrated with other support options. For example, a wizard can be linked to a related help topic and a help topic can reference a related chapter in the printed manual. A cue card can step the user through a procedure and also provide links to an associated quick tour. And if there is classroom training, the help system can be introduced and used during the online exercises. When the help system is integrated into the overall performance support strategy, it becomes part of a seamless support interface for the user.

Performance support options in turn must be matched to user needs. Many designers put all of a product's support for very novice users in the help system. Nothing is more intimidating. If your users are new to the windowing environment and have never used a mouse, you are setting yourself up for failure if you expect them to immediately start clicking on your hypertext jumps and be happy about it. One of my clients in the telecommunications industry had a major customer refuse to use the application because of the online support. After escalating the matter to my client's upper-level management, the customer demanded the return of the paper manual. Remember that novice users are easily frustrated and require a certain amount of hand-holding. They feel secure with their printed documents, even if they don't use them.

A well-planned support strategy is essential--one that maximizes the strength of each performance option and avoids its limitations. I don't recommend putting large amounts of conceptual/training information in a help system, for example, because it forces users to scroll through paragraphs of dense text. I have found that help systems are good for short-term memory items, such as questions that arise when performing a task. This is quick, concise in-out information. Online tutorials and classroom training, on the other hand, lend themselves more to long-term memory items and complex conceptual information. This information needs to be more interactive--whether that is person-to-person or person-to-online medium.

The more "active" your online support (the less scrolling and reading of online material), the more likely your system will be used.

Does my help system anticipate the right questions?
Help systems often suffer because they do not contain the right information, which means that users can't find answers to less obvious questions. I hear this complaint more than any other during usability debriefing sessions. Many help systems address primarily simple and obvious tasks; in many cases users don't even need that information because the procedure is self-evident. Some questions--a quirk in the interface or an unusual combination of tasks--can really hang users up. When the answer is nowhere to be found or is buried as a note in a simple procedure, users have a double problem they don't need.

I recently called a popular product's hotline after spending several hours trying to solve a printing problem using the online help. The technical expert gave me the answer immediately--it was obviously a common problem. When I asked why, if the problem was so common, it was not addressed in the help system, the technical representative had no response.

So how do you know if your system will be able to answer user questions? First ask yourself, "Did I develop the entire help system alone in my cubical or office?" If so, you've undoubtedly done a great job of describing all the product's features, but your end-user hotline will be lighting up from dawn to dusk. Sadly, most organizations allocate time for little else in the way of help system development and realize too late that a more responsive help system could also have "helped" the product's reception.

Determining the right content starts with understanding who your users are and where the product fits into their overall job. The best way to gain this understanding is to examine the types of procedures the help system includes. Do they describe real-world tasks (moving a paragraph) or are they more like computer tasks (cutting and pasting text or graphics). Real-world tasks tend be procedural, combining commands; computer tasks tend to be single commands. You can include computer tasks in your help, but be sure to augment them with plenty of real-world tasks.

For example, one help system I evaluated had tasks that described every feature of the tool such as "setting up a view" and "using a filter." That was fine except that these tasks had nothing to do with the end-user's job. After a brief analysis, we uncovered tasks that were more meaningful, such as "setting up a weekly itinerary"--tasks that would help make users productive from the very beginning.

You also have to anticipate the types of questions users will ask, an activity that often brings out problems with the user interface. You can use many techniques to collect this information--focus-group sessions, critical incidents, and exploratory and think-aloud protocol testing. The objective for all these techniques is to get inside the user's head.

Are my users getting "lost in hyperspace"?
A usable help system should have a structure that is intuitive and apparent to the end-user. When evaluating a help system's structure, I draw a detailed diagram or flowchart. This tells me a lot immediately. If the structure starts to look like spaghetti, I have an overly complicated help system that most users are going to use once and never return.

The overall goal of a help system is ease of use. A structure that is too complex leads to frustrated users who not only don't want to use the help system but may also reject the entire product.

There are several ways to make your help system's structure less complicated. One is to minimize levels. It is better to bring options to your users than to make them go several levels deep. You can do this using pop-up windows, collapsible/expandable lists, and secondary windows. You should also use jumps judiciously. For example, make yourself justify each highlighted jump. Ask yourself why the user would want to follow that particular path and whether it would be worth the trip.

The structure should also be consistent in the way it displays similar information. That is, if you define a secondary procedure window, be sure to display all procedures in it, rather using several different procedure window types.

Finally, a visual map of the help-system structure is invaluable. At a single glance the user can determine where they are and where they want to go.

Does it take more than three clicks to get an answer?
Users must be able to access information quickly. I follow the "three-clicks" rule in defining user tolerance: no more than three clicks to find the answer to any question. This rule applies to access from the application, the topic menus, and within the help system.

The first area to examine is whether users can easily access the help system from the application. Can they access help from anywhere in the application or must they always use the pull down help menu? I find that including a help icon on the application's toolbar, help buttons on both dialog and message boxes, and context-sensitive topics ensures that help is always in the user's face. The more "in-the-face help" you have, the more likely the user is to use it.

Next, look at your topic menus. How easy it is to scan them dictates how long users will take to find the answers. Menu lists that span several pages simply don't work. Use your knowledge of the user's job to group and organize items in a way that make sense to the user, and test these out. If there are sub-menus, try to limit them to three levels deep.

Access strategies are also important in following the three-clicks rule. The help system must be able to anticipate how users will search for information. Provide alternative menus to access topics. For example, both a command menu and a task menu to search for the topic "moving a paragraph." Try to anticipate likely reading paths by showing related topics. And take the time to do effective keywording. Keywording topics by nouns and also using synonyms increases the probability of finding the desired topics.

Are my windows designed to optimize performance?
Window design is not designing pretty windows. It's making design and layout decisions that optimize user performance. I have found topic clutter--overloading the user with information--to be a major problem in many help systems. It takes 20 to 30 percent longer to read on screen than in print, so you must minimize text. Requiring users to scroll through multiple screens is guaranteed to frustrate them.

Research recommends 65 percent text density (35 percent white space) for topics designed to be scanned and read. Figure 2 shows a before-and-after view of text density. One way to reduce text density is to layer information using pop-ups and jumps. Another is to display information in chunks (maximum 3-4 chunks per screen), highlighting them appropriately.

Successful help systems use different window sizes for different kinds of content. For example, procedure topics are often displayed in long, narrow windows that stay on top so the user can easily read and apply the information. Overviews are displayed in short, wide windows to accommodate more explanatory text and graphics. And glossary/definition topics are displayed in small windows, often as pop-ups. I have found that using distinct and consistent templates conveys information to the user even before they begin reading the topic.

The use of color is another way to improve usability. Remember, however, that reading colored text takes longer and is more prone to error. So try to make sure that color choices convey information rather than being merely for aesthetics. Choose colors that provide good contrast--black and white has the best contrast. Avoid using conflicting colors like red/blue and opponent colors like yellow/blue, red/green, and green/blue. Finally, make sure you use double coding for monochrome users and color-deficient users (i.e. underlining and green text).

To insure that the text is legible on the computer screen, use simple typefaces--sans serif 10-12 pt. for normal text and 12-14 pt. for headers. Avoid long passages of text in all uppercase and keep your line length short (fewer than 50 characters per).

I've observed that developers have a tendency to overuse highlighting (such as green underlines), which can impede readability. Try to keep highlighted links to less than 10 percent for text topics, and don't feel obliged to code menu items with color and underlining.

Are the topics self-contained and easy to read?
Writing online topics is not the same as writing for print. Because users can access topics in any order, the topics must be self-contained. Review your topic text to remove phrases like "earlier you read" and "as shown above." Also make sure the text does not assume the user can see a particular graphic.

Because the screen is significantly smaller than an 81/2-by- 11 page and is less legible, topics must be concise. Review and edit your topics to reduce the number of words. Really be ruthless and cut out any nice-to-know information. It also helps to keep paragraphs to a maximum of six lines and use bulleted lists wherever possible. Graphics and tables can also be used to reduce the amount of text.

I have also observed that the poor screen legibility makes it easy for users to overlook small words and phrases (e.g., "if," "not," "all," "any"). Review your topic text for words and phrases that, if missed, might significantly change the meaning of a procedure step or description. To help prevent users from overlooking these words, highlight them using color, italics, all caps, or some other appropriate method.

Last, be sure your text does not humanize the computer. Use words that apply to computers, not people (e.g., "store" instead of "remember", "process" instead of "think".) Some help developers anthropomorphize when writing online, which can lead to confusion. One help topic used the phrase "tell word processor Z to…" Some users thought this was a voice response system and kept saying the command to the computer.

Summary
The more time you were given to develop your help system, the more likely your system can pass the evaluation contained in this checklist. I've seen as little as two weeks and as much as two years allotted for help system development. If organizations are really serious about supporting their users, they will want to invest the time to do it right. Armed with these checkpoints, you have a systematic method that emphasizes the psychology behind the technology and may make the difference between satisfied users and frustrated ones.

Copyright C) 1996, Donna Timpone. Donna Timpone is president of UserEdge, Inc., a New Jersey-based human factors seminar and consulting company that specializes in helping organizations create effective online documentation and electronic performance support systems (EPSS). She can be reached at UserEdge, Inc., P.O. Box 5202, Clinton, NJ, (908) 730-9164, or home page http://www.useredge.com.