Chapter 3 of 97 Things Every Programmer Should Know is Ask “What Would the User Do?” (You Are not the User) written by Giles Colborne. Mr. Colborne relates a problem common to both librarians and programmers:
We all tend to assume that other people think like us. But they don’t. Psychologists call this the false consensus bias. When people think or act differently to us, we’re quite likely to label them (subconsciously) as defective in some way.
This bias explains why programmers have such a hard time putting themselves in the users’ position. Users don’t think like programmers. For a start, they spend much less time using computers. They neither know nor care how a computer works. This means they can’t draw on any of the battery of problem-solving techniques so familiar to programmers. They don’t recognize the patterns and cues programmers use to work with, through, and around an interface.
The common problem, it turns out, has a common solution – go and see what real users are doing:
The best way to find out how users think is to watch one. Ask a user to complete a task using a similar piece of software to what you’re developing. Make sure the task is a real one: “Add up a column of numbers” is OK; “Calculate your expenses for the last month” is better. Avoid tasks that are too specific, such as “Can you select these spreadsheet cells and enter a SUM formula below?” — there’s a big clue in that question. Get the user to talk through his or her progress. Don’t interrupt. Don’t try to help. Keep asking yourself “Why is he doing that?” and “Why is she not doing that?”
The first thing you’ll notice is that users do a core of things similarly. They try to complete tasks in the same order — and they make the same mistakes in the same places. You should design around that core behavior. This is different from design meetings, where people tend to be listened to for saying “What if the user wants to…?” This leads to elaborate features and confusion over what users want. Watching users eliminates this confusion.
You’ll see users getting stuck. When you get stuck, you look around. When users get stuck, they narrow their focus. It becomes harder for them to see solutions elsewhere on the screen. It’s one reason why help text is a poor solution to poor user interface design. If you must have instructions or help text, make sure to locate it right next to your problem areas. A user’s narrow focus of attention is why tool tips are more useful than help menus.
This past semester or so, we’ve had an intern who has been doing usability studies on our website. We wound up making changes based on what users weren’t finding on our website. Some of the tweaks were as simple as changing a metatag on one of our pages so a meaningful title showed up in the search results. A librarian or computer person didn’t need the title tag because we’re trained to look at the URL. But the average user doesn’t because they think differently.
It’s nice to see other fields tackling usability and watching people for what they actually do. We might have a lot to learn from one another.