UX Audit: What It Is, How to Run One and What You Get

A UX audit is an expert review of a website or product against usability principles, real user data and your business goals. What you get at the end is a prioritized list of problems and fixes, not a redesign.

Below is how I run one on SaaS products and marketing sites: the method step by step, the checklist I use, what the report contains, where AI speeds things up without replacing judgment, and what drives the cost.

What is a UX audit?

A UX audit, sometimes called a UX review or usability audit, is a structured evaluation of an interface to find where users struggle and why. A designer walks through the key journeys, checks them against established principles, crosses what they see with analytics and support data, and rates each problem by severity.

It is not a usability test (no users are recruited by default), not a redesign (it tells you what to fix, not what the new screens look like) and not an automated score. Tools can flag contrast errors or slow pages; they cannot tell you that your pricing page answers the wrong question.

UX audit vs heuristic evaluation, usability testing and accessibility audit

These terms overlap, and agencies use them loosely. Here is how I separate them:

A UX audit uses a heuristic evaluation as one of its steps. It often recommends usability tests for the questions it cannot answer alone, and those tests do not need to be large: Nielsen Norman Group recommends small rounds with no more than five users.

When a UX audit is worth it

An audit pays off when you know something is wrong but not exactly what, or when you are about to spend serious money on changes. The situations I see most often:

• Before a redesign. Auditing first tells you what to keep, what to fix and what actually needs a new design. If the redesign includes a new site, pair it with a website redesign SEO plan.
• When activation or conversion drops. Sign-ups stay flat but fewer users reach the first result, or trials stop converting. Onboarding is often the cause, and SaaS onboarding patterns are one of the first things I check.
• After fast feature growth. The product grew feature by feature, each one designed in isolation, and the whole no longer feels coherent.
• When the UI has drifted. Five button styles, three date pickers, inconsistent spacing. That is usually a sign the product needs a design system, and the audit tells you where to start.
• Before an important sale or raise. Enterprise buyers and investors click through the product. An audit catches what would embarrass you in a demo.

How to do a UX audit, step by step

This is the method I follow. The depth of each step changes with the scope, the steps do not.

1. Agree on goals, scope and key journeys

Start with the business question: "Why do trials not convert?" is a better brief than "Audit the app". Then choose the three to five journeys that matter most for that question, for example sign-up to first result, creating a report, inviting a teammate, upgrading. An audit that tries to cover every screen ends up shallow everywhere.

2. Read the data before the screens

Before forming opinions, I look at what users already tell you: funnel and drop-off data, session recordings at the steps where people leave, support tickets, sales call notes, reviews and churn reasons. This step decides where to look closely and stops the audit from becoming a list of personal taste.

3. Walk each journey screen by screen

Then I walk each journey as a user would, on desktop and mobile, with realistic data. Two lenses help:

• Heuristics. Nielsen's 10 usability heuristics, published in 1994 and still unchanged, are broad rules of thumb: show system status, speak the user's language, prevent errors, help users recover from them, and so on.
• Cognitive walkthrough. For each step of a task, I ask whether a new user would know what to do, see how to do it and understand the result. It is the best way to catch learnability problems without recruiting anyone.

Each problem is captured with a screenshot, the exact location and the evidence behind it.

4. Check accessibility and performance basics

A UX audit is not a full accessibility audit, but it covers the basics: text contrast of at least 4.5:1 for normal text, keyboard navigation, visible focus, form labels, touch targets of at least 24 by 24 CSS pixels, both from WCAG 2.2. On marketing sites I also check Core Web Vitals, since slow pages are a UX problem before they are an SEO one: Google's thresholds for a good experience are a Largest Contentful Paint under 2.5 seconds, an Interaction to Next Paint of 200 milliseconds or less and a Cumulative Layout Shift of 0.1 or less.

5. Review consistency and the design system

I list the components and patterns in use: buttons, inputs, tables, modals, empty states, error messages. Inconsistencies are not only cosmetic. When the same action looks different on two screens, users hesitate, and every new feature costs more to design and build.

6. Rate severity and prioritize

Every finding gets a severity rating. I use the Nielsen Norman Group scale, from 0 (not a usability problem) to 4 (a usability catastrophe to fix before release), based on how frequent the problem is, how hard it is to overcome and whether it keeps bothering users. Then I cross severity with effort, which gives three groups: quick fixes to ship now, larger changes to plan, and minor issues to watch.

7. Present the findings and turn them into work

The audit ends with a working session, not an email with a PDF. We go through the top findings together, agree on what to fix first, and I turn the main ones into tickets or design briefs your team can act on.

UX audit checklist for websites and SaaS products

This is a condensed version of the checklist I use. Not every item applies to every product; the ones marked for SaaS matter most inside the app.

Clarity and first impression

