Theory
Watching, done properly
Unit 2 taught the IDEA of usability testing: watch real users attempt real tasks. But 'just watch someone' informally misses most of the value: you forget what to test, help too much, and end with a vague 'it seemed okay'.
Done professionally, usability testing is a disciplined 3-phase PROCESS: plan, conduct, analyze. Each phase has rules that turn casual watching into reliable findings you can act on.
This lesson is that process, run on FestConnect's registration prototype with 5 first-years.
Follow along
The usability testing process, phase by phase
- PLAN: define goals Decide exactly what you want to learn ('can first-years register without help?') and which metrics (success rate, time, errors).
- PLAN: write tasks + recruit Write realistic, non-leading tasks ('register for Garba Night'); recruit ~5 representative users (real first-years); prepare the prototype.
- CONDUCT: brief and reassure Tell the participant you are testing the DESIGN, not them; encourage think-aloud (say your thoughts out loud).
- CONDUCT: give tasks, observe silently One task at a time; watch where they struggle; do NOT help or lead; take notes; record with consent.
- ANALYZE: find patterns Compile all observations; identify issues MULTIPLE users hit (patterns matter more than one-offs).
- ANALYZE: rate severity + recommend Rank issues critical to minor; turn findings into prioritised, actionable fixes for the next iteration.
Theory
Phase 1: Planning is most of the work
A test is only as good as its plan. Before anyone sits down:
- define objectives: what SPECIFICALLY do you want to learn? Vague goals give vague results
- write task scenarios: realistic and TASK-based ('book a ticket for Garba Night'), never leading ('try our lovely new date picker')
- recruit representative participants: real target users (first-years), about 5
- decide metrics: task success rate, time on task, error count, satisfaction
- prepare the prototype and a script
Skimp on planning and you will run a session that gathers noise. This phase is where testing succeeds or fails.
Theory
Phase 3: Turning chaos into recommendations
After 5 sessions you have a heap of notes. Analysis makes them useful:
- find patterns: an issue 4 of 5 users hit is REAL; something one user did once may be a fluke. Patterns, not anecdotes, drive decisions
- rate severity: a bug that BLOCKS registration is CRITICAL; a slightly-confusing label is MINOR. Fix critical first
- prioritise and recommend: translate findings into a ranked list of ACTIONABLE changes
The output is not 'the test showed problems': it is 'here are the 3 critical issues, ranked, with recommended fixes' feeding straight into the next design iteration (next lesson).
Quiz
What are the three main phases of the usability testing process?
- Design, code, deploy
- Plan, conduct, analyze
- Sketch, colour, animate
- Research, ignore, ship
- Brand, market, sell
Show the answer
Plan, conduct, analyze
Usability testing runs in 3 disciplined phases: PLAN (goals, tasks, participants, metrics), CONDUCT (brief, give tasks, observe silently), and ANALYZE (find patterns, rate severity, recommend fixes). This structure is what separates reliable findings from casual watching. Option A is the software BUILD lifecycle, not testing. Option C lists visual-design steps. Option D contains 'ignore', the opposite of a test's purpose. Option E is marketing. Memorise plan-conduct-analyze as the process spine; each phase has its own rules (write non-leading tasks; observe without helping; prioritise by severity), and the exam often asks you to expand each phase's steps.
Think first
One user vs a pattern
In your 5 sessions, one participant fumbled the profile photo upload, while four of five got stuck at the date field. With limited time, which do you fix first, and what principle decides? Then tap.
Show the answer
Fix the date field first. The principle is PATTERNS OVER ANECDOTES combined with SEVERITY: 4 of 5 users hitting the same wall is a strong, recurring signal of a real, widespread problem, whereas one person's photo-upload fumble may be a fluke (fatigue, misunderstanding) and affects the whole flow far less. Analysis is precisely this triage: weight issues by how MANY users hit them and how BADLY it blocks the task, then fix the critical, common ones first. Chasing every one-off wastes limited time; the recurring, blocking issue is where the impact is. Data-driven prioritisation, not gut feeling.
Watch out
Process slips
Weak planning: vague goals and leading tasks doom the session before it starts.
Helping during the test: rescuing a stuck user erases the finding (Unit 2's hard rule); observe silently.
Reporting anecdotes: 'one user struggled' is weak; report PATTERNS across users, ranked by severity.
No actionable output: findings must become prioritised RECOMMENDATIONS, not just a problem list, or nothing changes.
Testing too late: test prototypes early (cost-of-change), not the finished build.
Theory
Findings are useless until you act
A test that produces a ranked list of critical fixes is only half the value; the other half is actually CHANGING the design and testing AGAIN. That loop: design, test, learn, refine, retest: is the ITERATIVE design process, and it is the next lesson: the engine that turns feedback into a genuinely better FestConnect, one cycle at a time. Testing without iteration is just collecting complaints.
Summary
Key takeaways
- Usability testing runs in 3 phases: plan, conduct, analyze.
- Plan: define goals and metrics, write realistic non-leading tasks, recruit ~5 representative users, prepare the prototype.
- Conduct: brief and reassure (testing the design, not them), encourage think-aloud, give one task at a time, observe silently without helping.
- Analyze: find patterns across users, rate severity (critical to minor), prioritise into actionable recommendations.
- Metrics: task success rate, time on task, error rate, satisfaction.
- Patterns beat anecdotes; fix common, blocking issues first.
- Memory hook: plan, conduct, analyze: watching users, done with discipline.