People are funny when it comes to instructions, particularly when those instructions come from a perceived authority. People tend to follow instructions no matter what, even when they are being told to do something that seems illogical. There’s a silly sign I once saw that read (first in type and then handwritten):
Recently, robbers were able to “break into” an office building in Rhode Island by posting a sign on a door that read “Please do not lock this door tonight.” No one locked the door that night, so the robbers casually entered after hours and took what they wanted.
When it comes to computer-user interfaces, instructions can be even more compelling. People not only perceive instructions as coming from some authority that they can’t (and aren’t even able to) question, but also their lack of understanding of the rationale — plus the fear associated with not obeying — often make these instructions seem almost sacred. This is not based on a lack of technical understanding. In fact, technical understanding can make this even worse. Consider the following example.
Years ago, when my firm was testing voting systems for the National Institute of Standards and Technology, we ran a pilot of our protocol. The purpose of the pilot was just to test our procedures, instructions, and data collections methods. The test involved asking people to vote for specific names and to choose specific Yes or No responses on referenda that were provided to them on paper, in the order in which they would appear on the ballot. There were no trick tasks and no intentional errors in the instructions. There was, however, one very small exception. On one of the multi-member races (where you can vote for more than one person to fill all vacant offices), we provided the names of only three of the four possible names running. This is an intentional “under vote” in a multi-member race.
We recruited only four people and had not expected to get any useful data about the interface designs from the pilot test. What happened surprised all of us. One of the four ballots came back showing an error. The error was that four names were entered when we only specified three. Since this was a pilot, we had the flexibility to talk to the participants after the test. The participant who voted the four names told us he was concerned because the instructions given by the voting machine were “Vote for four,” and he was afraid of what might happen if he didn’t. He explained that he thought the machine might not accept any of his votes if he didn’t complete the task as the machine directed (regardless of our silly instructions). This instruction seemed like an imperative to him. His background? He was a computer programmer.
We often observe that people do not read instructions on screens. This is true when we’re doing something familiar that we think we know how to do, like entering addresses, phone numbers, or even creating passwords. It’s only when a user makes a mistake that they notice instructions. The exception to this is when the user is in unfamiliar and/or important territory (like voting) or is elderly (many of whom tend to read everything on a screen).
Like error messages, instructions are given at times when a user needs help. We should be very careful when this happens. Instructions can’t be an afterthought any more than error messages can be (but often are).
There is an old expression about kids: “Never worry that your kids don’t listen to you; worry that they are always watching you.” The human-computer version might be: “Don’t worry that people don’t want to read your instructions; worry that they sometimes do.”