• The page or screen says what it is for within a few seconds
• One primary action per screen, visually dominant
• Headings and labels use the customer's words, not internal jargon

Navigation and information architecture

• Users can tell where they are and how to go back
• Menu labels match what users look for, not your org chart
• Search, if any, handles typos and shows useful empty results

Onboarding and empty states (SaaS)

• New accounts land on a screen that leads to a first result
• Every empty state explains what will appear and offers one action
• Setup can be skipped, saved and resumed

Forms, inputs and errors

• Only necessary fields, with labels that stay visible
• Errors appear next to the field, say what went wrong and how to fix it
• Input is preserved after an error

Feedback and system status

• Every action gets a visible response: loading, success or failure
• Long operations show progress and can run in the background
• Destructive actions ask for confirmation or can be undone

Accessibility

• Text contrast meets WCAG 2.2 AA (4.5:1 for normal text)
• Every action works with a keyboard, with a visible focus
• Images and icons that carry meaning have text alternatives

Mobile and responsive

• Key journeys can be completed on a phone
• Touch targets are large enough and not crowded
• Tables and dashboards have a real mobile pattern, not a squeezed desktop

Performance

• Core Web Vitals pass on key pages, measured on mobile
• Interface responds quickly to clicks and typing
• Large data views load progressively

Content and microcopy

• Button labels describe the result ("Create invoice", not "Submit")
• Pricing, limits and plans are explained before the user hits them
• Help is reachable where questions arise

Visual consistency and trust

• Components, spacing and type follow one system
• Proof (logos, case studies, security information) sits where buyers hesitate
• Nothing looks broken, unfinished or out of date

What a UX audit report includes

A useful report is short enough to be read and specific enough to be acted on. Mine contains:

1. A one-page summary with the main problems and the order in which to fix them
2. The journeys reviewed and the data used, so everyone knows the scope
3. The findings, one per row, with evidence and severity
4. Recommendations, with annotated screens or quick wireframes for the important ones
5. A prioritized plan: quick fixes, larger changes, things to test with users

Each finding follows the same format. Here are two examples of the format, written for illustration:

What a report should not do: promise a conversion increase. An audit tells you what is likely hurting users; the effect of each fix is measured after it ships.

Where AI helps in a UX audit, and where it does not

I use AI in every audit now, and it saves real time. It does not replace the judgment the audit is paid for.

Where it helps:

• Reading and grouping hundreds of support tickets, reviews or interview notes into themes
• Summarizing session recordings or call transcripts so I know which ones to watch in full
• First-pass checks: contrast, missing labels, inconsistent copy across screens
• Generating hypotheses to test ("users may not understand this label because...")
• Drafting the write-up of each finding from my notes and screenshots

Where it does not:

• Choosing which journeys matter for your business this quarter
• Rating severity in context: a confusing settings screen is minor for one product and critical for another
• Seeing what users actually do. Nielsen Norman Group is clear that heuristic evaluations cannot replace user research, and an AI reviewing screenshots is a heuristic review, not a user
• Recommending fixes that fit your design system, your constraints and your roadmap

NN/g also recommends several independent evaluators, ideally three to five, because any single expert misses problems. An AI review can be a useful extra pair of eyes. Automated "AI UX audit" tools that score a site in minutes are fine for a quick check, but their findings tend to be generic, and the hard part is still deciding what to do about them.

Can you do a UX audit yourself?

Yes, and a self-audit is better than none. Use the checklist above, pick your three most important journeys, and walk them as a new user would, on a phone as well as a laptop. Ask someone outside the product team to try the same tasks while you watch.

The limits are familiarity and bias. Your team knows how the product is supposed to work, so it stops seeing the gaps, and it tends to defend past decisions. An outside designer brings a fresh view and the experience of many other products, which is mostly what you pay for.

How much does a UX audit cost?

The price of a UX audit depends on its scope more than on the size of your company. The main factors:

• Number of journeys and platforms: a website, a web app, a mobile app
• Depth: heuristic review only, or with data analysis, recordings and user tests
• Access to data: analytics, recordings and support tickets make the audit sharper, and take time to review
• Accessibility depth: basic checks, or a full WCAG review
• The deliverable: a report and a working session, or redesigned flows for the main problems
• Seniority: who does the work, and whether they can also design the fixes

I scope audits as a fixed-price product design sprint, agreed after a short call: see my price ranges for product design work. Some teams choose a lighter audit followed by a design sprint on the top problems, which is often the better use of the budget.

After the audit: from findings to fixes

An audit is only worth what ships after it. The quick fixes can go to your engineers the same week. The larger problems need design: new flows, better empty states, a consistent set of components. That is where an audit naturally becomes a design project, and where having the same person who found the problems design the solutions saves a round of explanations.

If you want an outside, senior view of your product or website, see how I run audits and design sprints as a freelance product designer, or tell me about your product and the journeys that worry you most.