Lesson 9 of 15
Usability testing
Usability testing — watching real people attempt real tasks with your design — is the single most valuable thing you can do in UX. Nothing else reveals so clearly what's confusing, broken, or missing. And the best part: it's cheap, fast, and you need surprisingly few users to find most problems. If you take one practical skill from this course, make it this. Let's run a test properly.
Watch what they do, don't ask what they think
The essence of usability testing: give a user a realistic task and watch them attempt it — observing where they hesitate, get stuck, or go wrong, without helping:
HOW TO RUN A USABILITY TEST
1. PICK REAL TASKS — the key things users need to do (e.g. "Find and buy a
blue shirt in size M"). Give the GOAL, not step-by-step instructions.
2. RECRUIT REAL-ISH USERS — people like your actual users. You do NOT need
many: ~5 users typically uncover ~80% of usability problems. Testing 5
then fixing beats testing 50 once.
3. ASK THEM TO THINK ALOUD — narrate their thoughts as they go ("I'm
looking for... I expected that here... this is confusing"). This reveals
WHERE + WHY they struggle.
4. WATCH SILENTLY. DO NOT HELP OR LEAD. Bite your tongue. The moment you
guide them, you've lost the finding. Their struggle IS the data.
5. OBSERVE + NOTE: where do they hesitate, get lost, misread, click the
wrong thing, give up? Note the PROBLEMS, not just opinions.
6. Keep sessions short + focused (~5 tasks, 30-45 min).
Test with a PROTOTYPE (before building) or a live product. Even a paper
sketch can be tested. Test EARLY + OFTEN.
The two golden rules: watch behaviour, don't ask opinions (what they do reveals usability; what they say they'd do doesn't), and don't help them — the moment you step in and guide the user, you've destroyed the finding. Their struggle is exactly the data you came for.
Why so few users, and what to do with findings
THE 5-USER INSIGHT + ACTING ON RESULTS
- ~5 USERS FIND MOST PROBLEMS. The same big issues recur fast — you don't
need statistical significance to see that a button is confusing. So:
test 5 -> fix the problems -> test 5 more. Iterate cheaply.
- SEPARATE SIGNAL FROM NOISE: a problem SEVERAL users hit is real + urgent.
One person's personal preference may be noise. Prioritise by how many
users hit it + how badly it blocks them.
- FOCUS ON WHAT THEY DID, not what they SAID they liked. "I liked it" while
failing the task = the design has a problem, regardless of the compliment.
- TURN OBSERVATIONS INTO FIXES: each problem -> a specific design change ->
re-test. (The next lesson covers analysing results in depth.)
- DON'T get defensive. Every problem found is a problem FIXED before launch.
A failed task in testing is a GIFT (found cheaply, not after release).
The value isn't a report — it's the CHANGES you make + re-test.
The liberating fact: you only need about 5 users to find most problems, because the big issues recur quickly. So testing is cheap — test 5, fix, test 5 more. And remember to watch what they did, not what they said they liked: a user who fails the task but says "nice app" has just shown you a real problem.
The mistake beginners make
The mistake that invalidates a usability test is helping or leading the user — jumping in when they struggle ("oh, it's up there"), or asking leading questions ("wasn't that easy?"). The struggle is the finding; helping erases it. Sit on your hands, stay neutral, let them work. The second mistake is asking for opinions instead of observing behaviour — "do you like this?" (they'll be polite) instead of watching whether they can complete the task. Behaviour is truth; opinions are noise. The third mistake is getting defensive about problems — arguing that the user "did it wrong" or dismissing findings, instead of treating each discovered problem as a gift (a flaw found cheaply, before launch). And a quieter mistake: not testing at all because it feels intimidating — when even one rough test with 5 people would transform the design. Test early, test often, watch silently, embrace the problems.
Your turn
Your turn
- Write 3-5 realistic task scenarios for your design, phrased as GOALS not instructions (e.g. 'Buy a blue shirt in size M', not 'Click the shop menu, then...').
- Recruit 5 people similar to your real users. Remember: 5 is enough to find most problems — you don't need a big sample.
- Run a session: ask them to THINK ALOUD, give them a task, then WATCH SILENTLY. Do not help, hint, or lead — even when it's painful. Note every hesitation, wrong turn, and point of confusion.
- Focus on behaviour over opinions: record what they DID (completed? struggled? failed?), not just what they said they liked.
- Turn findings into fixes: list the problems SEVERAL users hit (real + urgent), turn each into a specific design change, and plan to re-test. Treat every problem found as a win.
Key points
- Usability testing — watching real users attempt real tasks — is the single most valuable UX activity: it reveals what's confusing, broken, or missing more clearly than anything else, and it's cheap and fast.
- Give users a realistic GOAL (not step-by-step instructions), ask them to think aloud, and WATCH SILENTLY — never help or lead, because their struggle IS the data (helping erases the finding).
- ~5 users uncover most (~80%) usability problems because big issues recur fast — so test 5, fix, test 5 more; you don't need a large sample or statistical significance.
- Watch what users DO, not what they SAY they like — a user who fails the task but compliments the app has revealed a real problem; prioritise issues by how many hit them and how badly they block.
- The mistakes: helping/leading the user (invalidates the test), asking opinions instead of observing behaviour, getting defensive about problems, and not testing at all — test early/often, watch silently, treat every problem found as a gift.
Q&A · 0
Enrol to ask questions and join the discussion.
No questions yet — be the first to ask.