Testing prototypes, with people and with tools
🎯You'll be able to
Run a usability test of a prototype, combine it with automated checks, and use both to decide what to change.
🏠The everyday picture
A new recipe is tested twice: once with a thermometer and a timer, and once by people eating it. Both matter.
📘What it really is
- Test with people using the methods from UX2: realistic tasks, think-aloud, neutral moderation, tagged notes and results.
- Compare versions with the same tasks: "T1 completed without help: starter 2/5; redesign 5/5" (still counts, not percentages).
- Automated checks run every time something changes:
- accessibility rules (axe);
- layout checks at several widths (no sideways scrolling, target sizes);
- journey checks (the whole booking works);
-
content checks (no full phone number on the confirmation).
-
The kit's tests are examples of acceptance tests a design team can write with developers. They don't replace watching people.
- Test what changed, and what might have broken: each fix can affect other screens.
- Accessibility testing with disabled participants finds problems neither tools nor non-disabled testers notice.
📝A worked example
Input: the starter and the reference prototype.
| Check | Starter | Reference |
|---|---|---|
npm run test:prototype |
2 of 10 pass (tests 8 and 9) | 10 of 10 |
| axe on the search page | color-contrast: 9, label: 1 |
no serious or critical problems |
| Small targets on the search page | "Go" and every "Choose a time" link | none |
Expected output: a short note saying what the tests show (rules met, journey works) and what still needs people (whether "Selected: 10:30" is noticed, whether the confirmation feels trustworthy).
🌍Where it's used
- Continuous integration in product teams, where accessibility and journey tests run on every change.
- Pre-launch testing with five to eight people per round.
- Benchmark tests on larger groups when a rate is needed.
📝Case scenario
A team ran automated checks only and shipped a redesign that passed all of them. Support calls rose: people didn't notice a new "Confirm" step and thought they'd booked. A five-person test would have shown it; the team now runs both before every release.
🖱️Try it
Run npm run test:prototype on the starter and read each failure. Then predict which failures would also show up in a session with
people. Success: you link at least three test failures to findings in research/findings.md.
⚠️Common mistakes
- Tools only. Sign: no sessions since the redesign. Fix: test with people too.
- Changing the test to pass. Sign: a test edited because it failed. Fix: change the design; tests are part of the brief.
- Testing one screen. Sign: a fix breaks the next screen. Fix: run the whole journey test after every change.
🛠️For your project
Project 2's marking guide requires 10 of 10 tests passing without changing any test, and a short session with at least one person.
✅Quick check
What can automated checks not tell you?
Show the answer
Whether people notice, understand and trust the design.
Why run the whole journey test after a small change?
Show the answer
Because a change on one screen can break another.