A UX audit is a structured review of a website or app that finds where it makes things hard for people and ranks those problems by how much they cost. It combines an expert review against usability rules with evidence: analytics, support tickets and, where you can, a few sessions with real users. The output is a short list of fixes in priority order, not a redesign.
It is broader than a heuristic evaluation, which is usually one step inside it, and most auditors use Nielsen's 10 usability heuristics as the rules. This guide covers the seven steps, a checklist, a worked example on one screen, how long an audit takes, and where the method stops being useful. Each check links to the laws of UX that explain why it matters. Auditing an AI feature adds its own checks, covered in AI product design.
People use these names loosely, so it helps to separate them. Each method answers a different question, and a UX audit is the one that puts the answers together.
| Method | What it tells you | What it needs |
|---|---|---|
| Heuristic evaluation | Where screens break known usability rules | Three to five reviewers and an afternoon |
| Analytics review | Where people drop off, and how many | Access to product data |
| Usability testing | Whether people can finish a task, and why not | A handful of users and a task script |
| UX audit | All of the above, ranked by impact | A clear scope and a few days to a few weeks |
The value is in the combination. The expert review says what might be wrong, the numbers show how many people it affects, and the sessions explain why. A problem that shows up in all three is almost certainly real and worth fixing first.
Use these questions on every screen in scope. They are not a replacement for the heuristics, but they turn them into things you can check by looking.
| Area | What to check |
|---|---|
| Navigation | Can a newcomer tell where they are and reach the main tasks in two or three steps? |
| Choices | Does each screen ask for one main decision, with a clear default, instead of many equal options? |
| Forms | Do fields accept the formats people actually type, group related questions, and explain errors next to the field? |
| Feedback | Does every action respond within about 400 milliseconds, and does every screen have empty, loading and error states? |
| Layout | Do related items sit together and line up, and is the most important thing the most visible? |
| Content | Are labels in the user's words rather than the company's, and does each page answer the question that brought people there? |
| Accessibility | Does body text meet the WCAG contrast ratio of 4.5 to 1, and are buttons large enough to tap without zooming? |
| Trust | Are prices, fees and next steps visible before people commit, and can they go back or undo? |
Each row has a UX law behind it, which gives you a reason to put in front of the team rather than an opinion. Navigation is Information Architecture. Choices is Hick's Law. Forms is Postel's Law. Feedback is the Doherty Threshold and Design Every State. Layout is the Law of Proximity and Visual Hierarchy. Accessibility is Accessible Contrast and Minimum Tap Target.
Here is one finding followed through the steps. The product is a made-up project tool, but the problem is one of the most common an audit turns up.
The finding from the example: the empty first screen gave new users nothing to do; the fix says what the screen is for and starts the first project in one tap.
Two laws explain the fix. Design Every State says the empty state is a screen like any other and needs designing. Time-to-Value says the sooner people get something useful, the more of them stay.
It depends on the scope more than anything else. One flow, with analytics you already have, is a few days of work for one person. A whole product, with user sessions and a written report, usually takes two to four weeks. Most of the time goes into gathering evidence and writing it up, not into looking at screens.
If time is short, cut the scope, not the evidence. A tight audit of checkout with real numbers is worth more than a quick pass over every page.
Keep the findings in one place the team already uses. If that is Notion, the UX Research Vault has an insight database with tags and severity built in.
The hard part of an audit is not the method. It is looking at a screen and naming what is wrong, and that comes from practice. In UX Quest, each UX law comes with a real screen to judge. Start with Design Every State for the empty and error states audits keep finding, then Hick's Law for crowded choices. Each law page says whether its challenge is free or part of Pro.
Three laws behind the findings an audit turns up most often. Open one to see the screen and the challenge.
A UX audit is a structured review of a website or app that finds usability problems and ranks them by impact. It combines an expert review against usability rules with evidence such as analytics, support tickets and sessions with real users.
Agree the goal and scope, collect existing data, walk each flow and capture every state, review the screens against heuristics and a checklist, check accessibility and speed, rate each issue from 0 to 4, then report the top issues and test the riskiest fixes with users.
A heuristic evaluation checks screens against a set of usability rules. A UX audit usually includes one, and adds evidence such as analytics and user sessions to show which problems actually cost the most.
One flow with data you already have takes a few days for one person. A whole product with user sessions and a written report usually takes two to four weeks.
A short summary with the top five issues, then for each issue a screenshot, its location, the rule it breaks, the evidence, a severity from 0 to 4 and a suggested fix. It should also say what was out of scope and who owns each fix.
Start where the money is lost: product pages, the cart and checkout. Check that prices, delivery costs and returns are visible early, that forms accept what people type, and that paying takes as few steps as possible on a phone.