A UX audit is a structured review of a product against known usability principles, run flow by flow rather than screen by screen. It ends in a written report: a list of findings, each scored by severity, each paired with a concrete fix, rolled up into a prioritized backlog a team can actually build from.
A quick audit covering one or two flows takes a few days and a few thousand dollars. A comprehensive audit of a full product, with research and accessibility testing built in, takes weeks and costs more. What makes it a UX audit rather than a design opinion is the method: every screen and every state gets checked against the same fixed list, and every finding gets scored the same way.
That is the whole thing in one paragraph. Everything below covers how to run one properly, what it should never replace, and what happens after the report lands and nobody reads it.
What a UX audit is, and what you get from one
A UX audit is not a redesign. It does not hand you new screens. It hands you a ranked list of what is broken in the screens you already have, and why. Sometimes that ranked list confirms the product needs more than a fix list, and nine signs your product needs a redesign is worth checking against before you commit to one.
It is also not one person's opinion, even when one person does all the work. Every finding gets tied to a named usability principle, evidence in the form of a screenshot or a recording, and a severity score. That is what separates an audit from a design critique: the method stays the same no matter who runs it, and the reasoning is written down so someone else can check it.
What you get at the end is a document with six parts: a scope statement, the method used, the findings, severity scores, recommended fixes, and a prioritized backlog. We walk through what all six actually look like further down this page.
The next question is who does this work, and how long it takes.
How long it takes, and who should run it
A focused audit of one core flow takes about a week. A few days of review, plus a day to write findings and prepare a walkthrough. A full product audit, covering every flow with research and accessibility testing, takes several weeks.
Who runs it varies more than people expect. It can be one senior designer or researcher working alone, an in house designer running the process on their own product, or a small team split across usability and accessibility.
What matters is not team size. It is whether the person doing the review can see the product with fresh eyes. That is the actual reason companies hire outside help even with designers already on staff. Not because in house designers lack skill, but because nobody spots friction in a flow they built themselves.
None of that matters if you are buying an audit for the wrong reason in the first place. So let us rule that out first.
When a UX audit is the wrong tool
An audit is not always the right purchase. Three situations make it the wrong one, and it is worth saying so before anyone spends the budget.
A brand new product with no real usage yet. An audit scores problems by how many people hit them and how badly. With no traffic, there is no reach number to score against. What you need at that stage is usability testing: watch five or six people try the product and see where they actually get stuck. That is behavior, not a heuristic guess about behavior, and it is the right tool before launch.
A team with no capacity to build the fixes. An audit produces a backlog. If nobody can touch that backlog for the next two quarters, you are paying for a document that sits in a drive. Fix the capacity problem first, then buy the audit once someone can act on what it finds.
A product that has not found fit yet. If the real issue is that people will not pay for what the product does, no amount of usability polish changes that. A finding like "the checkout button needs higher contrast" does not matter if nobody wants the product underneath it. That is a strategy problem, not a UX problem, and an audit is not built to catch it.
If none of these describe you, an audit is a reasonable next step. If one does, the honest move is to fix that first and audit later.
The five things people confuse a UX audit with
People use "UX audit" as a catch all for five different things, and mixing them up wastes money on the wrong deliverable. Here is how they actually differ.
| Method | What it answers | Who does it | What it costs you | When to use it instead | |---|---|---|---|---| | UX audit | Where is this product losing people, and in what order should we fix it | A senior UX consultant, researcher, or small internal team | A few thousand dollars for one flow, more for a full product (real 2026 price bands) | Default choice when you need evidence and a ranked backlog, not just an opinion | | Heuristic evaluation | Does this screen break a known usability principle | One expert reviewer, often solo | Hours, not weeks. Cheap or free if done in house | A fast check on a handful of screens, when you do not need a full report or backlog | | Usability testing | Can a real person actually complete this task, and where do they get stuck | A researcher moderating sessions with recruited users | Recruiting, incentives, and moderator time | Before launch, or whenever you genuinely do not know why people are struggling | | Design review | Does this design match our intent and style before it ships | The design team, informally, on work still in progress | Free, but it is opinion, not evidence | A pre launch quality check, not a systematic pass on a live product | | Accessibility audit | Does this meet a documented WCAG conformance level | An accessibility specialist, often testing with assistive tech | Its own budget, separate from a general UX audit | A legal or compliance deadline that needs conformance on record | | CRO audit | Why is this page not converting, and what should we test next | A conversion specialist working from analytics and test tooling | Often bundled into a testing or implementation retainer | You already have traffic and the goal is more conversions specifically |
The one people confuse most with a full audit is the heuristic evaluation, because it is the method sitting inside the audit. Walking a flow against a fixed checklist of usability checks is exactly what a heuristic evaluation is. A UX audit does that, then adds scope, evidence, severity scoring, and a backlog on top. The checklist is the input. The audit is what you build from it.
CRO gets confused with UX for a different reason: both eventually touch conversion. But a CRO audit starts from analytics and tests hypotheses against real traffic, while a UX audit starts from usability principles and does not need any traffic to find a problem. They are complementary, not the same thing, and a mature team usually runs both. If you have the traffic to test with, the conversion side of this has its own guide, including the traffic floor below which testing cannot give you an answer at all.
The process: how a UX audit actually gets run
Every real UX audit follows roughly the same shape, whether it takes three days or six weeks.
-
Define scope. Pick one flow, or a small set of them: signup, checkout, onboarding, whichever the business depends on most right now. Write down what is out of scope too, including devices, browsers, and anything you are explicitly not touching this pass.
-
Set success metrics if you have them. A drop off number, a support ticket volume, a completion rate. Numbers turn a finding from an opinion into a priority, but an audit still works without them.
-
Use the product like a real user first. Create an account and go through the flow yourself before you start taking notes as a reviewer. Seeing it cold catches things a familiar eye stops noticing.
-
Run the heuristic evaluation. Walk the scoped flow screen by screen against a fixed list of checks covering first impressions, forms, consistency, and accessibility. This 40 point checklist is the one worth running.
-
Pull in whatever other evidence exists. Session recordings, analytics, old support tickets, and a handful of live user sessions if the budget allows. This step is optional, but every extra source makes the findings harder to argue with.
-
Capture every state, not just the happy path. Empty states, loading states, error states, and whatever happens right after a form submits. Most usability problems live in states nobody designed on purpose.
-
Score every finding for severity, with evidence attached. A screenshot or a screen recording next to each one. A finding with no evidence is a guess dressed up as a fact.
-
Write the fix as a specific, buildable change. "Show password requirements before the first failed attempt" is buildable. "Improve the password field" is not.
-
Record everything in one place. A nine column table built for exactly this keeps screen, finding, severity, evidence, fix, effort, owner, and status all in one row, so nothing gets lost between the review and the backlog.
-
Prioritize into a backlog and hand it off. Rank by reach crossed with effort, not by severity alone, name an owner for each item, and present it to whoever can actually greenlight the work.
All of that work turns into one document. Here is exactly what that document should contain.
What the deliverable actually looks like
Strip away the process, and what you are paying for is a report. Here is what a real one contains, part by part.
| Part | What it contains | |---|---| | Scope | What was tested, what was not, and on which devices | | Method | How the review was done, and what evidence was used | | Findings | Each problem, where it lives, and the principle it breaks | | Severity scores | Critical, High, Medium, or Low, on every finding | | Recommended fixes | A specific, buildable change per finding | | Prioritized backlog | What ships first, ranked by reach and effort, not severity alone |
Most audit vendors describe this anatomy in the abstract, or show a cropped screenshot of a page you cannot actually read. That is the gap worth naming: almost nobody shows the finished thing.
We do. A complete UX audit example walks a real report end to end: the scope page, five findings scored and written out in full with their fixes, and the prioritized backlog those findings turn into. It is the same structure listed above, filled in, on an anonymized flow, so you can see exactly what you are paying for before you pay for it.
In that example, a signup and onboarding flow gets walked through five specific findings: a form that shifts layout as a button loads late, password rules that only appear after a failed attempt, a dead end error message for an existing account, a confusingly worded checkbox, and an error state that relies on color alone. Each one gets a severity score, a fix, and a place in the backlog.
Severity, and why scoring is the whole game
A list of findings with no priority attached is homework, not a plan. Severity is what turns one into the other.
Four levels do this better than a numbered scale:
- Critical: blocks the task entirely, or loses the user's data.
- High: the task completes, but people drop off or misread something important.
- Medium: friction, with no drop off.
- Low: polish, nothing more.
A 1 to 5 scale looks precise, but it is not. Give reviewers a middle number and half the findings land on it, because a 3 is where people park anything they are unsure about. Four named levels force an actual decision: does this stop someone, or does it just annoy them?
If you are unsure whether a finding is Critical or High, ask one question: can the task still be completed, by anyone, right now? If yes, it is High, not Critical.
Severity alone still does not decide what ships first. A second factor does: reach crossed with effort. A High severity finding that needs a quarter of engineering time can ship after a Medium finding that takes an hour, because the quick fix removes real friction today while the bigger one is still being scoped.
That crossing of severity, reach, and effort is what turns a findings list into an actual shipping order. It is the single habit that most separates a useful audit from a decorative one.
What it costs, and whether to run it yourself
Real pricing pages put a single flow audit at three thousand to twenty five thousand dollars for most single product companies, once the sales framing gets stripped back out. A full breakdown of real 2026 UX audit pricing normalizes six published rate cards into one table, with the variables that actually move the number: how many flows, whether live research is included, and how senior the reviewer is.
Some of that spread is genuine. A senior reviewer covering three flows with live user sessions costs more than a junior freelancer spot checking one screen. Some of it is positioning: an agency built to sell forty thousand dollar retainers rarely quotes the two thousand dollar option, even when that is all you need.
Whether to run it yourself comes down to one honest question. Can you see friction in a product you already know too well? A structured checklist plus a template built to hold the findings is genuinely enough for a competent team to run a solid first pass. Plenty of teams should start there before paying anyone.
Where DIY tends to fall short is objectivity, not process. A designer who built the checkout flow struggles to see it the way a stranger does on day one. Either way, the real test is whether the fixes found are worth more than the audit cost within a reasonable window, not whether the report looks impressive.
What happens after, and why most audits fail there
Every audit guide ends at "share the findings with stakeholders," as if that were the finish line. It is not. That is where most audits actually die.
A report becomes shelfware in a few predictable ways:
- Findings sit in a slide deck instead of a tracked table, so nobody remembers which ones got fixed six months later.
- Every finding gets assigned to "the team" instead of one named person, and a task with no owner never starts.
- The backlog never gets weighed against the actual product roadmap, so it competes with feature work and loses every quarter.
- Nobody checks whether the fix actually worked once it ships.
The fix for the first two is mechanical: put every finding into a tracked table with an owner column, not a document that only gets opened once. A row with no name in the owner column is not a task. It is a place a task goes to disappear.
The fix for the last one is a habit, not a tool. Pick a handful of top findings, note what you expect to change once they ship, and check back later. That is the difference between an audit that changes the product and one that just describes it once. The worked audit example on this site walks through a backlog written specifically so it survives that handoff, with effort estimates and owners attached to every row.
How often to run a UX audit
There is no fixed schedule that fits every product. A few signals matter more than a calendar date.
Run one after a major redesign, before you assume it worked. Run one when a metric moves in a direction nobody can explain from the data alone. Run one before a big push into a new market or channel, since flows that work for existing users can fail silently for new ones.
For a stable product with steady traffic, once or twice a year is a reasonable cadence, timed around planning cycles rather than a fixed date. For anything changing weekly, an audit goes stale fast. Put your energy into live testing instead until the product settles.
Where to start
If none of this convinces you an audit fits your situation right now, that is fine. Revisit it once traffic, capacity, or product fit catches up.
If it does fit, you do not have to take our word for the process. The checklist, the template, and a full worked report are all public on this site already, free to use whether or not you ever hire anyone.
When you are ready to have someone else run it, on your product, with a report and a backlog you could hand an engineer on Monday, that is what the UX audit service is for.