Most teams ask for a UX audit at one of two moments. Either the numbers have dropped and nobody can say why, or a redesign is on the table and someone sensibly asks, “Before we rebuild everything, what is actually broken?”
A good UX audit answers that question with evidence. It tells you where people struggle, how much it costs the business, and which fixes will make the biggest difference for the least effort. In this guide I share the process I use with product teams: what to review, how to run the audit in five steps, how to score what you find, and how to turn the report into work that actually ships.
What is a UX audit?
A UX audit is a structured review of a digital product that finds usability problems and explains their impact. It combines expert review against known principles with real evidence: analytics, recordings, support tickets and, where possible, a few sessions with real users.
It is not a redesign and it is not a list of opinions. The output is a ranked set of problems, each with evidence, severity and a recommended fix. Think of it as a health check that tells you where to operate, rather than the operation itself.
When you need a UX audit
- Before a redesign. An audit shows which parts of the product work and should be kept. Many redesigns throw away things users liked and keep the problems.
- When a key metric drops. Sign-ups, activation, checkout completion or retention falling without an obvious cause.
- When support tickets keep repeating. The same “how do I” questions every week usually point to an interface problem, not a user problem.
- After rapid growth. Features added quickly by different teams leave inconsistent patterns and confusing navigation.
- Before adding AI features. AI on top of a confusing workflow makes the confusion faster. Audit the flow first.
What a UX audit covers
I review six areas. Not every audit needs all six in equal depth, but skipping one entirely usually leaves a blind spot.
- Goals and journeys. The three to five tasks that matter most to users and the business, and how easily people complete them.
- Information architecture. Navigation, labels, search and whether people can predict where things live.
- Interaction and feedback. Forms, errors, loading states, empty states and whether the system tells people what is happening.
- Content and clarity. Microcopy, headings, instructions and terms only your team understands.
- Visual consistency. Components, spacing, hierarchy and how closely the product follows its own design system.
- Accessibility. Contrast, keyboard use, screen reader support and focus order, measured against WCAG.
The UX audit process in five steps
Figure 1 ยท The five-step UX audit process
01 Scope
Goals, key journeys, success metrics.
02 Evidence
Analytics, recordings, tickets, interviews.
03 Review
Walk each journey against heuristics.
04 Score
Severity, reach and effort for each issue.
05 Roadmap
Quick wins, fixes, bigger bets.
1. Scope the audit
Start with the business question, not the screens. “Why do trial users not activate?” leads to a focused audit. “Review the whole app” leads to a 200-item spreadsheet nobody reads. Agree on the key journeys, the users involved and the metrics that define success.
2. Gather evidence
Before forming opinions, collect what already exists. Funnel data shows where people drop off. Session recordings show how they struggle. Support tickets and sales notes show what they complain about. Even five short user interviews will change what you look for, because, as Nielsen Norman Group’s research has shown, a handful of users reveals most of the common problems.
3. Review each journey
Walk through every key journey as a new user would, then as a returning one. Check each step against established heuristics such as Jakob Nielsen’s 10 usability heuristics: visibility of system status, match with the real world, error prevention, recognition rather than recall and the rest. Capture every issue with a screenshot, the step where it happens and the evidence behind it.
4. Score the findings
A list of 80 issues is not useful until it is ranked. I score each issue on three things:
- Severity (1 to 4): from cosmetic to blocking the task completely.
- Reach (1 to 4): how many users meet it, and how often.
- Effort (1 to 4): how hard it is to fix, estimated with the developers.
Severity times reach, divided by effort, gives a simple priority score. It is not science, but it turns a debate about opinions into a conversation about trade-offs.
5. Build the roadmap
Group the scored issues into three buckets. Quick wins are high impact and low effort, and should ship within weeks. Planned fixes need design and development time and go into the next quarter. Bigger bets point to deeper problems in structure or strategy, and are where a partial redesign may genuinely be needed.
A simple UX audit checklist
Use these questions as a starting point for each key journey:
- Can a first-time user tell what the product does and what to do first within a few seconds?
- Does the navigation use words your users use, not your internal team names?
- Does every action give clear feedback, including loading, success and error states?
- Do error messages explain what went wrong and how to fix it?
- Are forms as short as possible, with smart defaults and inline validation?
- Are the same components and patterns used for the same jobs across the product?
- Can the key journey be completed with a keyboard alone, with sufficient contrast?
- Does the product work properly on the devices your analytics say people use most?
Common mistakes that weaken a UX audit
Auditing screens instead of journeys. A screen can look fine in isolation and still fail as a step in a task. Always review in the order users actually move.
Reporting opinions without evidence. “The button should be bigger” is easy to dismiss. “38% of users tap the wrong button on this step, see recordings 4, 7 and 12” is not.
Delivering a document and walking away. The audit only creates value when fixes ship. Present the findings with the team, agree on owners, and check the metrics again after the quick wins are live.
What to do after the audit
The most common question after an audit is whether to fix or redesign. In most products I review, 70 to 80 percent of the problems can be fixed inside the existing structure. A full redesign is only worth it when the problems sit in the foundations: the core model of the product, the navigation structure or a technology that blocks change.
If your product includes AI features, add one extra lens to the audit: how much the AI does on its own and how people can check and correct it. I wrote about that in the AI autonomy dial and in what AI-native design really means.
Coming next in this UX audit series: running a UX audit before a redesign, usability audits for web apps, fixing user journey friction, and the most common website usability problems I find.
If you want an outside view on your product, I run focused UX audits for SaaS and web app teams. Get in touch through chandrajith.in and tell me which journey matters most.
Frequently asked questions
What is a UX audit?
A UX audit is a structured review of a digital product that finds usability problems, backs each one with evidence and ranks them by impact, so a team knows what to fix first.
How long does a UX audit take?
A focused audit of three to five key journeys usually takes two to four weeks, including evidence gathering, review, scoring and a roadmap workshop with the team.
What is the difference between a UX audit and usability testing?
Usability testing watches real users try tasks. A UX audit is broader: it combines expert review, analytics and other evidence, and often includes a small amount of usability testing as one input.
Should I do a UX audit before a redesign?
Yes. An audit shows which parts of the product work and should be kept, and which problems are structural. Many teams find most issues can be fixed without a full redesign.
