Watching people try to use your site
Ask someone if a checkout works and they'll say sure. Watch them try it and you'll see where it breaks.
If you only ever run one kind of research, run this one. Usability testing is the method that made the field credible, because instead of asking people what they think, it watches what they do. You hand a real person a real task, “buy the cheapest delivery for a parcel to Leeds”, and watch them attempt it. Where they stall, where they click the wrong thing, where they say “what does that even mean” out loud, that’s your finding. It’s the most reliable way to find out whether the thing you built works for the person you built it for.
The method is called think aloud. You ask the person to say what they’re doing and thinking as they go, which turns a silent struggle into something you can follow. It’s the difference between “they gave up” and “they gave up because all the delivery options looked the same and none of them said what ‘standard’ meant”. How you brief them matters more than people expect. Tell them you’re testing the site, not them, and that if they get stuck it’s the site’s fault. People are terrified of looking stupid, and a participant who’s worried about that will tell you everything is fine while it very much isn’t.
Everything rests on the task, and a badly written one ruins the test before it starts. It has to be a real goal in the person’s words rather than the designer’s. “Find the returns policy” is a task. “Navigate to the footer and locate the policy link” is the designer telling them the answer. It also mustn’t give itself away: “click the big green checkout button” is a guided tour. Getting the phrasing right is worth ten minutes per task.
You don’t need many people. Five is the number Steve Krug settled on, and it’s held up. Most usability problems show in the first two or three sessions, and by five you’re mostly hearing repeats, which is your signal to stop and fix things instead of collecting more proof. What matters is having the right people: real users, or people who match them. Avoid your colleagues, and avoid the person who built the thing, who’s spent months learning not to see its flaws.
Be wary of the preference test. “Do you like it?” and “which of these feels better?” collect opinion, and opinion about an interface is mostly noise. The person who tells you a page looks lovely will still fail to find the buy button. The comment worth writing down sounds more like “I can’t tell how much this costs”, said out loud at the exact moment someone gave up.
Put it to work
Take one task on your site and write the exact wording you would give a stranger to attempt it. Remove any word that hints at the answer.
There is no right answer. Write yours first, then compare.
Sources
Shoshin is written by Another Web is Possible. Lessons are licensed CC BY-SA 4.0.Our promise.