In spite of the respect and attention we give to the sequential, numbered steps that tell users how to achieve a given task, that form of information delivery just doesn’t match the typical user’s information-seeking behavior.
User Behavior
Two principles best describe how people use Help:
- People don’t go to Help unless they feel stuck.
- People stay in Help only until they feel unstuck.
It takes a surprisingly short amount of time for a user to feel unstuck. When I was a usability consultant, I used to advise clients to put the critical information in the first three words of a sentence. Here’s an example that demonstrates why this is important: The message “Create a directory for your XYZ product or click OK to use the default directory” often resulted in users unnecessarily creating a new directory and complaining about having to do so. The alternative, “Click OK to use XYZ product’s default directory, or if you want, create a new directory” was much more effective. Users often clicked OK without reading the whole message and suffered no harm—in fact, they did what the software developer preferred.
The three-word rule might seem restrictive, but it reflects the fact that good technical writers start instructions with a command verb that is closely followed by its direct object. Therefore, readers often have enough information to take action within three words. Unfortunately, that does not mean they have enough information to take the correct action.
A striking illustration of this fact came from a usability test I did, during which users installed a modem in a notebook computer. In one case, it was essential that a user load an installation diskette before inserting the modem into the computer’s card slot. Step 1 on the Quick Installation card was explicit about this requirement:
- Install the Modem Installation diskette before doing anything else.
One user read this as “Install the modem,” immediately quit reading further, and inserted the modem card into the card slot. To solve this problem, the writer reworded the instruction to say “Insert the diskette labeled…” This demonstrates how quickly users shift from reading documentation to doing something with a product. If they are this willing to abandon reading an instruction in mid-sentence, what hope is there that they will read an entire procedure?
Users’ Behavior Versus Procedures
There are some some basic mismatches between users’ behavior and the characteristics of procedures, as Table 1 shows.
| Users… | Procedures… |
|---|---|
often have already begun a procedure, then get stuck and finally need to go to Help |
start at step 1, requiring users to read—or at least skim—information that has no value to them in solving their current problem (See The MapQuest Phenomenon later in this column.) |
might need to know only an important principle or rule to successfully complete a task |
embed principles and rules within specific steps that require them, so users might miss them if they skip that step |
are often in the wrong place in a program to perform a task when they refer to the documentation |
often assume users are in the correct place to perform a task, so users might try to follow a procedure from where they are with undesirable results |
might already have done something wrong that precludes the possibility of their successfully completing the procedure by following the instructions |
often assume the right conditions for performing a task are in place, with the result that the instructions seem wrong to users and frustrate them |
want information in the smallest chunks possible |
deliver information about an entire task at once |
Note—The last characteristic summarizes the basic mismatch between users’ needs and procedural characteristics: Users don’t want to know the whole answer; they just want to know the small part that has them stuck.
