How to run a UX audit: a step-by-step checklist and the tools for each job

A UX audit, short for user experience audit, is a structured review of a product that finds where it fails the people using it and ranks what to fix first. The evidence comes from four places: the product's analytics, recordings of real sessions, an expert review against usability heuristics, and a check of the interface against its own design system. The output is a short list of fixes, each with an owner and a date. An audit without that list is theater.

My work is mostly design systems, so this guide spends more time than most on the UI half of an audit: checking what shipped against the system it was meant to follow.

UX audit or UI audit

People use the two terms interchangeably, and they check different things.

A UX audit asks whether people can do what they came to do. Can a new user finish onboarding? Where do buyers give up at checkout? It works from behavior, so it needs real usage data.

A UI audit asks whether the interface was built the way it was designed. Is every button the same button, with the same states? Do the colors, type and spacing come from the design system's tokens, or from values someone typed by hand? It works from the screens and the code, so it can run before a single user arrives.

A useful audit does both. An inconsistent interface is harder to learn, and that cost shows up in the UX numbers.

A usability test is a third thing. It watches a handful of people attempt specific tasks. An audit often ends by recommending one.

When to run a UX audit

• Before a redesign, so the redesign fixes measured problems and not matters of taste.
• When a key metric drops and nobody can say why.
• Before a design system rolls out to more teams, while the drift is still small.
• After a migration or a replatform, when things that used to work stop working without anyone noticing.
• On a schedule. A quarterly audit suits most products. A weekly micro-audit of the highest-traffic flows suits some. Match the cadence to how fast the product changes.

How to run a UX audit, step by step

1. Pick one objective and fence the scope

Decide what the audit is for before opening a tool. Conversion on the signup flow. Task success in the dashboard. Consistency across the settings screens. A vague objective produces a vague audit, and auditing conversion, satisfaction and brand coherence in one pass produces three shallow ones.

Write the scope down: which flows, which platforms, which users, and what finished looks like.

2. Start with the numbers

Pull the funnel for the flows in scope and find where people drop out. Numbers diagnose. They don't prescribe. A 40% drop at step three of onboarding says something is wrong at step three and says nothing about what. The number is the question, and the rest of the audit looks for the answer.

Skip the vanity metrics. A chart that goes up and to the right without telling you why produces confidence without insight.

3. Watch real sessions

Take the steps with the worst drop-off and watch recordings of real people going through them. This is where the intended flow and the actual flow come apart. People hover over a button for three seconds before clicking, which means the label is unclear. They rage-click something that looks interactive and isn't. They scroll past the call to action to read the section below it, which means that section interests them more.

Watching real users go through what your team built is one of the more humbling exercises in product work. Most teams come out of the first session with a backlog of small, high-impact fixes.

4. Run a heuristic evaluation

In a heuristic evaluation, a reviewer walks the product against a fixed set of usability principles. The standard set is Jakob Nielsen's ten usability heuristics:

1. Visibility of system status
2. Match between the system and the real world
3. User control and freedom
4. Consistency and standards
5. Error prevention
6. Recognition rather than recall
7. Flexibility and efficiency of use
8. Aesthetic and minimalist design
9. Help users recognize, diagnose, and recover from errors
10. Help and documentation

Walk each flow in scope. For every problem, note the screen, the heuristic it breaks and how severe it is, with a screenshot. Have two or three people do this separately and merge the lists, because one reviewer misses a lot.

5. Check accessibility

Test against WCAG 2.2 at level AA. Automated checkers catch the mechanical failures, like missing labels and low contrast, but not all of them, so finish with a keyboard-only pass and a screen reader on the main flows.

Then put the automated check in CI. Catching a contrast failure in code review costs a minute. Catching it after launch costs months.

Accessibility work makes the product better for everyone. Larger touch targets help thumbs. Higher contrast helps in sunlight. Keyboard navigation helps power users. Captions help the meeting room with the muted laptop.

6. Audit the UI against the design system

This is the UI half of the audit. Compare what shipped with what the system says should ship:

• Colors, type, spacing and corner radii come from tokens, not from hand-typed values.
• Each control is one component, with one set of states: hover, focus, active, disabled, loading and error.
• The same action looks and behaves the same everywhere it appears.
• Components render correctly in every theme and at every screen width the product supports.

Measure this instead of eyeballing it. The drift a UI audit looks for is the kind that hides in a screenshot, so check computed styles in the browser, element sizes and the code itself. The section on what a screenshot hides, further down, has three examples.

7. Ask the people who hear the complaints

Support tickets, sales calls and cancellation emails cluster around specific screens. Read them for the screens more than the feature requests. A user who asks for feature X often means the current way is annoying in a way they can't name. Map the request back to that friction and fix the friction.

The most useful feedback arrives unprompted. A customer who writes in to explain why they left tells you more than ten survey responses. Build the channel that captures those messages before you tune the surveys.

8. Rank the findings and write the action plan

Most audits surface 30 or more issues. Score each one by its impact on users, how many users it reaches and the effort to fix it, then ship the top five first. Clearing the easy ones first feels productive. Order the work by user value instead.

Every finding in the plan gets:

• the evidence: a recording, a metric or a screenshot
• the heuristic or design-system rule it breaks
• a proposed fix
• an owner
• a ship date

Findings without owners drift. Findings without ship dates drift faster.

