Usability Review Coach

Run a structured usability review of a screen or flow and return findings a team can act on the same day. The discipline is evidence over taste: every finding names the exact element and the moment it fails a user, carries a severity that means something, and arrives with the cheapest credible fix attached. A review that says "feels cluttered" has not done its job.

When to use this skill

• The user shares screenshots or a walkthrough and asks what is wrong with a flow
• A signup, checkout, or onboarding funnel is underperforming and needs a diagnostic pass
• A team wants a pre-launch usability check before recruiting real test participants
• Support tickets cluster around one screen and nobody can say why
• A redesign needs a before-and-after comparison against consistent criteria

The seven lenses

Review every step of the flow against these questions, in this order:

1. Orientation — can a first-time user tell where they are, what the screen is for, and how far through the task they have come?
2. Next step — is the primary action visually singular and unmistakable, or do several elements compete for it?
3. Feedback — does every action produce a visible response within a beat, including slow operations and failures?
4. Forgiveness — can the user back out, undo, or correct a mistake without losing work or dignity?
5. Load — how much must the user read, remember, or decide before acting, and how much of that could the interface carry instead?
6. Language — do labels use the user's own words, and does the same thing keep the same name on every screen?
7. Reach — does the flow work with a keyboard alone, on a small screen, and with modest eyesight, or only on the demo setup?

Workflow

1. Fix the frame first: who is the user, what task are they completing, on what device. A review without a task degenerates into decoration critique.
2. Walk the flow step by step as a genuine first-timer. At each step, write down what you actually see before what you already know — expert knowledge is the enemy of this pass.
3. Apply the seven lenses at each step and log failures as findings. One finding, one element, one moment.
4. Assign severity honestly: blocker means users cannot complete the task; major means many will fail or give up; minor means friction but the task completes; polish means worth fixing, harms little.
5. Attach the cheapest credible fix to each finding. Relabeling a button beats redesigning the page; propose the redesign only when no small fix can resolve the finding.
6. Write the keep list: three to five things that work well and must survive future changes. Reviews that only criticize get ignored, and good patterns get accidentally destroyed.
7. Summarize with a verdict paragraph, the top five findings by severity, then the full table.

Output format

Findings go in a table with these columns:

ID	Step	Lens	Severity	Finding	Cheapest credible fix
U1	Payment form	Feedback	Major	Submit shows no state change for four seconds; users click again, risking double charges	Disable the button on submit and show inline progress text

Precede the table with the verdict paragraph and the task-and-user frame, so readers know exactly what was reviewed and for whom.

Worked example: weak versus strong finding

Weak: "The dashboard is confusing and cluttered." Nobody can act on this, and it will be argued about instead of fixed.

Strong: "U3 — Dashboard, Orientation lens, Major. Seven cards share identical size and weight, so a first-time user cannot tell which number they came to check; in a five-second glance test the primary metric is not findable. Cheapest credible fix: make the primary metric card twice the height and demote the four secondary cards to a single compact row."

The strong version names the elements, describes the failing moment, and hands the team a next step they can take today.

Guardrails

• Review the interface, never the user; "users don't get it" is a finding about the design
• Every finding must point at an observable element or moment — delete anything you cannot point at
• Severity reflects task impact, not your level of annoyance
• Do not redesign wholesale inside a review; the deliverable is findings plus minimal fixes
• If you only have a prose description, ask for screenshots or a recording before scoring severity; severity guessed from prose is fiction
• Name the lenses you could not assess — for example Reach without keyboard access — instead of skipping them silently