How Help Files Don't

Have you ever noticed how some Help files in programmes are excellent and others are useless? I became intrigued by this and wondered "why are some Help files helpful and others not?" - or to use the NLP approach "how do some help files help and how do others not help? What are the differences in structure?"

A poorly designed Help file can create bad feelings towards the program, I know some people who have rejected programmes after suffering particularly bad Help files. Used effectively the Help system can help build and maintain brand loyalty amongst customers. It can also enable and empower users by helping them to use technology more effectively and more enjoyably.

Having interviewed several computer users, both expert and novice, about their experiences of learning and of Help files I came to the following two conclusions:

Help files are helpful when they are written and structured in a way that matches the way people learn and are unhelpful when they are structured in a way that does not match with the learning process

Help files are helpful when they avoid interfering with the learning process and are unhelpful when they interfere with the learning process

Before thinking about the strengths and weaknesses of Help files, let's think about the question "how do people learn?" They construct, piece by piece, a mental model of the thing or process they are learning. In the case of a computer program they build a model of what the program does and what facilities (menus, buttons, dialogue boxes etc.) makes the program do certain things.

As someone learns they are engaging in the process of acquiring pieces of information and putting them into their mental model. Let's consider how someone learns about using a menu in a computer program.

Firstly they would need to know what they wanted to make the computer do. It might be to display the current date. This is an action or result that they are already familiar with. Next they would need to see the menu. In order to understand what a menu is it might be likened to a restaurant menu, a list of choices. The learner can then start to form relationships between the menu and the result. They would then need to see how to use the menu, maybe by pressing keys on the keyboard. This would clarify how the menu is related to the result. This process works best when the learner has positive and resourceful feelings towards learning.

This is the process of building understanding. The learner finally understands something when they fulfil three conditions.:

they have matching models of the menu and the menu actions in all three major representational systems (a visual model of the menu and the result, a name or auditory anchor/representation for each item and action, and a resourceful kinaesthetic anchor for each item and action)

all the items in the model match to items already in the learners experience

there are no unanswered questions

This is expanded further in the section on The Model Of Learning And Understanding.

So how do some Help files manage to so successfully avoid being helpful? It's all to do with structure and language, which is why I found NLP so useful in analysing this problem. I've encountered six ways in which some (not all, but many) Help files are structured in an inappropriate way.

Firstly, and it seems that many of the Help files I've had to suffer using recently made this mistake, they never explained what the program (or function) was intended to achieve. A mail gateway program Help system never explained what the program was supposed to do. This would confound someone whose preferred strategy was to start with the big picture and chunk down.

Secondly, many Help files use words without explaining their meaning, and learning stops as soon as the learner doesn't understand one word. An Internet news-reader I used explains how to subscribe to a newsgroup, without explaining what was meant by the word subscribe, in fact in never explained what a newsgroup was.

This is inappropriate since the action or item referred to might not related to something in the learners' previous experience. Without this reference it is much more difficult to understand. How much more difficult would it be to learn to drive if you didn't know what a car was or what it did?

Thirdly, as a consequence of this lack of explanation there can also be gaps in one or more of the models, maybe the learner has seen something but doesn't have a name for it, or knows a word without knowing the object it refers to. Understanding is much less likely to occur if the models mismatch. (This relates directly to the need for isomorphism in the structure of many metaphors in order for the metaphor to be effective.)

Fourth - many Help files seem structured in the same way as the menu structure of the program. This is not how someone learns to use a program. As an analogy consider learning to drive a car, few people master the steering wheel completely before learning the gear shift. Most would gain a basic competence with steering, gears, brakes and navigating and then move on to learn the finer points.

With a word-processor it is more effective to learn basic text entry, saving files and opening files than to learn all the options on the File menu (such as templates, network routing and page set-up) before learning how to edit simple typing errors.

A pertinent question for the Help file author is "am I writing a system to help people new to this program gain skill and ability, or am I simply writing a brief description of the menus?"

Fifth - even those writing a brief description of the menus manage to write unusable Help files by committing the Second mistake, without realising it. In a mail program you might want to know how to change the network connection settings. If the Help file refers to the TCP/IP settings and Winsock without defining them this would be, for many people, a useless description - even thought the Help file has defined them elsewhere.

One of the benefits of a hypertext system is that the learner can jump in at any point, it also means that it is easier to miss the introduction to a section. All sections of a Help file should assume that the learner is starting from scratch.

The sixth and final point is that many Help files require the learner to follow as many as five or six links before arriving at the text of the help topic. As described earlier, learning is a process of constructing a mental model and this requires the learner to be in a specific state.

Having to shift awareness to navigating through this many links interrupts the model creating process, or worse, the actions of navigating might even become part of the mental model of carrying out the action being learned - leading to total confusion.

For example, if the learner was using the Help system to learn how to turn on an Autosave function and have to navigate through several links, such as "File Functions" and "Save Features", (which differed from the menu choices required in the program, which might be "Tools" and "Options") the learner may well end up not being able to remember whether they went into the "File" menu first or the "Tools" menu.

Designing a helpful and robust Help system is not a job that can be left to a programmer as a quick task at the end of the project. It is a skill and a role to be taken seriously.