9. Re-audit

Check that the fixes moved the number you started with, then put the next audit on the calendar.

UX audit checklist

Copy it and cut what doesn't apply to your product.

Navigation and structure

• Users can tell where they are and how they got there.
• The main action on each screen is visible on a phone without scrolling.
• Labels use the users' words, not internal names.
• Search returns useful results for the terms people type.

Forms and input

• Every field has a visible label, not only a placeholder.
• Errors appear beside the field, say what went wrong, and keep what the user typed.
• Required fields are marked, and optional fields are rare.
• Phones show the right keyboard for each field.

Feedback and errors

• Every action gets a visible response.
• Loading, empty and error states exist, and each says what to do next.
• Destructive actions ask for confirmation or can be undone.

Content

• Headings describe the section below them.
• Buttons say what they do, such as "Save changes", instead of "Submit".
• Prices, limits and next steps are stated before the user commits.

Visual design and UI consistency

• Each control is one component with consistent states.
• Colors, type and spacing come from design tokens.
• Text contrast meets WCAG AA.
• Content doesn't jump around while the page loads.

Accessibility

• Everything works with a keyboard alone, with a visible focus indicator.
• Images have alt text, and decorative images have empty alt text.
• The page uses real headings, landmarks and buttons.
• The main flows work with a screen reader.

Performance

• The main content appears within 2.5 seconds on a mid-range phone, Google's threshold for a good Largest Contentful Paint.
• Taps and clicks respond within 200 milliseconds.

Trust

• Contact details, policies and security information are easy to find.
• The product explains why it asks for any personal data.

UX audit tools, by job

Each tool covers one part of an audit. You need a few of them together.

Analytics. Google Analytics 4, Mixpanel, Amplitude and PostHog show funnels, drop-off and the paths people take. Set up events for the flows in scope before the audit starts.

Heatmaps and session recordings. Hotjar, Microsoft Clarity and FullStory show where people click, scroll and hesitate, and replay real sessions. Clarity is free. PostHog records sessions alongside its analytics.

Usability testing. Maze runs unmoderated tests on prototypes and live products. UserTesting recruits participants and records their sessions.

Surveys and feedback. Hotjar's surveys and feedback widgets cover most needs, or a Typeform linked from inside the product. Your support inbox belongs here too, and it costs nothing.

Accessibility. axe DevTools and WAVE in the browser, Lighthouse for a quick score, and Stark to check contrast in Figma before anything is built. Run axe-core in CI so a failure blocks the merge.

Performance. PageSpeed Insights shows real-user data once a site has enough traffic. Lighthouse and Chrome DevTools run lab tests on a throttled connection for everything else.

UI audit tools. Storybook puts every component and state on one screen. Chromatic runs visual regression tests on those stories. Lint rules can reject raw hex colors and hand-typed pixel values in the code. And Zengin, which I build, is an open-source design system with a deterministic engine that checks each edit against the system's tokens and components and hands back the fix. It runs from the terminal, in CI, and as a hook after a coding agent writes a file. On three public React codebases it flagged 424 violations, every one of them read and classified by hand.

Search. Google Search Console shows the queries that bring people in and the pages that fail to earn the click. A page that appears thousands of times in search and rarely gets clicked has a UX problem before anyone lands on it. This post was one of them. I rewrote it in September 2026 after Search Console showed it appearing more than 3,000 times in three months for these searches and getting clicked seven times.

What a screenshot hides

In September 2026 I audited the interface of this site. Three of the findings looked fine in a screenshot:

• The four buttons at the bottom of the navigation had four different hover behaviors. One inverted its colors completely while the other three barely changed, which read very differently in light and dark mode. At rest, they looked like a matching set.
• The tags on one project card rendered as circles, 65 pixels wide and 61 tall, because a flex row stretched them to its own height. On every other card they looked right.
• Every page downloaded two copies of its main typefaces, up to 2.1 MB of fonts, and looked identical either way.

Each one turned up only when I measured instead of looked: computed styles for the buttons, element sizes for the tags, network requests for the fonts.

What the audit report should contain

Keep it short enough to read in one sitting.

1. One page with the objective, the scope, and the five findings that matter most.
2. The ranked list of findings, each with its evidence, severity, proposed fix, owner and date.
3. An appendix with the raw material: heuristic notes, recordings, accessibility results and data exports.

Leave out the owners and dates, and you have spent two weeks producing a deck nobody implements.

How long a UX audit takes

It depends on the scope and on the state of the data. One flow with analytics already in place is a few days of work. A whole product with no event tracking takes weeks, and much of that time goes into setting up the tracking before there is anything to read.

Auditing AI features

The same audit works on AI features, with different instruments. AI features tend to ship after the team tests the prompt against examples it wrote itself, and then users hit the cases nobody anticipated.

• An eval set built from real production inputs, scored on every change, takes the place of the funnel. Without one, there is no way to tell whether a model upgrade helped or made things worse.
• A readable trace of every model call, with its inputs, tool calls, intermediate steps and output, takes the place of the session recording. The first time you read production traces, you usually find a class of failure the team didn't know existed.
• Refusal and hallucination rates take the place of accessibility violations. Set a budget for each and fix the worst cases before they ship.
• The ranking rule still holds. An audit of an AI feature surfaces dozens of failure modes, and the top five get fixed first.