How to Conduct a UX Audit: A Step-by-Step Guide

To conduct a UX audit, agree what the audit is for and which journeys it covers, then collect evidence before forming opinions: analytics for where people drop off, and feedback, recordings and support tickets for why. Next run an expert review against usability heuristics and walk every key task end to end, including error paths. Test the most important tasks with real users if you can. Log each issue in the same format, rate its severity, prioritize by impact and effort, and deliver a short report with specific recommendations. Retest once fixes ship.

This is the execution guide: the order of work, what to produce at each step and how to turn findings into decisions. If you're still deciding whether you need an audit or what one typically includes, start with UX audit: what it is, what it includes and how it works, which also contains a website UX audit checklist.

The workflow below works for websites, online stores, SaaS products and mobile apps. Scale it up or down: a focused audit of one checkout flow uses the same steps as a full product audit, with less ground to cover.

Each step produces something the next step depends on. Skipping ahead usually means reworking findings later.

An audit without a goal turns into a list of everything that could be better. Start by interviewing the people who own the product and its numbers: product, marketing, sales, support and engineering. Ask what's not working, which metrics matter, what has already been tried, and what is off limits, such as a platform that can't change this year.

Write the answers into a short audit brief: the business question (for example, “why do trial users rarely invite teammates?”), the journeys in scope, the devices and audiences, the evidence available, the deliverables and the date for the readout. Being explicit about what's out of scope protects the time you have for what's in it.

Audit the product the way its users experience it, not the way the org chart divides it. List the main user groups and the handful of tasks that matter most to them and to the business. For an online store that might be finding a product, choosing a variant, checking delivery and paying. For a SaaS product it might be signing up, completing setup, inviting a colleague and producing the first report.

Use existing research if you have it, including personas, interview notes and user research, but keep it light. The output you need is a ranked task list with the entry points, devices and context for each task. Every later step refers back to it.

Quantitative data tells you where to look. Check the tracking first: missing events, duplicated page views and unfiltered internal traffic are common, and conclusions built on broken data waste the whole audit.

Qualitative sources explain the numbers. Read a sample of support tickets and chat transcripts, product reviews, survey comments, sales call notes and app store reviews. Tag each piece of feedback with the task and the kind of problem, then count the tags. Recurring “how do I…” questions often point to findability or labelling problems; recurring “I didn't know…” complaints often point to missing information at the moment of decision.

If you use session recordings or heatmaps, watch recordings filtered to the drop-off points you found in step 3 rather than browsing at random. The heatmap analysis guide covers how to read this data without over-interpreting it.

Start with a heuristic evaluation: review each key task against an established set of usability principles, usually Nielsen's 10 heuristics, and note every violation. Several evaluators working independently find more problems than one, so combine their findings afterwards.

Then make a second pass area by area. Heuristics are broad; this pass makes sure specific parts of the experience get looked at deliberately.

Walk every key task yourself on the devices your users use, with realistic data. Create an account, use a long name, enter an address in another country, apply an expired discount code, let the session time out, pay with a card that will be declined in test mode. Most serious problems hide in these alternative and error paths, and they rarely show up in a design review of the ideal screens.

Record each walkthrough. Screenshots or short clips become evidence in the issue log and save arguments later.

Expert review predicts problems; watching users confirms them and shows how serious they are. Where budget allows, run a small round of usability testing on the two or three most important tasks, especially where the evidence is disputed or the fix would be expensive.

Keep the test focused on the audit's goal. Write tasks as realistic scenarios, recruit people who match your users, and note where they hesitate, misread or fail. If testing isn't possible, say so in the report and mark which findings rest on expert judgment alone.

A consistent issue log is what makes an audit usable. Record one issue per row, even if it appears on several screens, and link the evidence rather than describing it from memory.

Rate every issue on one scale so that problems found by different methods can be compared. A widely used option is Jakob Nielsen's 0 to 4 severity scale, which combines how often a problem occurs, how badly it affects users when it does, and whether it persists once users know about it.

Rate after the review sessions, not during them, and have evaluators rate independently before agreeing a final score. Nielsen Norman Group notes that evaluators give weaker ratings while they're focused on finding problems.

Severity alone doesn't set the order of work. A major issue on a rarely used settings page can wait behind a minor issue on the checkout that every buyer sees. Weigh severity against reach, business impact, effort and how strong the evidence is, then sort findings into a few buckets.

A recommendation should say what to change, where, and how you'll know it worked. Vague advice gets agreed with and then ignored.

Most readers will read the first two pages, so put the decisions there. Walk stakeholders through the top findings live; recordings of users struggling persuade faster than any slide.

An audit is only finished when the fixes are measured. Record baseline numbers for each key task before changes ship, then compare afterwards. Retest the same tasks with users to confirm the problem is gone and nothing new was introduced. Where traffic allows, measure bigger changes with A/B testing.

Keep the issue log alive as a backlog. Re-auditing the same journeys after significant releases is much faster than the first audit because the baseline already exists.

It depends on how many journeys and platforms are in scope, how usable the analytics are, whether new user testing is included and how many evaluators take part. A focused audit of one flow on one platform is much smaller than a full product audit across web and apps with testing. Agree the scope in step 1 and the timeline follows from it.

A good UX audit follows a clear order: goals, users and tasks, evidence, expert review, testing, a consistent issue log, severity, priorities and specific recommendations. The value is in the ranking and the follow-through, not the length of the report. For the wider design workflow the audit feeds into, see the UX design process.