tinyhumansai Usability Test
Watch people try to do the thing. The output is behaviour, not opinion — what somebody says about a design is weakly related to whether they can use it.
When to use
- A design rests on an assumption about how people behave.
- Two directions disagree and the argument is about taste.
- Anything with a task in it is about to ship.
Steps
- Write the task, not the question. "Change your billing address" — never "what do you think of this screen".
- Recruit for the behaviour, not the demographic. People who have actually needed to do this.
- Say nothing while they work. The single hardest step, and every prompt you give destroys the finding you were about to get.
- Record what they did — where they hesitated, what they clicked first, where they gave up. Time and clicks matter less than the moment of hesitation.
- Separate usability from preference. Five people is a real sample for "can they do it" and no sample at all for "which do they prefer". Say which you ran.
- File it.
record_entryonresearch-findingswith the method, the sample and the implication. A finding with no implication is trivia.
Output
research-findings rows stating what people did, with the sample beside each.
Findings that contradict the current direction go in first, and they are the
reason this pass exists.