Topic 7 — Usability and testing

Goal: Prove a design works by watching real people use it.

Lesson 7.1 — What you actually mean by "usable"

Tessa hands Marcus her first real screen at Wanderwell: a clean flight-results page, generous whitespace, a soft palette she's proud of. He looks at it for a while and asks one question. "Can a person find the cheapest flight to Rome on this in under a minute?"

She doesn't know. She made it look right. Whether it works is a different question, and it has a name.

Usability is how easily a person can use your product to reach their goal. It breaks into three things you can actually observe. A usable design is effective — the person can complete the task at all. It's efficient — they get there without wasted effort, dead ends, or backtracking. And it's satisfying — the experience doesn't frustrate or annoy them. Effective, efficient, satisfying. That's the measurable core of good UX, and it's what "good design" cashes out to when you stop talking about taste.

Notice what's not on that list: how pretty it is. A gorgeous screen that nobody can book a flight on has failed the only test that counts. Tessa spent eight years making retail spaces beautiful, but a beautiful store where customers can't find the fitting rooms is a store that loses sales. Same logic here.

Usability is the question "did this person reach their goal, easily?" — and aesthetics is no substitute for the answer.

Lesson 7.2 — The thing nobody warns you about

Tessa is certain her booking flow is obvious. She built every step. She knows the filter is in the top-right, she knows "Continue" comes before "Pay," she knows what every icon means. So when Marcus suggests testing it, a small voice says: why bother? It's clearly fine.

That voice is the trap. Here is the humbling truth every designer eventually swallows.

You cannot reliably judge your own design's usability. You know how it's supposed to work, which makes you blind to the exact spots where a stranger gets lost. Your brain auto-fills every gap a real user would fall into. The screen that feels self-evident to you, after staring at it for three days, will quietly baffle someone seeing it fresh — in ways you'd never predict from your chair.

This isn't a knock on your skill. The more deeply you understand a design, the less able you are to see it fresh. Marcus, who's run hundreds of tests, is just as blind to his own work as Tessa is to hers — that's why even senior designers test. The blindness is the whole reason testing exists.

Lesson 7.3 — A usability test, demystified

The phrase "usability test" sounds like it needs a lab, a budget, and a clipboard. It doesn't. Watch what Hannah, the researcher, actually does when she pulls Tessa in to observe.

She sits one real person in front of Tessa's prototype and gives them a single, realistic task in plain words: "Find and book the cheapest flight to Rome for next weekend." Then she does the hardest part of the job. She shuts up and watches.

That's usability testing: give a real person a realistic task, let them attempt it on your design or prototype, and observe — without helping. Three things are worth writing down every time:

• Where do they hesitate? A pause is a question they can't answer yet.
• Where do they go wrong — wrong button, wrong path, dead end?
• Do they finish the task at all?

The participant scrolls right past the "Sort by price" control three times, sighs, and starts comparing prices in his head. Tessa, watching, feels her stomach drop — that control was obvious to her. That single moment is worth more than a week of her own opinions. The struggle she just watched is data she could not have generated alone.

A "realistic task" matters more than it sounds. "Click the sort button" tests nothing — you've told them the answer. "Find the cheapest flight" lets them reveal whether they can even find the sort button. Hand them a goal, never instructions.

Lesson 7.4 — Five people is enough (and two rules that make it work)

When Tessa imagines testing, she pictures recruiting fifty users and drowning in scheduling. Priya, the PM, tells her the famous finding that changed the whole field.

You don't need fifty. Testing with about five users uncovers the large majority of usability problems — roughly 85% of them. This comes from a 1993 study by Jakob Nielsen and Tom Landauer (Nielsen later co-founded the Nielsen Norman Group), who modeled it across many real projects: a typical single user trips over about 31% of a design's problems, and by the time five people have each taken a pass, their overlapping struggles surface most of what's broken. The math has a soft edge that matters — a sixth, seventh, eighth user mostly re-finds problems you already saw. The money is better spent fixing those and testing again.

