{{img:hero}}A heuristic review is the quickest way to spot usability issues without recruiting users—but only if your notes are specific and comparable.

Use this as a one-page cheat sheet: run the checks, write evidence, avoid the traps.

This is not a replacement for usability testing. It’s a fast, repeatable “find obvious friction” pass you can do anytime.

How to use this cheat sheet (10–30 minutes)

{{img:process}}Pick one flow (example: sign up, checkout, save, share). Start at the entry point and go until the first “success moment.”

  • Step 1: Set a narrow scope. One device type, one persona, one goal. Don’t review the whole product.
  • Step 2: Do a silent pass. Go through once without writing anything; just notice where you hesitate.
  • Step 3: Do a writing pass. Capture issues using the format: Where → What happened → Why it’s a problem → Suggested fix.
  • Step 4: Rate severity lightly. Use: Blocker, Major, Minor. (If you can’t decide, it’s usually Minor.)
  • Step 5: Group and dedupe. Merge repeats into one root issue so you don’t “fix” the same thing five times.

Keep screenshots or timestamps if possible. A review with evidence travels farther.

The checklist: 20 fast heuristic checks

Run these as questions. If you answer “no,” you likely found an issue.

  • Clarity of purpose: Can a new user tell what this screen is for in 5 seconds?
  • Visible system status: Is it obvious what’s loading, saving, or failed?
  • Feedback timing: Does the UI acknowledge actions immediately (even if work continues)?
  • Back/undo safety: Can users recover from mistakes without panic?
  • Defaults: Are defaults safe and likely correct for most people?
  • Progressive disclosure: Are advanced options hidden until needed?
  • Consistency: Do similar actions look and behave the same across screens?
  • Affordances: Do clickable things look clickable (and non-clickable things don’t)?
  • Label accuracy: Do labels match the user’s language (not internal jargon)?
  • Error prevention: Does the UI prevent errors instead of only explaining them?
  • Error messages: When something fails, does it say what happened and what to do next?
  • Input effort: Is typing minimized (autofill, pickers, sensible constraints)?
  • Field requirements: Are required/optional fields unmistakable before submit?
  • Focus management: Does focus move logically (especially on mobile and forms)?
  • Navigation: Can users tell where they are and how to get back?
  • Discoverability: Are key actions visible without hunting in menus?
  • Information hierarchy: Do headings, spacing, and emphasis guide the eye correctly?
  • Accessibility basics: Is text readable, contrast adequate, touch targets generous?
  • Performance perception: Does it feel fast (skeletons, caching cues, no jank)?
  • Completion: After success, is the next step clear (and not a dead end)?

If you only have 10 minutes, prioritize: clarity, system status, errors, input effort, completion.

Common pitfalls: why heuristic reviews become “opinions”

{{img:pitfalls}}Most bad UX review notes aren’t wrong—they’re just non-actionable. These are the patterns to catch in yourself.

  • Vague judgments: “This feels off” / “Make it cleaner.” Replace with: what user tries to do, what blocks them, what to change.
  • Skipping the user goal: If you don’t name the goal, you’ll optimize aesthetics over success.
  • Reviewing in ideal conditions: Great Wi‑Fi, full attention, perfect data. Real users have interruptions, weak networks, and messy info.
  • Conflating preference with usability: “I don’t like this pattern” isn’t the same as “users can’t find it.”
  • Over-indexing on edge cases: Note them, but don’t let rare scenarios dominate your top fixes.
  • Fixing symptoms repeatedly: Five confusing labels often point to one taxonomy problem.
  • Ignoring content: Microcopy, empty states, and button labels are core UX—not finishing touches.
  • Not separating severity from effort: Something can be Minor but cheap, or Major but hard. Track both.

A useful note makes a developer or designer say: “I know exactly what to change.”

How to write notes that survive handoff

Use one template consistently so your review is scannable and comparable across flows.

  • Where: screen + step (e.g., “Checkout → Shipping → Submit”).
  • Trigger: what the user does (tap, type, scroll, wait).
  • Observed result: what the UI shows (or doesn’t show).
  • Why it matters: confusion, error risk, extra time, trust hit.
  • Suggested fix: one concrete change (copy, layout, validation, feedback).
  • Severity: Blocker / Major / Minor.

One sentence per bullet is enough. Clarity beats volume.

Severity, quickly: a practical rubric

{{img:severity}}Severity is about user impact, not how much the team dislikes it.

  • Blocker: prevents completion, causes data loss, or creates a trust/security fear. Example: payment fails silently.
  • Major: users can finish, but many will hesitate, make errors, or need retries. Example: required fields aren’t marked until after submit.
  • Minor: friction, polish, or clarity improvements. Example: unclear icon label, slightly confusing empty state.

If your list is all Blockers, you’re probably rating emotion, not impact.

Fast “sanity checks” to run at the end

These catch the issues a checklist can miss: pacing, trust, and cohesion.

  • Read it out loud: button labels, headings, error messages. If you stumble, users will too.
  • Do it one-handed: especially on mobile. Can you reach the primary action comfortably?
  • Try bad input: blank fields, wrong formats, long names, weak passwords, slow network.
  • Look for trust moments: pricing, permissions, data sharing, irreversible actions—do you explain before asking?

Takeaway: a good heuristic review is “evidence + next step”

A one-page UX heuristic review works when it stays concrete: a specific flow, observable friction, and a fix you can actually build. Run the checklist, watch for the pitfalls, and keep your notes consistent.