How to Run a Heuristic Evaluation?

Most website usability problems are predictable. A form wipes your input after one typo. A menu hides the page you came for. A checkout button shows nothing for three seconds, so you click it again and pay twice.

You don't need twenty test participants to find problems like these. A heuristic evaluation catches them with a few trained reviewers, a shared set of principles, and a disciplined way to rank what they find.

The method is an expert inspection of an interface against recognized usability principles. It works on a wireframe, a clickable prototype, or a live site, and a small team can finish one in days.

The catch is that it predicts problems instead of measuring them. Its value depends on how you run it, how you score the findings, and what you pair it with.

Key Takeaways

• A heuristic evaluation is an expert inspection that checks an interface against usability principles, usually Nielsen's 10 heuristics, without recruiting users.
• One evaluator misses most problems. Three to five evaluators working independently, then merging their findings, is the standard setup.
• Every finding needs a severity rating on the 0 to 4 scale, or the output stays a list of opinions instead of a fix plan.
• The method is fast and cheap but produces false positives, so confirm high-severity findings with usability testing before you rebuild anything.
• AI models now work well as an extra evaluator for layout and consistency issues. They still miss problems that span several screens.

What a Heuristic Evaluation Is

A heuristic evaluation is a usability inspection method. Evaluators walk through an interface, compare what they see against a set of broad usability principles called heuristics, and record every place the design breaks one.

"Heuristic" means a rule of thumb. The principles describe what good interfaces do in general terms, so evaluators have to interpret them for each screen.

10 Usability Heuristics by Clay

Jakob Nielsen and Rolf Molich introduced the method in 1990 as a cheaper alternative to formal lab testing. Their own experiments exposed its biggest weakness: individual evaluators found only 20 to 51 percent of the usability problems in the interfaces they reviewed. Pooling several evaluators closed most of that gap. That finding still shapes how the method is run.

Three things a heuristic evaluation isn't:

• It isn't usability testing. No real users take part, so you learn what's likely to cause trouble, not what actually does.
• It isn't a freeform expert review. An expert review relies on one person's judgment. A heuristic evaluation ties every finding to a named principle, which makes findings comparable and harder to dismiss.
• It isn't an accessibility audit. Some heuristics overlap with accessibility, but conformance needs a separate check against WCAG standards.

The output is a list of usability problems, each tied to the heuristic it violates, the screen where it happens, and a severity rating. A good one reads like a prioritized fix plan.

Nielsen's 10 Usability Heuristics, With Website Examples

Pros and Cons of Heuristic Evaluations

The 10 usability heuristics, refined in 1994, remain the default set for website reviews. Each one below comes with the website violation evaluators flag most often and the questions that catch it.

1. Visibility of System Status

Users should always know what the system is doing. The classic website violation is a submit or payment button that shows no loading state, so people click again and create duplicate orders.

We designed the Joe & The Juice ordering app around this principle, with animations that show the current stage of every order while customers wait.

Ask: does every action produce visible feedback within a second? Do multi-step flows show progress?

2. Match Between the System and the Real World

The interface should speak the user's language, not the company's. Websites break this with navigation built on internal labels, like product codenames or a vague "Solutions" menu.

Ask: would a first-time visitor know what each menu item contains?

3. User Control and Freedom

People make mistakes and need a visible way out. Common violations include modals with no close button, multi-step forms without a back option, and carts where removing an item can't be undone.

Ask: can users exit any state without losing their work? Can they undo the last destructive action?

4. Consistency and Standards

The same action should look and behave the same way everywhere, and the site should follow conventions users learned elsewhere. Watch for two button styles doing one job and logos that don't link home.

When we built a design system for Corsair, the existing icon library mixed metaphors and grid rules, so we rebuilt it as one consistent set.

Ask: do repeated elements behave identically? Does the site follow platform conventions?

5. Error Prevention

Good design stops errors before they happen. Free-text date fields, forms that only validate on submit, and one-click deletes are frequent offenders, and checkout flows deserve the closest look.

In our ecommerce redesign for Serena & Lily, we rebuilt the purchase journey from bag to order confirmation to strip out the steps where shoppers stumbled.

