# Usability Review Walks a real task through an interface step by step, and reports what the user cannot tell or cannot do — with the evidence behind each finding. ## Deliverable One Markdown document, `usability-review.md`, in the structure set out under **Output** below. It walks the flow described by **User Flow Specification**, and its findings feed the next revision of that document. ## Required inputs - **An interface that can be operated**, in the state it is actually in rather than the state it is meant to reach. - **The task the user is meant to complete on it**, and who that user is. - **The heuristic set the review is run against**, named so a reader can check any finding against it. If the task is absent, stop and report it. An interface reviewed without a task produces a list of preferences; the task is what turns a preference into a failure. ## Optional inputs - Recordings or notes from people attempting the task - Support records, and the questions that keep recurring - Analytics showing where attempts stop - The specification the interface was built from - The devices, input methods and conditions the task is performed under - Earlier reviews, and what changed after them Without observation this is an expert inspection, and every finding says so. An absent input lowers what a finding may claim; it never turns a judgement into an observation. ## Execution **1 — Fix the task, the user and the starting point.** Where the attempt begins, what the user knows on arrival, what counts as completion, and what would count as giving up. A review that starts inside the product skips the step where most attempts are lost. **2 — Attempt the task, one step at a time.** At each step record what the interface shows, what the user has to decide, and what that decision costs them in attention or in typing. Record the steps that work as well as the ones that do not. **3 — At each step, ask what the user cannot tell.** Where they are, what just happened, what will happen if they continue, whether it can be undone, and whether the system is doing anything at all. Each of these with no answer at that step is a finding. **4 — Attempt the failures.** Wrong input, missing permission, a lost connection, an interruption and a return. A task is only as usable as its failure paths, and they are where an unreviewed interface abandons the user. **5 — Write each finding against a heuristic.** The step, the heuristic it breaks, what the user cannot tell or cannot do, and the evidence — what someone was seen to do, or what was judged by inspection. A finding without a heuristic is a preference with a paragraph around it. **6 — Set severity from impact, not from irritation.** How many of the people doing this task meet that step, whether it blocks completion or slows it, whether a workaround exists, and whether a user could find that workaround without being told. **7 — Separate observation from judgement.** Label every finding `observed` or `inspected`. For each `inspected` finding, name the observation that would confirm or kill it. Never let an inspection finding be read as something users were seen to do. ## Output `usability-review.md`, in this order: - **1. Task, user and date** — the task reviewed, who it is for, and where the attempt started - **2. Method** — inspection or observation, the heuristic set used, and the conditions the attempt ran under - **3. Walkthrough** — per step: what the interface showed, what the user had to decide, and what it cost - **4. Findings** — per finding: step, heuristic, what the user cannot tell or do, evidence, `observed` or `inspected` - **5. Severity** — per finding: who meets it, whether it blocks or slows, whether a workaround exists and can be found - **6. Failure paths** — what the interface does when the task goes wrong, and what the user can do then - **7. Recommendations** — per finding: the change proposed, and what that change must not break - **8. What would settle it** — each `inspected` finding with the observation that would confirm or kill it - **9. Missing information** — what could not be attempted, and who can unblock it ## Validation The report is ready when all of these hold: - Every finding names a step from section 3 and a heuristic from the set in section 2 - Every finding is labelled `observed` or `inspected`, and no `inspected` finding is written as behaviour users were seen to have - Every finding carries a severity with its basis recorded - Every step attempted appears in section 3, including the steps with no finding - Every `inspected` finding has an entry in section 8 - Every recommendation names the finding it answers Fail the run if a finding claims observation the method in section 2 does not support, or if a severity appears with no basis recorded. ## Failure handling - **No task supplied** — stop. Report that there is nothing to walk, and that reviewing an interface without a task produces taste, not findings. - **No observation possible** — run the review by inspection, label every finding `inspected`, and list in section 8 the observation that would settle each one. - **No operable interface** — review the specification and the design material only, mark every finding `unattempted`, and state that a step nobody walked has not been reviewed. - **Contradictory accounts of intended behaviour** — record both with their sources, review the behaviour that is built because that is what the user meets, and raise the contradiction in section 9 as blocking. - **Partial access** — review the steps that can be attempted, mark the rest `NOT REVIEWED — `, and state that an unreviewed step is not a working one.