What does a heuristic evaluation look like?

A heuristic evaluation produces a list of usability findings, each tied to one of Nielsen's 10 heuristics, rated by severity (0-4), and accompanied by a recommended fix. Findings are usually collected in a spreadsheet or table and reviewed as a team before prioritising.

How do you write up heuristic evaluation findings?

Each finding should state what the problem is, which heuristic it violates, where it appears in the interface, a severity rating from 0 (not a problem) to 4 (usability catastrophe), and a concrete recommendation. Keeping each entry brief and action-oriented makes triage faster.

What is a severity rating in a heuristic evaluation?

A severity rating is a 0-4 scale used to prioritise findings. 0 means no real problem; 1 is cosmetic only; 2 is a minor usability problem; 3 is a major problem that should be fixed as a high priority; 4 is a usability catastrophe that must be fixed before launch.

How long does a heuristic evaluation take?

A single evaluator typically needs 1-2 hours to review a focused user flow. With 3-5 evaluators - the number Nielsen recommends for maximum coverage - expect a half-day for individual reviews plus time to consolidate findings, so a full evaluation usually runs 1-2 days in total.

Heuristic Evaluation Example: A Step-by-Step Walkthrough

A heuristic evaluation is one of the fastest ways to surface usability problems without recruiting a single participant - but the method only clicks once you see it applied to a real interface. This walkthrough takes a hypothetical e-commerce checkout flow and evaluates it against Nielsen's 10 heuristics, producing the kind of findings table you would hand to a product team.

If you want the theory first, start with our heuristic evaluation guide and the full list of Nielsen's 10 usability heuristics. If you want a blank template to fill in yourself, grab our heuristic evaluation template. This post focuses on the example itself.

The interface we are evaluating

For this walkthrough we will use a fictitious e-commerce site called "ShopFlow" - a purely hypothetical teaching example created to illustrate the method. The flow covers four screens: cart review, delivery details, payment details, and order confirmation. Nothing here refers to any real company or client.

We are playing the role of a single evaluator. In practice you would run 3-5 evaluators independently and then consolidate findings - that spread catches significantly more issues than one person alone.

How the severity scale works

Before we look at findings it helps to have the severity scale in mind:

| Rating | Label | What it means | |--------|-------|----------------| | 0 | Not a problem | Cosmetic observation only; no action needed | | 1 | Cosmetic | Fix only if time allows | | 2 | Minor | Low priority fix | | 3 | Major | High priority; fix before next release | | 4 | Catastrophe | Must fix before launch |

Severity combines two factors: how frequently users will encounter the problem, and how badly it affects their ability to recover. A problem that appears once and has an obvious workaround is a 1 or 2. A problem that blocks task completion for most users is a 4.

Walking through the checkout: heuristic by heuristic

Not every heuristic will produce a finding in every interface. Below we go through all ten and record what we observe in ShopFlow.

1. Visibility of system status

Finding: After the user clicks "Place order", the button shows no loading state. There is no spinner, no progress indicator, and no feedback for approximately four seconds while the payment processes.

Users in this situation often click the button a second time, risking a duplicate charge.

Severity: 3

Recommendation: Disable the button immediately on click, show a spinner inside it, and add a brief text label such as "Processing your order..." so users know something is happening.

2. Match between system and the real world

Finding: The payment screen uses the label "Card verification value" rather than "CVV" or "Security code". Research consistently shows that everyday users recognise the shorter abbreviation more quickly than the expanded form.

Severity: 1

Recommendation: Change the label to "Security code (CVV)" - the abbreviation first, the expanded form in parentheses for those who need it.

3. User control and freedom

Finding: There is no way to edit the delivery address once the user has moved from the delivery screen to the payment screen. The only option is to use the browser back button, which clears the payment form they have already filled in.

Severity: 3

Recommendation: Add an "Edit" link next to the delivery summary on the payment screen. This lets users correct mistakes without losing their payment entry.

4. Consistency and standards

Finding: The "Continue" button is right-aligned on the cart and delivery screens but centred on the payment screen. This inconsistency creates a brief moment of disorientation as users scan for the next action.

Severity: 1

Recommendation: Standardise the primary CTA button to right-aligned across all checkout screens, which also aligns with the convention on most major e-commerce sites.

5. Error prevention

Finding: The email field on the delivery screen accepts any string that contains "@". A user who types "me@" with nothing after it passes validation and only learns about the error after submitting the form.

Severity: 3

Recommendation: Apply RFC-compliant email validation on blur (when the user leaves the field) so they can correct the mistake before they attempt to continue. Inline validation at the field level is far less disruptive than a full-page error after submission.

6. Recognition rather than recall