Ask: are risky actions confirmed? Do inputs validate inline, before the user hits submit?

6. Recognition Rather Than Recall

Make options visible so users don't have to remember them. Websites fail this when desktop navigation hides behind a hamburger menu, or filters reset after users open a product.

For Grayscale, an expanding product portfolio had made navigation hard to scan, so we added an overview table that lets visitors compare products at a glance before opening a detail page.

Ask: are the most-used options visible without digging? Does the site remember selections across pages?

7. Flexibility and Efficiency of Use

Serve newcomers and repeat users at the same time. Content-heavy sites without search and web apps without saved preferences or shortcuts fall short.

Our UX work for Corsair's device customization software had to satisfy both beginners and professional gamers, so the flows offer quick defaults alongside deeper controls.

Ask: can experienced users skip steps? Can people tailor frequent actions to their workflow?

8. Aesthetic and Minimalist Design

Every extra element competes with the ones that matter. Rotating hero carousels, three competing calls to action, and stacked pop-ups are the usual suspects.

When we redesigned the Yahoo! Games portal, managing cognitive load across a large game library shaped the navigation and category structure from the start.

Yahoo! Games by Clay

Ask: does each element earn its space? Does the visual hierarchy point to one primary action per screen?

9. Help Users Recognize, Diagnose, and Recover From Errors

Error messages should explain the problem in plain language and suggest a fix. "Error 400," a red banner that doesn't name the broken field, and 404 pages with no way forward are common failures.

Ask: does each error message say what went wrong and how to fix it? Does recovery keep the user's input?

10. Help and Documentation

Some tasks still need guidance, and help buried in the footer fails users at the exact moment they need it.

In the Fooji platform, we placed tips and descriptive elements inside the flows where users needed them, instead of in a separate help center.

Ask: can users find help from the screen where they're stuck? Is documentation searchable and focused on tasks?

Heuristic Evaluation vs Usability Testing

The two methods answer different questions, and treating them as substitutes is the costliest mistake teams make with heuristic evaluation.

• Who takes part: a heuristic evaluation uses three to five trained evaluators. Usability testing uses representative users.
• What design stage it needs: a heuristic evaluation works on wireframes and static mockups. Usability testing usually needs a clickable prototype or a live site.
• What it finds: a heuristic evaluation finds violations of known principles, including consistency and cosmetic issues users rarely mention. Usability testing shows where real people fail tasks, misread content, or give up.
• Main risk: heuristic evaluation produces false positives and misses domain context. Usability testing only covers the tasks you script, with a small sample.

Heuristic Evaluation vs Usability Testing

Run a heuristic evaluation first when the UX design is early, the budget is tight, or you're about to test with users. Clearing known violations beforehand means test sessions surface deeper problems instead of the same broken button five times.

Go straight to usability testing when the open question is whether people understand your offer, when the domain is specialized enough that general experts can't judge it, or when a flow carries real financial or legal risk.

For Discover, we built multiple iterations of the card activation flow as iOS and Android prototypes and tested them with users, because no expert review could settle which version people would complete.

For questions about live traffic, such as which of two layouts converts better, A/B testing is the right tool. Never ship a checkout, onboarding, or payment flow on heuristic evaluation alone.

From Google's wearable experience to Snapchat’s AR try-on lenses, we've helped teams across every industry design products people actually want to use. Let's talk about yours.

How to Run a Heuristic Evaluation in 6 Steps

Heuristic Evaluation Process

Step 1: Define the Scope and User Tasks

Scope by tasks, not pages. Pick three to six core tasks visitors come to complete, such as finding pricing or checking out, and list every screen and state each one touches, including errors and empty states.

Note the target users, since a problem that blocks first-time visitors may not matter to daily users.

Step 2: Choose the Heuristic Set

Nielsen's 10 heuristics cover most websites. Add a domain-specific set when the interface has needs the general list misses. Shneiderman's eight golden rules are a common alternative, and mobile apps, games, and AI products all have published heuristic sets of their own.

Keep the final list short enough for evaluators to hold in their heads, and give everyone the same version.

Step 3: Pick Your Evaluators

