research methods
Usability testing
Watching real people attempt real tasks with your design, to find where it trips them up. It is not asking whether they like it - it is handing them something to do and seeing what actually happens.
The demo
A usability test, stripped to its bones, is five moves. Here is one you have already taken part in on this very site:
- Pick a real task. Not "browse around" but something with a right answer: find the cheapest plan, get to billing, spot what changed.
- Hand it over and stay quiet. The moment you explain the interface, you have stopped testing it. Let the person struggle; the struggle is the finding.
- Watch what they do, not what they say. Where did the first click land? Where did they stall? What did they skip entirely?
- Find the telling moment. The pause before a wrong turn, the label that read the wrong way, the button nobody saw. One honest stumble is worth a page of opinions.
- Fix it, then test again. A test that doesn't change the design was a survey. Close the loop.
The research-methods entries each take one slice of this and let you feel it: the five-second test measures first impressions, first-click testing measures the opening move, and heuristic evaluation is the cheap expert pass you run before you spend real testing time.
Every timed demo on this site is a tiny usability test: a task, a stopwatch, and your own behaviour as the data. This is the method underneath all of them.
The golden rule is to test tasks, not opinions. Ask "what do you think of this" and you get politeness; ask "show me how you'd do X" and you get the truth. People are unreliable narrators of their own behaviour, so watch the behaviour and treat the commentary as a clue, not a verdict.
You need far fewer participants than you'd think. Five people will surface the large majority of the serious problems - so test five, fix what they hit, then test five more. Big samples are for measuring how bad something is, not for discovering that it is broken.