A heuristic evaluation is an inspection of an interface against usability principles. Its useful output is a set of specific, reproducible problems and reasoned recommendations. It identifies likely difficulties; it does not measure how often real users experience them. Start with one task and interface version, inspect independently, then consolidate the findings and decide what to fix or investigate.
Start with a task you can actually inspect
A team receives the comment 'The booking form is confusing.' One person wants a new layout, another wants shorter labels, and a third wants to remove a step. None of those proposals identifies what goes wrong. A useful evaluation begins by specifying the task, the starting conditions, and the interface that everyone will inspect. Otherwise, reviewers may be discussing different problems while using the same word: confusing.
This guide uses a fictional community workshop booking flow. A visitor selects a pottery session, enters their contact details, submits the request, and checks whether a place was reserved. All screens and findings below are teaching examples, not measurements or an audit of a real product. The exercise focuses on the response when the last place becomes unavailable before submission finishes. No payment is taken in this example.
Write the scope as an instruction another reviewer can follow: 'Inspect the mobile booking flow in prototype version B. Start from the workshop detail page, reserve one place, and recover from a capacity conflict. Use the supplied test details and the simulated full-session response.' An ordinary successful booking is still part of the scope; the conflict condition is an additional state, not a reason to skip understanding the basic journey.
| Field | Example for this evaluation |
|---|---|
| User and goal | A visitor reserving one pottery workshop place |
| Starting point | Workshop detail page, signed out |
| Material | Prototype B; mobile layout; supplied test details |
| States to inspect | Available place, submitting, confirmed, session full, uncertain response |
| Outside this exercise | Payment, refunds, staff administration, real attendance data |
| Deliverable | Reproducible issue records and a short repair/research decision |
Choose principles, then inspect without a group debate
NN/g describes a process of preparation, independent inspection, and consolidation. Its ten usability heuristics provide a shared vocabulary; they are not a checklist that proves a design is good. Agree which principles you will use before reviewing. For a specialist domain, record any additional criteria and where they came from. Do not silently mix a legal requirement, a brand preference, and a usability judgment into one score.
Each reviewer should first follow the booking journey to understand it, then inspect it closely and capture their own findings. Keep initial notes separate until the independent pass ends. If the first reviewer announces that the button is the main problem, the rest of the group may spend their time confirming that idea. Independence is useful even when the eventual discussion is collaborative.
For this example, several principles help frame questions: whether the interface explains its current state, whether it helps someone recover from an error, and whether it avoids unnecessary loss of work. Apply them to a particular interaction. 'Does the form support recovery after a full-session response?' is inspectable. 'Is the experience intuitive?' is too broad to produce a precise finding.
A solo review can still produce useful observations, but label it as one person's inspection. Do not describe repeated passes by the same person as independent evaluations. Likewise, an expert review is not an accessibility conformance audit or a usability test with participants. Keep those activities distinct so readers understand what evidence the report actually contains.
Inspect the transition, not only the final screen
In this booking example, the visitor has selected Thursday at 18:00 and entered a name and email address. After 'Reserve a place' is activated, the form remains visually unchanged while a request is pending. The simulated response then says 'Error 409,' empties the contact fields, and leaves the same submit button available. The screenshot after the error captures only part of the problem: it cannot, by itself, show that the fields were previously filled.
Capture the sequence as well as the result. Save the before state, the action, and the after state, with the prototype version and response condition. For a running application, a short recording may be more useful than several isolated screenshots. Use test data and remove personal information. If the scenario cannot be reproduced, retain it as an unresolved report rather than rewriting it as a confirmed defect.
Now separate observation from interpretation. 'The form clears the entered name and email after the full-session response' describes the example's behavior. 'A visitor will have to enter the details again to try another session' follows from that behavior. 'This causes 30% of visitors to abandon' does not follow; no participant or production measurement has been collected. Keeping these sentences separate prevents an ordinary inspection from turning into invented user research.
| Step | State or action | What the evaluator records |
|---|---|---|
| 1 | Select Thursday 18:00 and enter test contact details | The selected session and populated fields |
| 2 | Activate Reserve a place with a delayed response | Whether pending status is perceivable and what remains operable |
| 3 | Return the simulated full-session result | Exact error wording; whether data and selection remain |
| 4 | Try to recover by selecting another session | Whether a valid next action exists and what must be re-entered |
Write separate findings for separate mechanisms
A report headed 'Error handling is bad' is hard to assign and impossible to verify. In this example there are at least three questions: the pending state is not explained, the capacity error gives no usable explanation, and the failed attempt clears useful input. They occur in one journey, but they have different causes and acceptance conditions. A copy change might solve the explanation problem while leaving the data loss untouched.
Use a short problem title that includes the trigger or consequence. Then include the task, environment, steps, observed result, relevant principle, likely consequence, and supporting capture. A suggested fix belongs in a separate field. The team may choose a different remedy once it understands the cause, so the finding should remain useful even if the first proposed design is rejected.
Use the filled records below as a model for your own evidence. Do not attach a heuristic name merely to make a preference sound authoritative: explain how the behavior interferes with the specified task. A preference for rounded buttons, for example, needs a task-related reason before it becomes a usability finding.
| ID and observed issue | Likely consequence and rationale | Repair direction and verification |
|---|---|---|
| HE-01: No visible pending state after submission | Visibility of system status: the current request status is unclear, so the visitor has no basis for deciding whether to wait. A second click is possible, but duplicate reservations have not been demonstrated. | Show a perceivable pending state and define repeat-activation behavior. Verify the pending state during a delayed response and separately check the reservation outcome. |
| HE-02: Full session is reported only as Error 409 | Help users recognize, diagnose, and recover from errors: the code neither explains the capacity problem nor identifies a useful next action. | Explain that the session is full, state that no place was reserved, and provide a way to choose another session. Verify each statement against the actual response meaning. |
| HE-03: Capacity conflict clears contact fields | The same error-recovery principle applies: retrying requires recreating information already supplied, while clearing those fields does nothing to resolve the capacity problem. | Retain appropriate contact input while allowing a new session choice. Verify the preserved values and correct final reservation; do not retain sensitive data unnecessarily. |
Justify priority without inventing prevalence
NN/g's severity guidance considers frequency, impact, and persistence and describes a 0–4 scale. The practical lesson here is to record the reasoning behind a rating. An evaluator who can reproduce one error knows that the error can occur under those conditions; that is not a measurement of how often customers encounter it. If exposure is unknown, write 'unknown' and identify the evidence needed to estimate it.
For this exercise, HE-02 is a candidate high-priority repair because the only displayed response fails to explain why booking stopped or how to proceed. That is an evaluator judgment about a core task, not a measured abandonment result. HE-03 also deserves attention because retrying involves avoidable re-entry. Its exact priority depends on the amount of lost input, available recovery, and how often this condition happens. A short email field and a long application form do not create the same burden.
Discuss ratings after reviewers have supplied their own assessments. If one reviewer calls HE-01 a minor delay and another calls it catastrophic, investigate the difference before averaging numbers. One may be assuming that repeated activation creates duplicate bookings. Verify that assumption. A missing progress message and a confirmed duplicate transaction are different findings with different evidence and potentially different urgency.
Keep repair effort separate from severity. A ten-minute text fix is not automatically more important than a difficult core-task failure, although it may be sensible to deliver both in the same release. A useful triage decision states the user consequence, uncertainty, owner, next action, and the condition that would change the priority.
| Finding | Current judgment | Unknown or follow-up | Next action |
|---|---|---|---|
| HE-02 | Prioritize: the capacity failure offers no usable explanation | How often the capacity conflict occurs in real bookings | Repair the specific response and verify it with the service contract |
| HE-03 | Prioritize within the recovery repair | Burden with real field length and repeat attempts | Preserve suitable fields; inspect the retry journey |
| HE-01 | Investigate state feedback and repeat activation | Whether a repeated action can create duplicate records | Test delayed and repeated actions before making a stronger claim |
Propose a repair that tells the truth about the outcome
For a confirmed capacity conflict, an appropriate recovery message might say: 'This session has just filled up. No place was reserved. Your contact details are still here; choose another session to continue.' That wording is useful only if those statements are true. If the system does not know whether the request succeeded, it must not claim that no place was reserved or invite an immediate duplicate attempt.
An uncertain response needs a different design. For example, after a connection interruption, the next step may be to check the booking status before retrying. Specify how the interface obtains that status and what the visitor sees while it remains unknown. Avoid solving a visual feedback problem with a reassuring sentence that misrepresents the underlying state.
The proposed design should also preserve the visitor's context. Keep the workshop visible, distinguish the unavailable session from available alternatives, and retain appropriate contact details for the retry. If the system changes the selected date automatically, make that change explicit and require the visitor to review it. A successful request for the wrong session would not be a successful recovery.
This is why a repair description should include both interface behavior and observable outcome. 'Add a spinner' is incomplete. 'While the request is pending, show that booking is in progress; when it finishes, show a confirmed reservation, a known failure with recovery, or an unresolved status with a way to check' gives the implementer and reviewer something concrete to verify.
| Known state | What the interface can truthfully say | Next action |
|---|---|---|
| Confirmed reservation | A place is reserved for the named session | Review confirmation details |
| Confirmed full session, no reservation | The session is full; no place was reserved | Choose an available session with appropriate input retained |
| Outcome not yet known | The booking status has not been confirmed | Check the result before inviting another reservation |
Use this report template for the next finding
Copy the fields below into a document or issue tracker. Keep one record per actionable problem, linking related records when the same transition exposes several problems. The template includes evidence and verification because a persuasive paragraph alone is not enough for another person to reproduce, repair, and close a finding.
During consolidation, merge true duplicates while retaining every source observation. Two reports with the same heuristic label may describe different bugs. Conversely, two reports using different labels may describe the same lost-input behavior. Compare the trigger, observed result, and affected task instead of merging by title alone. Keep a disagreement if it changes the interpretation or priority.
| Field | Filled example: HE-03 | Your finding |
|---|---|---|
| Task and version | Reserve a workshop place, mobile prototype B | |
| Starting conditions | Thursday 18:00 selected; test name and email entered | |
| Steps | Submit; return the full-session fixture; choose another session | |
| Observed result | Name and email are empty after the conflict response | |
| Evidence | Before/after captures from the same attempt; attach real files | |
| Principle and reasoning | Help users recognize, diagnose, and recover from errors: clearing unrelated input obstructs recovery from the capacity conflict. | |
| Consequence | Additional work is required to retry; actual abandonment is unknown | |
| Priority rationale | Core recovery path; exposure and total re-entry burden still need evidence | |
| Proposed remedy | Retain appropriate input and make the unavailable session clear | |
| Verification | Known conflict preserves input; new choice is reviewed; final reservation matches it | |
| Owner and result | Assign a person; record checked version, result, and remaining questions |
Consolidate duplicate findings without losing evidence
Two evaluators may report the same failure using different heuristic labels. Suppose one reports that Error 409 does not explain what happened, while another reports that the full-session screen offers no next action. Review their captures and reproduction steps together before deciding whether these are one issue with two acceptance conditions or separate failures.
For the booking example, combine those reports under HE-02 only if they concern the same confirmed capacity response. Preserve both evidence links and require both a clear explanation and a working alternative-session action. Keep HE-03 separate because lost contact input remains a distinct defect even after the message is repaired.
| Inputs | Decision | Acceptance / closure evidence |
|---|---|---|
| Reviewer A: cryptic Error 409; reviewer B: no recovery action | One HE-02 record with both observations attached | Known capacity rejection explains no reservation and allows another session |
| Reviewer C: contact values disappear | Keep HE-03; link to HE-02 | Before/after test proves appropriate input survives the rejection |
| Reviewer D: repeat activation may duplicate reservations | Investigate rather than assume a confirmed duplicate | Record actual request and reservation outcomes before setting severity |
| Developer marks message fixed | Keep issue open until checked | Attach checked version, original reproduction, result and unresolved conditions |
Close the finding with a repeatable check
After implementation, repeat the original steps on the changed version. For HE-03, the confirmed full-session fixture should leave the appropriate contact values intact, allow a different valid session, and produce a confirmation for that chosen session. Test the successful path as well: preserving failed input should not cause an old session or stale response to overwrite the new selection.
For HE-02, read the message alongside the actual result it represents. Confirm that a capacity conflict and an uncertain timeout are not treated as equivalent. For HE-01, inspect a delayed response long enough to see the pending state, then check what happens if the action is activated again. A screenshot of a spinner establishes its appearance; it does not establish that duplicate requests are handled correctly.
Record the version checked and whether each acceptance condition passed. If a participant study is needed, give participants the visitor's situation without explaining the intended interface solution, then observe their recovery. That study can test an unresolved expectation about understanding or behavior. It should not be relabeled as confirmation merely because the evaluator likes the revised screen.
The finished evaluation is a decision aid: these problems were reproduced in these conditions, these repairs were verified, and these questions still need evidence. A long list of heuristic names is not the goal. The report earns its value when another person can follow it from a specific difficulty to a justified change and a credible check.