Use three to five people. Evidence on expertise backs this up: three to five usability specialists found 74 to 87 percent of usability problems, while five non-specialists uncovered only about half. The strongest evaluators know both usability and the product's domain. A practical team pairs a designer and a researcher with someone who understands the business, like a product manager for a fintech dashboard.

Avoid making the person who designed the interface the only evaluator. They know how it's supposed to work, which is exactly what hides its problems.

Step 4: Run Independent Passes

Each evaluator reviews the interface alone, usually in a one- to two-hour session per scope. Two passes work best. The first pass follows the tasks to get a feel for the flow. The second goes element by element against each heuristic.

No discussion happens until everyone is done. Independence matters because some of the hardest-to-find problems are caught by evaluators who otherwise find few issues. Group sessions pull everyone toward the loudest opinion and lose those outliers.

Step 5: Log Every Issue in the Same Format

A shared template keeps findings comparable. Each entry needs a screenshot or location, the task where it occurs, the heuristic it violates, what happens, and why it matters to the user. One problem per entry. "The nav feels cluttered" isn't a finding. "Seven top-level items with overlapping labels, so users can't tell where pricing lives" is.

Step 6: Merge Findings in a Debrief

Bring evaluators together to deduplicate. Keep a count of how many people found each issue, since problems several evaluators spotted on their own tend to be real and serious. Discard anything nobody can tie to a heuristic or a user consequence.

Rating Severity and Prioritizing Fixes

A list of 60 problems with no ranking gets ignored. The standard fix is the 0 to 4 severity scale for usability problems:

• 0: not a usability problem
• 1: cosmetic, fix only if time allows
• 2: minor, low priority
• 3: major, high priority
• 4: usability catastrophe, fix before release

Three factors drive the score. Frequency asks how many users will hit the problem. Impact asks how hard it is to get past. Persistence asks whether users overcome it once or run into it every visit. A confusing label on a page few people visit scores lower than a broken filter on your product listing page, even if the label is the uglier mistake.

Each evaluator rates severity on their own, after seeing the merged list, and you average the scores. A single person's ratings swing too much to build a roadmap on.

Severity isn't the same as priority, though. Cross it with effort and business stakes:

• Severity 4 issues get fixed before the next release, whatever they cost.
• Severity 3 issues with low effort go into the current sprint.
• Severity 3 issues that need a redesign go to the roadmap, with a usability test planned to confirm the problem first.
• Severity 1 and 2 issues get batched into design system cleanup.

What a Heuristic Evaluation Report Should Contain

Open with a one-page summary: scope, evaluators, heuristic set, and the five most severe problems. Stakeholders often read nothing else.

Group the detailed findings by user flow. Product managers and engineers think in flows like signup or checkout, and a report organized that way turns straight into tickets.

Heuristic Evaluation Template

Each finding should carry the screenshot, the violated heuristic, the averaged severity, how many evaluators found it, and a specific recommendation. Recommend a fix direction, not a full redesign.

Flag which findings need validation with users before anyone builds a fix. After the fixes ship, run a short follow-up evaluation on the changed screens to confirm the problems are gone and nothing new broke.

Where Heuristic Evaluation Falls Short

False positives. Evaluators flag issues that real users never stumble on. Rating severity independently and validating major findings with users keeps these from eating your roadmap.

Missing context. General principles can't tell you whether an approval flow matches how a finance team actually works. Domain-heavy products need evaluators with domain knowledge, or user research to supply the missing context.

Evaluator fatigue. Attention drops over long sessions. In one comparison, human evaluators' detection rate fell as they moved through later tasks. Short sessions with breaks and a rotated task order help.

Pair the evaluation with methods that cover those gaps:

• Cognitive walkthrough steps through tasks as a first-time user would, so it catches learnability problems that experienced evaluators skim past.
• Usability testing confirms which predicted problems real people actually hit.
• Behavior analytics show where visitors drop off on the live site. User behavior data tells you which flows deserve an evaluation first.
• Accessibility evaluation checks conformance with WCAG, including screen reader and keyboard use.

Using AI as an Extra Evaluator

