Usability testing
Also called user testing.
Watching real people try to complete real tasks with a product, to find where they get stuck.
Last updated
What it is.
In a usability test you give someone a task ("book a follow-up visit for next Tuesday") and watch what they do. You do not help or explain. Where they hesitate, misread or give up is where the design needs work.
It can run on a wireframe, a high fidelity prototype or live software. A handful of people, often five or so per round, is usually enough to find the biggest problems, and more rounds after fixes find the next layer.
Why it matters
Teams know their product too well to see it fresh. A short test with real users finds problems that would otherwise reach launch, where they cost support time, lost sign-ups and rework. Finding them on a prototype is much cheaper than in code.
In a product build
OceanLab builds start with a clickable prototype before production code, and that prototype is the cheapest place to run a test with a few real users.
Common mistakes.
- 01
Asking people what they think instead of watching what they do.
- 02
Testing with colleagues instead of people who match the real users.
- 03
Testing once at the end, when there is no time left to fix what you find.
Related terms.
- High fidelity prototypeA prototype that looks almost exactly like the finished product, with final styling, real content and realistic interactions.
- WireframeA simple, usually grey, sketch of a screen showing layout, content and actions, without final styling.
- Clickable prototypeA set of linked screens you can click through, built to test a design before the real software exists.
- Acceptance criteriaThe testable conditions a feature must meet before the person who asked for it accepts it as done.
Guides and pages
Browse the full glossary or read answers to common questions.