So testing is cheap and powerful, not expensive and rare. One caveat Hannah always adds: the five-user rule holds for one kind of user. Wanderwell serves both first-time travelers and frequent business bookers, who behave differently — so she runs a small round with each group rather than one round of five mixed people.

Five sessions only pay off if you run them right, and two rules carry the whole thing.

One: ask them to think aloud. Tell the participant to narrate — say whatever's in their head as they go. "I'm looking for prices... I guess I'll try this menu... no, that's not it." Without the narration you see that they're stuck; with it you learn why. Their running commentary is the difference between "something's wrong here" and a fix.

Two: never lead or rescue them. Beginners break this rule every time, because watching someone struggle is physically uncomfortable. The instant Tessa leans in and says "just tap the top-right," the test is over — she's handed over the one answer she came to discover. Their confusion is the finding.

The moment you rescue a struggling user, you delete the most valuable thing they were about to teach you. Sit on your hands.

When someone gets badly stuck, Hannah's move is a neutral nudge, not a hint: "What are you trying to do right now?" That keeps them talking without solving it for them.

Lesson 7.5 — Catching the obvious stuff between tests

Testing is gold, but you can't test every screen every day. Between sessions, you need a checklist for catching the dumb-but-easy-to-miss problems before they ever reach a user. That checklist already exists, and it's the field standard.

In 1990, Jakob Nielsen and Rolf Molich distilled common interface failures into a short list of rules of thumb — heuristics — and Nielsen refined them in 1994 into the 10 usability heuristics still taught everywhere today. Marcus has Tessa run her booking flow against them. A few of the most useful, with what they caught:

• Visibility of system status — always show what's happening. Tessa's "Pay" button gave no feedback after a tap, so users tapped it twice and double-booked. A spinner and a confirmation fixed it.
• Match between system and the real world — use the user's words, not internal jargon. Her filter said "PAX," the airline term for passengers. Real travelers say "travelers." She changed it.
• Consistency and standards — the same action should look and behave the same everywhere. Her "back" arrow sat on the left on one screen and the right on another. Pick one.
• Error prevention, and help users recover from errors — stop mistakes before they happen, and when they do, explain them in plain language with a way out. "Invalid input" became "Please enter a date in the future."
• Recognition rather than recall — show options instead of forcing people to remember. Don't make users recall an airport code; show a list as they type.

Heuristics don't replace testing — they catch the obvious problems so your real users can reveal the surprising ones. Run through them yourself, then bring in a second designer for a fresh pass, since you're still blind to your own work.

And then you loop. Design → test with a few users → fix what tripped them → test again. Each turn, driven by real observation rather than opinion, grinds a decent design down into an effortless one. It also hands Tessa the single most persuasive sentence a designer can say to stakeholders: "I tested this, and here's what I learned." No one argues with a recording of a real user getting lost.

Worked example — Five sessions that saved a launch

Wanderwell is two weeks from launching a redesigned checkout. Bookings dropped in an early beta and nobody knows why. Tessa volunteers to run her first real usability test instead of guessing. She writes one realistic task — "You found a flight to Rome you like. Book it and add a checked bag." No instructions, just the goal. She and Hannah recruit five everyday travelers, one at a time, thirty minutes each.

User 1 thinks aloud, hits "Continue," and pauses: "Wait, did it save my bag? It didn't say anything." No system-status feedback. Tessa's hand twitches toward the keyboard to reassure him — she doesn't. She writes it down. Users 2 and 4 hit the same wall, which tells her it's real, not a fluke. User 3 can't find where to add the bag at all and gives up, booking with none — a flat task failure. User 5 mistypes a date, gets a red "Error 422," and has no idea what it means.

Five short sessions, three concrete problems, each watched with her own eyes: no confirmation after adding a bag, a buried bag control, and a useless error message. Tessa runs the flow against Nielsen's heuristics and the same three light up — visibility of system status, recognition over recall, help users recover from errors. She fixes all three, then runs five new users. This time, four of five sail through and add the bag without a hiccup.

She brings the before-and-after clips to Priya. Not an opinion — evidence. The launch ships on time, and bookings recover. That loop, design → test → fix → test, is the entire job of this topic, and Tessa just did it for the first time.