A UX Audit Checklist You Can Actually Use

This checklist is the heuristic evaluation step inside a larger process. If you want the whole picture first, the complete guide to running a UX audit covers scope, severity, and what happens after the report lands.

Most UX audit advice is a list of ten heuristics and a wish for good luck. You read it, nod, open the product, and still do not know what to write down. This is the checklist I actually work through when I audit a product, written so a designer doing their first audit can follow it point by point.

One rule before we start. An audit covers one flow at a time. Signup, onboarding, checkout, whichever one the business depends on. Auditing a whole product in one pass produces a shallow document about everything and a useful document about nothing.

Before you touch the product

Set yourself up so the findings connect to reality. Fifteen minutes of prep saves you from writing a document the team politely ignores.

• Write down the one action that makes this flow successful, in one sentence. Every finding gets judged against it.
• Get analytics access if you can. A drop-off number turns an opinion into a priority.
• Use the product as a real user, on a real account, at least once before you start taking notes.
• Test on the device most users actually use. If 70 percent of traffic is mobile, the audit is a mobile audit.

The first screen

Users decide whether to trust a screen in seconds. Most flows lose more people here than anywhere else.

• Can a stranger say what this product does and who it is for within ten seconds?
• Is there exactly one primary action, and does it visually dominate every secondary one?
• Does the headline describe a benefit or just name the product?
• Is anything competing with the primary action for attention, a banner, a popup, an animation?
• If a user arrives here from an ad or a link, does the screen match the promise that brought them?
• Is pricing, or the path to it, findable within one click? Hiding it reads as a trick and users punish tricks.

Core flow friction

Walk the scoped flow step by step and count everything the user has to do, read, or decide. Friction hides in steps everyone internally stopped seeing years ago.

• Count the steps from entry to success. Can any step be removed, merged, or deferred until after the first success?
• Does every screen make it obvious what to do next, without the user having to scan or guess?
• Is progress visible in flows longer than two steps, so users know how much is left?
• Can the user recover from going back, or does the flow lose their data and their patience?
• Are you asking for information before the product has shown any value? Every early field costs conversions.
• Does anything open in a new context, a tab, a modal, an app, that risks losing the user on the way back?
• Is the success state unmistakable, and does it point to the natural next action?

Forms

Forms are where products bleed users quietly. Every check here is boring and every one of them moves numbers.

• Does every field justify its existence, right now, in this step?
• Do labels stay visible while typing, or do placeholders vanish and take the context with them?
• Does validation happen inline as the user finishes each field, not as a slap after submitting?
• Are error messages specific about what to fix, or do they just announce failure?
• Do inputs use the right keyboard and autocomplete attributes on mobile?
• If submission fails, does the form keep everything the user typed?
• If the submit button is disabled, can the user tell why, or are they clicking a dead button in confusion?

The states nobody designs

Empty, loading, and error states are where design maturity shows. They are also where most audits find their easiest wins, because nobody ever looked.

• Does every list and dashboard have a designed empty state that tells the user how to get their first item?
• Do loading states hold layout in place, or does content jump when it arrives?
• Is there a designed error state for the network failing, or does the user get a spinner forever?
• What happens on a double click of a submit button? Duplicate charges are a real audit finding.
• Are destructive actions guarded by confirmation or undo, and is undo preferred where possible?
• Does the product behave sanely when data is long, weird, or missing? Test a 40 character name.
• If a session expires mid flow, does the user lose their work, or does the product recover it after login?

Consistency and UI debt

Inconsistency taxes users on every screen, because nothing learned on one screen transfers to the next. It also reads as sloppiness, and users assume sloppy UI means sloppy data handling.

• Count the visually distinct button styles across the flow. More than three is a finding.
• Are the same actions named the same way everywhere, or is it Save here, Done there, Apply somewhere else?
• Do colors mean something consistent, or is the danger red also the brand red?
• Is spacing rhythmical, or does every screen invent its own margins?
• Do interactive and non-interactive elements look reliably different?
• Do icons carry one consistent meaning, or does the same icon do different things on different screens?

Accessibility quick pass

This is not a full accessibility audit, it is the pass that catches the failures affecting the most users, including users nobody thinks of as disabled, anyone on a cheap screen in sunlight.

• Does body text pass 4.5 to 1 contrast against its background? Check the gray on gray text designers love.
• Can you complete the whole flow with only a keyboard?
• Is focus visible at every step of that keyboard journey?
• Do images and icon only buttons have accessible names?
• Are touch targets at least 44 pixels, especially in dense mobile UI?
• Does anything rely on color alone to communicate state?
• Does the flow stay usable with the page zoomed to 200 percent? Plenty of paying customers browse zoomed in.

Scoring severity so priorities are obvious

A list of 40 findings without priorities is homework, not help. I score every finding on two axes, how many users hit it and how badly it hurts them, then bucket the result into four levels.

• Blocker. Users cannot complete the flow. Fix this week.
• Major. Users complete the flow but a meaningful share gives up or errors. Fix this sprint.
• Minor. Friction users push through. Schedule it.
• Polish. Worth fixing when touching that screen anyway.

Presenting findings so they actually get fixed

The audit succeeds or fails at the handoff. Engineers do not act on essays. For every finding I write three things into a ready-to-copy findings sheet: a screenshot with the problem marked, the severity with a one line justification, and the concrete fix described in one or two sentences. If you want to see what that looks like written out, here is a full audit report walked through end to end, findings, severity scores, backlog and all.

Then I go one step further and rewrite the top findings as ready-to-build tickets. That single habit is the difference between an audit that changes the product and a PDF that ages in a drive folder. If the findings pile up across nearly every section instead of clustering on one flow, that's often the signal that a redesign beats another fix list.

This checklist asks whether a person can finish the task. It does not ask whether the funnel around that task is losing money, which is a separate pass with its own numbers. If that is the question you actually have, the conversion side has its own checklist.

If you are a designer, steal this checklist, it is yours. If you are a founder or a team without a designer, I run this exact process as a fixed price UX audit service and hand you the report, the backlog, and a walkthrough call.