Large language models can now run a credible first pass. In one controlled comparison on two mobile apps, a carefully prompted LLM identified 73 to 77 percent of known usability issues, while five experienced human evaluators combined found 57 to 63 percent. The model was especially strong on layout inconsistencies and didn't tire across tasks.

The same comparison showed the limits. The model caught only 43 to 50 percent of violations that spanned multiple screens, compared with 83 to 86 percent for human evaluators, and it flagged many non-issues because it misread interface components and app conventions. Results also vary widely with setup.

On a web system reviewed from screenshots, GPT-4o identified only 21.2 percent of the issues human experts found, even while reporting new ones the experts missed. LLM feedback on UI mockups has the same profile: useful for catching subtle errors, not reliable without a human checking it.

The practical setup treats AI as one more evaluator on the panel:

• Give the model screenshots in task order, the user goal, and the heuristic list, and ask for the violated heuristic, a severity score, and a rationale for each issue.
• Let humans own cross-screen flows, domain conventions, and final severity ratings.
• Treat every AI finding as a candidate until an evaluator confirms it in the debrief.

Used this way, AI extends coverage on large sites where humans would otherwise sample a few templates.

If you need more professional AI assistance, we can help. Whether it's web design, branding, or UI/UX, we'll deliver it with a perfect blend of AI and human creativity. Let’s talk.

Read More

• UI vs UX: What's the Difference and Why It Matters
• What Is a UX Design Agency and When You Need One?
• Clay Global’s Digital Design Case Studies

FAQ

How long does a heuristic evaluation take?

For three to six tasks, each evaluator needs one to two hours, and the debrief and severity rating add a few more. Most teams go from kickoff to report within a week.

Is a heuristic evaluation the same as a UX audit?

No. A UX audit usually combines a heuristic evaluation with analytics, accessibility, content, and conversion reviews. The heuristic evaluation usually sits at its center.

Can one person do a heuristic evaluation?

They can, but expect to miss well over half the problems. If you only have one evaluator, run two sessions on different days, add an AI pass, and validate the top findings with a handful of users.

Can you run a heuristic evaluation on wireframes or Figma prototypes?

Yes, and that's one of its biggest advantages. Wireframes won't reveal visual hierarchy issues, but they expose problems in structure, labeling, and flow logic before anyone writes code.

What's the difference between a heuristic evaluation and a cognitive walkthrough?

A heuristic evaluation checks the whole interface against a set of principles. A cognitive walkthrough follows specific tasks step by step and asks, at each step, whether a new user would know what to do and understand the result. Walkthroughs go deeper on learnability and narrower on coverage.

Do Nielsen's heuristics work for mobile apps?

They apply, but they miss mobile-specific issues like touch target size, thumb reach, and gestures with no visible cue. Teams reviewing apps often add a mobile heuristic set alongside the original 10.

How often should you run a heuristic evaluation?

Run one at major design milestones, before usability testing rounds, and before significant releases. On live sites, reviewing core flows once or twice a year catches the drift that builds up as teams add features.

Can a heuristic evaluation find accessibility problems?

It finds some, like unclear error messages or inconsistent navigation. It won't systematically verify contrast ratios, screen reader behavior, or keyboard access, so it doesn't replace an accessibility audit.

What tools do you need?

A shared spreadsheet or board in Figma or FigJam for logging findings, a screenshot tool, and a consistent template are enough. Some teams add an AI model for a first pass across every screen.

Can you use heuristic evaluation to benchmark competitors?

Yes. Running the same tasks and heuristics on two or three competitor sites shows where you're ahead or behind. Keep the evaluators and severity scale identical so the comparison holds.

What should you do when evaluators disagree on severity?

Averaging handles most of it. When scores sit more than two points apart, discuss the issue, because the gap usually means evaluators pictured different users. Agree on the scenario, then re-rate.

Make the Findings Count

A heuristic evaluation is one of the cheapest ways to find out what's wrong with a website before users tell you through bounce rates and support tickets. What separates a useful evaluation from a forgotten spreadsheet is the discipline around it: independent evaluators, consistent logging, honest severity ratings, and a clear line from each finding to a fix or a test.