Finding: On the order confirmation screen, the order reference number is shown once and there is no prompt to save or copy it. Users who need to contact support must remember it or scroll back through their email inbox.

Severity: 2

Recommendation: Add a "Copy order number" button next to the reference, and make the confirmation email subject line include the order number prominently.

7. Flexibility and efficiency of use

Finding: There is no option to save delivery details for returning customers. Every purchase requires re-entering the full address.

Severity: 2

Recommendation: After a successful order, prompt logged-in users to save their address for next time. This is a table-stakes feature for repeat purchase flows.

8. Aesthetic and minimalist design

Finding: The cart screen displays six promotional banners alongside the cart contents. The banners compete visually with the "Proceed to checkout" button and create a cluttered layout that slows the eye toward the primary action.

Severity: 2

Recommendation: Limit promotional content in the checkout flow to a single, low-contrast banner at most. Users who have already added items to their cart have signalled intent - interrupting them with cross-sells at this stage increases abandonment.

9. Help users recognise, diagnose, and recover from errors

Finding: When a card payment fails, the error message reads: "Transaction unsuccessful. Error code: 5412." The error code means nothing to the user and no guidance is given on what to do next.

Severity: 4

Recommendation: Replace technical error codes with plain-language messages. For a declined card, something like: "Your card was declined. Please check your card details or try a different card." If the failure reason from the payment processor suggests a specific fix (wrong CVC, expired card), surface that. Always provide a clear next step.

10. Help and documentation

Finding: There is no live chat, FAQ link, or help tooltip visible anywhere in the checkout flow. If a user is confused about delivery costs, returns, or payment security, they have to leave the checkout to find an answer - and many will not return.

Severity: 2

Recommendation: Add a persistent "Need help?" link in the footer of every checkout screen, opening a support page or chat widget without navigating away from the checkout.

Full findings table

Here is all ten findings consolidated into the format you would use in a real deliverable:

| # | Screen | Heuristic violated | Finding summary | Severity | Recommendation | |---|--------|--------------------|-----------------|----------|----------------| | 1 | Payment | Visibility of system status | No loading state on "Place order" button | 3 | Add spinner and disable button on click | | 2 | Payment | Match between system and real world | "Card verification value" unfamiliar to most users | 1 | Use "Security code (CVV)" | | 3 | Payment | User control and freedom | Cannot edit delivery address without losing payment entry | 3 | Add "Edit" link to delivery summary on payment screen | | 4 | Payment | Consistency and standards | Primary CTA button alignment varies across screens | 1 | Standardise to right-aligned | | 5 | Delivery | Error prevention | Email validation too permissive; errors caught too late | 3 | Inline validation on blur | | 6 | Confirmation | Recognition rather than recall | Order number shown once with no copy option | 2 | Add "Copy order number" button | | 7 | Delivery | Flexibility and efficiency | No address save option for returning users | 2 | Prompt to save after successful order | | 8 | Cart | Aesthetic and minimalist design | Six promotional banners compete with checkout CTA | 2 | Limit to one low-contrast banner in checkout | | 9 | Payment | Help users recognise and recover from errors | Payment failure shows opaque error code only | 4 | Plain-language error messages with next steps | | 10 | All screens | Help and documentation | No help access during checkout | 2 | Persistent "Need help?" link in footer |

What to do with findings once you have them

Gathering findings is only half the job. The next step is to prioritise them.

Start with all severity 4 findings - these are blockers. In this example, that is the payment error message (finding 9). No user should encounter a cryptic error code when their payment fails; that finding would go straight to the top of the sprint backlog.

Severity 3 findings (1, 3, and 5 in our table) form the second tier. They will cause visible friction for a meaningful proportion of users and should be fixed before the next release if at all possible.

Severity 1 and 2 findings can be triaged alongside other backlog items. They are real problems but not urgent ones.

If you ran 3-5 evaluators independently rather than one, you would merge all their findings before assigning final severity scores. A problem spotted by four out of five evaluators almost certainly warrants a higher severity than one only one person noticed - frequency of detection is useful signal even before you get real user data.

Heuristic evaluation as a starting point, not a verdict

A heuristic evaluation tells you where problems are likely to exist. It does not tell you how much those problems actually affect real users, or why. That is why experienced UX designers use it as a fast, low-cost input into a broader research programme rather than a replacement for usability testing.

Used well, a heuristic evaluation - like the one we have just walked through - can surface a decade's worth of known usability problems in a morning, giving teams a clear, prioritised list before a single participant walks in the door.

If you want to practise heuristic evaluation yourself with expert guidance, the UX Academy Beginner UX Design course covers the full research and evaluation toolkit in a live online format. The next cohort starts 5 September 2026, and you can get a feel for the teaching style first at a free UX/UI masterclass.