Current software products are complex, and complex products require complex Help systems. Even simple applications come with hundreds of pages of documentation, and Help systems, and online tutorials. Despite all this information, frequently they are left standing on the shelf or deleted from the hard disk because people don’t read manuals or use Help. The reason they don’t is that often the documents don’t tell them what they want or need to know.
Because we cannot afford to produce information systems that nobody is expected to use, we must take care to design systems that provide useful information, that accommodate diversity, and that people actually use. That result is attained through effective design.
As you design your Help file, determine why users will want to read the information you provide. Four common reasons why people use Help are:
nFor reminders.
Many users refer to Help to remind them of something they have forgotten. For example, users frequently look up specific tasks and keyboard shortcuts.
nTo learn an application.
Novices and other users often choose Help to learn a new application. Because Help is perceived as part of the application, it is the easiest to access.
nTo find specific information.
Many users request Help only when they have a specific question. Often, they have tried to do something on their own first and were unsuccessful.
nTo explore.
Users sometimes browse the Help file just to see what’s there, following one topic to the next, gradually tracing a path through the information and building an understanding of it. Hypertext systems like Windows Help are especially compatible with this kind of use.
Almost all Windows-based applications offer Help. Despite its availability, many people have never used Help or have used it only occasionally. Usability studies show that users in test situations try Help once, and if they do not get the answer they are looking for, they do not try Help again. Why?
Three explanations are frequently offered for not using Help:
nAsking for Help often does not provide the right answer.
Users have a low tolerance for unhelpful Help, and if they don’t find what they are looking for, they frequently form a negative opinion of Help and never try it again.
nAsking for Help interrupts the user’s work flow.
When requesting Help, users must remember their original question, find the answer to it somewhere in Help, and then remember the answer when they return to the application.
nAsking for Help is disorienting.
The Help window changes the look of the screen and presents users with its own interface and feature set, which users must master to find information. Frequently, users forget the question that they had when they are forced to learn how to navigate through Help screens.
These three problems are more severe for less-experienced users. Experienced users are more comfortable with Help. They are less worried about getting back to where they were, they are more likely to remember what they were doing because it is more familiar, and their expectations are more realistic (or more pessimistic, depending on their previous experiences with Help).
Most of us are driven by motivations of one kind or another. Users are no different. Their primary motivation is finding answers to questions, solving problems, or learning new skills. Given that, our motivation as designers should be to make certain that users get what they want.
What each user wants varies, but all users seem to share some general expectations. They want:
nHelp to function interactively.
nContext-sensitive Help.
nTo keep their application in view while they are using Help.
nHelp to explain the consequences of their choices.
nInformation about Help itself.
nSummary information about the application (quick reference).
nConceptual information about the application.
Most users want Help to answer very specific questions, but the question depends on what they are doing and what the computer is doing. Their questions are shaped by their immediate tasks. They want Help to be an expert that knows their situation and what information they need to continue.
Providing Context-Sensitive Help
Users want context-sensitive Help because it is convenient, saves time and effort, and is more likely to keep them from overlooking something important. Providing context-sensitive Help is one of the best design decisions you can make.
Users expect the computer to be user-friendly and to behave the way people do. When they ask for Help, they expect the computer to be aware of what has been going on, and they are therefore impatient with irrelevant Help. In fact, users believe that the computer does “know” but often refuses to help them.
Users do not expect context-sensitive information from books; they expect to find information in a book on their own. On the other hand, people expect Help to know their context, to interpret their request for Help in that context, and to understand their questions. People’s impatience with Help and their unwillingness to try it again suggests that they expect Help to behave more intelligently than a book, and suggests that books are an inadequate model for Help because they lack context sensitivity.