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'd 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're evaluating

For this walkthrough we'll 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're playing the role of a single evaluator. In practice you'd 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's 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's 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's 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's 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's 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 won't 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'd 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	Can't 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's 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'll 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're real problems but not urgent ones.

If you ran 3-5 evaluators independently rather than one, you'd 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 doesn't tell you how much those problems actually affect real users, or why. That's 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 (myuxacademy.com) Beginner UX (AI) Design course covers the full research and evaluation toolkit in a live online format. Cohorts start on 14 October 2026 and 12 January 2027, and you can get a feel for the teaching style first by booking a free 15-minute call with an advisor.