Heuristic Evaluation

Heuristic Evaluation (Expert UX Audit)

A heuristic evaluation is a structured way for one or more people to inspect an interface against a set of usability principles ("heuristics") and surface the problems a designer would want to fix. It's fast, cheap, and needs no participants — which is its strength and its limit. It reliably catches the generic, recognizable problems (unclear labels, missing feedback, inconsistent patterns, dead ends), but it does not tell you what real users actually do, where they get genuinely stuck, or whether they succeed. Say this plainly to the user when relevant: a heuristic evaluation complements usability testing with real users, it doesn't replace it.

Use this skill to run an evaluation end to end, or to help with any one piece of it (pick a heuristic set, write up an issue, rate severity, structure a report).

How to run an evaluation

1. Set up the evaluation

Before inspecting anything, pin down:

• What's being evaluated — the whole product, one flow (e.g. onboarding, checkout), or a specific screen. A focused scope produces sharper findings.
• Who the users are and what they're trying to do. Usability is relative to a user and a goal. "Is this clear?" only has an answer once you know clear to whom, doing what. Even a rough persona and top tasks sharpen every judgment.
• The context of use — device, environment, expertise level, frequency of use. An expert tool used daily forgives density that a consumer app can't.
• Which heuristics you'll evaluate against (see below).

If the user has screenshots, a prototype link, or a live URL, work from that. If they don't, don't fabricate findings about an interface you can't see — instead, give them the heuristic set and issue-logging structure so they can walk their own product, and offer to do the first pass together from screenshots or a recording.

2. Choose a heuristic set

Heuristics are the lens. The most widely used general-purpose set in the field is Jakob Nielsen's ten usability heuristics; evaluate against these unless the product calls for something more specialized. Expressed in plain terms, a good interface should:

1. Show system status. Keep people informed about what's happening through timely, visible feedback — loading states, confirmations, progress.
2. Match the real world. Speak the user's language and follow real-world conventions rather than internal jargon or system-oriented terms.
3. Give control and freedom. Provide clear exits, undo, and a way back out of mistakes without feeling trapped.
4. Be consistent and follow standards. The same thing should look and behave the same way; follow platform and industry conventions so people don't have to relearn.
5. Prevent errors. Design so the slip can't happen in the first place — constraints, good defaults, confirmation on destructive actions.
6. Favor recognition over recall. Keep options, actions, and information visible so people don't have to remember things across steps.
7. Be flexible and efficient. Let novices succeed while giving experts accelerators (shortcuts, saved states) to go faster.
8. Keep it minimal. Every extra element competes for attention; remove or downplay what isn't needed so the essential stands out.
9. Help users recover from errors. Error messages should be in plain language, say what went wrong, and offer a way to fix it.
10. Provide help and documentation. When needed, help should be easy to find, task-focused, and concrete.

For specialized products, supplement with domain-appropriate heuristics — e.g. form-design principles for data-entry-heavy tools, accessibility guidelines (contrast, keyboard operability, labels) for any product that must be inclusive, or content-clarity checks for information-dense screens. Name the supplementary lens you're adding and why.

3. Inspect systematically

Walk the interface deliberately, not randomly:

• Go screen by screen and flow by flow, in the order a user would meet them. Include the unglamorous states: empty states, loading, errors, edge cases, the very first use.
• Do two passes. First pass: get a feel for the flow and overall structure. Second pass: inspect each element closely against every heuristic. Single-pass evaluations miss issues that only make sense once you know where the flow goes.
• For each screen, ask of every heuristic: is this honored or violated here?
• Capture the problem where you see it, with enough specificity that someone could find the exact spot and understand the issue without you narrating it.

4. Log each issue consistently

Freeform notes don't aggregate. Record each issue with the same fields so the findings can be sorted, counted, and prioritized:

• Location — the screen/flow/element where it occurs.
• The problem — what's wrong, described concretely (what a user would experience), not just "confusing."
• Heuristic(s) violated — which principle(s) it breaks; an issue can break more than one.
• Severity — see below.
• Recommendation — a concrete direction to fix it (even tentative).
• Optionally an evidence note or screenshot reference.

A lightweight tagging system on top of heuristics helps teams triage at a glance — for example tagging each issue by the type of fix it implies (clarity, consistency, efficiency, visual/UI, error-handling, accessibility). Define whatever tags fit the product and use them consistently; the value is a shared vocabulary the team can filter on, not the specific labels.

5. Rate severity

Severity is what turns a long list into a plan. Rate each issue by combining:

• Impact — how badly it hurts the user when hit (blocks the task entirely? causes errors? slows them down? merely cosmetic?).
• Frequency — how many users will hit it and how often (on a core path everyone travels, or a rare edge case?).
• Persistence — is it a one-time hurdle people learn around, or a repeated irritation?

A simple, defensible scale:

• Critical — blocks task completion or causes data loss; fix before release.
• Serious — causes real difficulty, errors, or frustration on a common path; high priority.
• Minor — slows or annoys but users get through; fix when convenient.
• Cosmetic — polish; fix if time allows.

Always show the reasoning for a rating, not just the label — "Serious: on the primary signup path (high frequency), users can't tell the form submitted, so some will submit twice." That reasoning is what lets a PM trust and act on it.

6. Write the findings report

Structure the report so a busy team can act on it:

# Heuristic Evaluation: [product / flow]
## Overview
  What was evaluated, against which heuristics, on what device/version, scope and limits
## Summary
  Headline: how many issues by severity, the 2–3 biggest risks, overall read
## Findings (most to least severe)
  For each issue: location, problem, heuristic(s), severity + reasoning,
  recommendation, screenshot/evidence
## Recommendations, prioritized
  What to fix first, grouped by effort/impact where possible
## Method & limitations
  Expert inspection, no users involved; note this complements user testing

Lead with severity, keep each finding self-contained, and make recommendations concrete. A finding a developer can act on without a meeting is worth ten vague observations.

Producing the deliverables

Generate a ready-to-use findings report (default Markdown; offer .docx or a .xlsx issue log if the user wants to hand it around or track fixes — a spreadsheet with one row per issue and columns for location/heuristic/severity/ recommendation/status is the natural format for triage). Use clearly marked [placeholders] for anything you can't observe, and never invent findings about an interface you haven't actually seen.

Pairs well with

• accessibility-review — run alongside for the a11y dimension; together they cover usability and accessibility.
• ux-usability-study — expert inspection is fast and cheap; user testing tells you what people actually do. Use both.
• design-fundamentals — the underlying principles behind many heuristic findings.

Sources & scope

Nielsen's ten heuristics are an established framework you can name and reference freely. Evaluating the user's own product — their screens, notes, prior findings — is exactly the intended use. Two cautions about other people's material: don't reproduce a third party's copyrighted text (e.g. a paid inspection template), and when you invent an illustrative example, use fictional findings rather than another organization's confidential evaluation.