Usability Testing as Design Evidence
What This Concept Is
Usability testing observes representative people attempting representative tasks with a design. It measures whether they can discover, understand, complete, and recover —not whether they say the interface looks good.
Why It Matters Here
Code review supplies evidence about implementation quality; usability testing supplies evidence about interaction quality. Both expose assumptions through inspection. Treating usability as taste makes product decisions unreviewable and allows polished failure paths to survive.
Concrete Example
Five participants must restore a deleted note. Four open “History,” but the implementation places restoration under “Workspace settings.” Their hesitation and failed path are evidence against the information architecture. The team moves history beside the note list and retests. Completion rises from one of five to five of five, while median task time falls from 94 seconds to 21 seconds.
Common Confusion / Misconception
Usability testing is not a statistically representative opinion survey. A small formative test can reveal severe workflow defects, but it cannot establish market demand or population-level preference. Report what the test demonstrates and what it does not.
How To Use It
- Define a task and success condition without revealing the intended path.
- Recruit people who approximate the relevant context; document limitations.
- Ask participants to think aloud without coaching.
- Record completion, critical errors, recovery, time, and observed confusion.
- Rank findings by impact and frequency.
- Revise one important interaction and rerun the same task.
Check Yourself
- Does the prompt describe a goal rather than a sequence of clicks?
- Can an observer distinguish assistance from participant success?
- Did the design change because of evidence, and can you show before/after results?
Mini Drill or Application
Write a three-task protocol for the Semester 3 project. Run it with one person who did not implement the feature. Record one success, one hesitation, one incorrect assumption, and one design change. Retest the changed task.
Read This Only If Stuck
- Good Code, Bad Code provides the local backbone for testable claims and observable behavior.
- Use the W3C Easy Checks alongside usability observation so accessibility failures are not mistaken for ordinary preference.