Rung 5

Usability

Rung five: they can reach it, load it, perceive it, and read it. Can they do the thing they came to do?

The line we just crossed

Everything below this rung was about mechanics: the page exists, arrives, and connects to the person's senses, hands, and language. Usability asks a different question — one no validator, scanner, or spec can answer: does the interface match how people think, and does it let them finish their task?

This is why the rung matters as its own lesson: a page can pass every technical check we've built so far — valid, resilient, fully accessible, translation-friendly — and still fail nearly everyone who tries to buy a fleece. Correct is not the same as usable. The scanner's 100 score measures the rungs below, not this one.

What holds this rung up

  • Convention. Users spend most of their time on other sites; your site is judged by habits formed elsewhere. The logo links home. The cart lives at the top end of the header. Links look like links. Every convention you break is a toll you charge in confusion — pay it only for real gains.
  • Speaking the user's language. "Add to cart," not "Initiate procurement." Labels come from the user's world, not the org chart or the database schema.
  • Feedback. Every action gets a visible reaction. A cart button that does its work silently teaches users to click it four times and trust it zero.
  • Error prevention and recovery. Constrain inputs so mistakes are hard to make; when they happen, say what went wrong, where, in words, next to the field — and never throw away what the user already typed. Forgiveness is a feature.
  • Visibility of state. Where am I, what's in my cart, what will this cost, what happens when I press this? A checkout that reveals shipping cost only on the last screen isn't hiding a number; it's ambushing a decision.
  • Task fit. The flow mirrors the user's goal, not your system's internals. Nobody's goal is "create an account"; it's "get the fleece." Every step you add serves you, and they know it.

The demo design: the flawless failure

This rung's demos are two versions of a three-step Terra Outfitters checkout. The punchline of the broken one: it scores 100 on Lighthouse accessibility and passes axe with zero violations. Every control is a real button, labeled, focusable, high-contrast. And nobody can buy a fleece with it. As in the earlier lessons, the sins are numbered in the source, with matching numbered fixes:

The unusable checkout: sins and their fixed counterparts
#Sin (technically flawless)Fix
1Jargon labels: "Initiate procurement," "Finalize fulfillment parameters," "Remit""Add to cart," "Shipping address," "Pay $32.24"
2Silent success: adding to cart changes nothing visible anywhereCart count updates; brief inline confirmation near the button
3Broken conventions: logo not linked home; cart link buried in the footer; primary action styled gray, on the start side, with "Reset" styled orange beside itLogo links home; cart top of header; primary action prominent and consistently placed; no reset button at all
4Ambush pricing: shipping and fees appear only on step 3, raising the total 40%Running order summary visible from step 1
5Error rage: one invalid field rejects the form with "Error in form" at the top — and clears every fieldErrors named per field, inline, in plain words; input preserved
6Forced account creation before the price is even shown, with password rules revealed one rejection at a timeGuest checkout; account optional after purchase; requirements stated up front
7No sense of place: three steps, no indication of which you're on or how many remain"Step 2 of 3 — Shipping" heading and progress list
8Surprise navigation: "Continue" on step 2 opens a newsletter interstitial instead of step 3Continue continues. Nothing else.

The exercise: measure behavior, not opinions

This rung introduces the discipline's method: usability is observed, not declared. Run the classic hallway test as a lab. (Until the two demo checkouts are posted, run it on any real store's checkout, with a task that stops short of paying.)

  1. Pair up. One partner is the observer, one the participant; the participant gets a task, not a tour: "Buy one Trailhead Fleece in green, shipped to campus."
  2. Observer records, silently: task completed? time to complete; wrong turns; error messages hit; where they hesitated; what they said out loud. No helping — every instinct to explain your interface is data about the interface.
  3. Run it on the unusable store, then swap partners and run the usable one. Compare completion rate and time across the class.
  4. First run Lighthouse on the unusable store and post the accessibility score next to the class completion rate. Let the gap between 100 and reality be the lecture.
  5. Debrief against the sin table: which sin cost the most time? Which caused abandonment? Note that sins 4, 6, and 8 are choices someone made on purpose — hold that thought for the acceptance lesson.

Next rung

The task is completable. Would anyone choose to come back? Continue to Acceptance: do they want it?