How to Conduct a UX Audit

To conduct a UX audit, start from the product decision you need to make, not from a checklist. Scope the journeys that decision depends on, gather every kind of evidence you can — analytics, support tickets, reviews, recordings, interviews, accessibility and heuristic review — walk the experience end to end, record each problem as an observation, a hypothesis or a validated finding, rate its severity and your confidence, and turn the result into a priority order the team can actually build. Then check, after the changes ship, whether they worked. Anything less is a list of opinions with a PDF cover.

We run UX audits to give product teams a clear direction, and the name has never quite fit. A good audit is not a design critique and it is not a compliance exercise. It is the product’s SOS button: the moment someone independent looks at the whole experience, tells the team what actually matters first, and backs every priority with evidence from the people who use the product.

Turn the audit into a product your customers can use

A backlog of findings is expensive if the team still cannot decide what to build. Recolouring the dashboard or adding another onboarding tooltip keeps developers busy while customers struggle with the same broken journey. ANODA connects the diagnosis to the next design decision: the first successful task, the states that interrupt it, and the screens and components your team needs to ship the fix.

In SEOSpace, we audited the live product finding by finding, then redesigned its extension, web app and landing pages as one experience. The work included onboarding with an invalid-URL state, audit tasks ordered by priority, Figma files and Loom walkthroughs for the client’s developers, followed by design QA. That is how an audit becomes a clear path from a customer’s problem to a buildable solution.

Bring ANODA the journey your customers cannot finish. We will identify the priorities, explain the fixes and help your team move from debating symptoms to improving the product.

What a UX audit is — and what it is not

A UX audit, or user experience audit, is a structured review of a product’s experience that identifies where people struggle, explains why as far as the evidence allows, estimates what it costs and sets an order of work. It combines expert review with real user evidence, and it ends in decisions.

It is not:

• A visual opinion dump. “The colours feel dated” is not a finding unless it is connected to something users fail to do.
• A generic checklist. Checklists are useful prompts. A product that passes every line of a generic checklist can still lose most of its new users in onboarding, because no checklist knows your users or your business.
• A redesign. An audit diagnoses and prioritises. It does not deliver a new interface, though a good one will include two or three wireframes for critical flows when a fix cannot be explained in words.
• Proof of why users behave as they do. Expert review produces hypotheses. Some of them are strong enough to act on; others need research or usability testing before anyone spends a sprint on them. A serious audit says which is which.

The value of an audit is traceability. Every recommendation should lead back to evidence, forward to a user and business consequence, and on to an action and a way of checking whether the action worked. If you cannot follow that line for a finding, it is decoration.

Why products drift faster than teams can notice

Teams used to commission audits rarely, and usually late — when they felt cornered, had already redesigned everything they could think of and shipped new features that did not help. That has changed, and the reason is speed.

Now, in the AI era, teams generate kilometres of code and tens, sometimes hundreds of new screens a day. Any large product changed by more than a couple of people who are not talking to each other around the clock starts to fall out of sync. Someone understands a requirement one way and builds it that way, someone else another way, the reviewer a third way, files a bug, the requirements change, the product manager does not catch it. The technical team gaslights itself. Then SEO arrives with a new idea for tomorrow, and sales has sold a feature that does not exist.

More output does not produce shared understanding. It produces more interpretations. Each person and each AI agent makes locally sensible decisions, and the product slowly stops being one product: the same action named three ways, two settings pages, a navigation nobody planned, a new feature with no route in from the place users actually are.

It is a garden left alone for a season. Nothing in it is dead; everything is simply growing wherever it likes, and by autumn you need a machete to reach the shed. Oksana’s example is the dropdown that grows to fifty items because every new feature added one line and nobody asked how a person would find anything in it any more. That is not a design flaw you can see in a single screen review. It is drift, and it only shows up when someone walks the whole journey.

When a product needs a UX audit

There are many ways into an audit. These are the ones we see most often.

The backlog has no order. Four new features, twelve bugs, a pile of technical debt and two experiments, all marked urgent. The team keeps buying tools and adding AI assistants, and the financial results still do not move. Oksana’s diagnosis is simple: the team has no priorities, and it cannot have, because everything is being ranked by whoever shouts loudest — SEO, sales, the product manager, the founder. In a product, the priority should be dictated by the user. An audit puts the user back in that chair.

The product is about to meet a large audience. Before a Product Hunt or AppSumo launch, before paid acquisition, before a big sales push — anything that sends a crowd to a product that has so far been built quietly and approved by authority.

This is where rose-coloured glasses break inward. The product manager, the CEO, the client meet the uncomfortable truth and leave their wishful thinking for reality. At the very least, walk one onboarding happy path before launch and make sure it makes sense, does not fall apart and is understandable.

A stitch in time saves nine, and a stitch before launch saves the whole acquisition budget you were about to pour into a leaking onboarding.

The product has been growing for a while. For teams that have worked on a product for a long time, or where more than three or four people change it, Oksana recommends an independent audit roughly every three months — especially when there is no dedicated UX specialist and one overworked designer handles UX, flyers, branding, button recolours and the website at the same time. Her recommendation reflects how quickly products change: at today’s delivery speed a coherent experience can turn into a swamp within a quarter.

Metrics are flat and nobody agrees why. Activation stalls, churn creeps up, support volume grows, reviews complain about the same things. Everybody has a theory. An audit replaces theories with evidence.

Why the team cannot audit its own product

“We can do it ourselves” is the most common objection, and it is understandable. The team knows the product better than anyone. That is exactly the problem.

Oksana’s analogy is financial: a company can have excellent accountants on staff and still commission an independent financial audit. Nobody asks the person who kept the books to certify them — of course they will conclude that everything is in order. The same logic is why large technology companies with enormous in-house design teams still bring in outside UX specialists for fresh eyes.

The deeper reason is desensitisation. A designer who sees the same awkward screen every day stops noticing it. The clumsy flow starts to feel familiar, then normal, then as if it has always been there. New users have no such familiarity. They meet it cold and see immediately that it does not work. Asking the team to audit its own product is marking your own homework: you will be very fair, and you will still miss the mistakes you have been making all term.

This is not a criticism of the team. It is how attention works. The fix is an independent review — any competent agency or auditor who is not invested in the current decisions and does not have to defend them in the next stand-up.

Before you start: scope the decision, not the product

The most common audit failure is scope. “Audit the whole product” produces a hundred findings of equal weight and a team that does not know where to start. Start instead from the decision the audit should inform:

• Which three problems should we fix before launch?
• Why do trial users not convert, and what should the next quarter’s roadmap be?
• Is the new AI feature worth keeping, and what does it need to become usable?

Then choose the journeys that decision depends on: sign-up to first value, the core recurring task, upgrade and payment, the path to the feature everyone argues about. Name the user segments that matter — new versus established, roles, platforms. Agree what is out of scope and write it down. Then agree who owns the result: the audit needs a named person on the client side who can grant access, answer questions within a day and take the findings into the roadmap. Without that owner, even an excellent audit stalls at the handover, and the team goes back to ranking the backlog by volume. A full audit examines the product broadly; even then, it needs a centre of gravity.

Gather the evidence before you judge the screens

An audit is only as good as its evidence, and most companies have far more than they think. Ask for:

• Product access — every role, every plan, test accounts with realistic data, staging if production cannot be touched.
• Analytics — funnels for the scoped journeys, drop-off points, feature usage, retention and churn, broken down by segment. Include what marketing tracks, not only what product tracks; the two rarely match.
• Support evidence — ticket themes, the most common questions, chat transcripts, refund and cancellation reasons.
• Public feedback — app-store reviews, reviews on comparison sites, and what real users say on Reddit, X and Threads. Real users, not the praise the marketing department paid for.
• Existing research — interviews, surveys, usability sessions, personas, previous audits. Older research still helps, as long as you note its date.
• Access to users — even when the company believes it has none, or does not know how to reach them. There is almost always a way: recent sign-ups, churned accounts, sales prospects, support contacts.
• Business context — goals, KPIs, the roadmap, recent releases, constraints you cannot change.

How to conduct a UX audit, step by step

Here is the process we follow. The order matters: each step produces something the next one depends on.

1. Define the decision and scope. What the audit must help decide, which journeys and segments, what is out of scope, and who will act on the results.
2. Build the evidence inventory. Collect everything above and note gaps. A gap is a finding too: “nobody tracks whether invited users ever log in” is often the most important line in a report.
3. Walk the journeys end to end. Use the product as each key segment would, starting where they really start — from the ad, the invite email, the app-store page. Record every step, screen and state, including empty, loading and error states, and time how long the first meaningful result takes.
4. Run the expert review. Evaluate each journey against established usability heuristics, interface consistency, content clarity and accessibility basics — readable text, contrast, target size, keyboard access, error handling. Look for inconsistency across the product: the same action named or placed differently in different areas is a classic sign of drift.
5. Bring in user evidence. Match what you saw against analytics, tickets, reviews and recordings, and — where the stakes justify it — interviews, card sorting or a round of usability testing on the critical flows. This is where hypotheses become findings, or quietly die.
6. Record the findings. One problem per finding, with its evidence and its status: observation, hypothesis or validated finding. More on that distinction below.
7. Rate severity and confidence. How badly does this block the user and the business, and how sure are you?
8. Prioritise. Combine severity, confidence, reach and effort into an order of work, and say explicitly what can wait and what should stop being built.
9. Write the roadmap and the UX KPIs. Turn priorities into a sequence the team can deliver, with the measure each change should move.
10. Validate after release. Check whether each change moved its measure, and feed what you learn into the next review.

A note on step 4. Heuristics are a lens, not a verdict. The classic usability heuristics — visibility of system status, match with the real world, user control and freedom, consistency and standards, error prevention, recognition rather than recall, flexibility, minimalist design, helping users recover from errors, and help and documentation — are a disciplined way to look at a screen. They are not a scoring system, and a product can break none of them and still fail because it solves the wrong problem for the wrong person in the wrong order. Use them to generate observations; use user evidence to decide which of those observations matter.

Observation, hypothesis, validated finding

This distinction is what separates an audit from an opinion, and most audits skip it.

• Observation: something you saw, stated neutrally. “On the plan screen, the annual price is shown per month, and the total appears only after clicking Continue.”
• Hypothesis: an explanation you believe but have not confirmed. “Users abandon at the plan screen because they discover the real total too late.”
• Validated finding: a hypothesis supported by user evidence. “42% of sessions that reach the plan screen end there; in five of six usability sessions, participants hesitated at the total; eleven support tickets last month asked why they were charged the annual amount.”

The figures in that last example are illustrative, but the structure is the point. Expert review is excellent at producing observations and strong hypotheses quickly. It cannot, by itself, tell you why users behave as they do. Marking the status of each finding tells the team where to act immediately, where to test first and where the auditor is making an educated guess — which is a perfectly respectable thing to do, as long as nobody mistakes it for a fact.

Severity, confidence and priority

There is no universal severity formula, and any report that pretends otherwise is selling precision it does not have. What works is a simple, explicit scale the team understands and agrees with:

• Severity — the consequence for the user and the business. Blocks a critical task or revenue; seriously slows or confuses users on an important path; irritates without stopping anyone; cosmetic.
• Confidence — how strong the evidence is. Validated by user evidence; likely, supported by several signals; possible, an expert hypothesis worth testing.
• Reach — how many users, and which ones, meet the problem.
• Effort — a rough estimate from design and engineering, not a promise.

Priority comes from reading these together. A blocker on the main onboarding path with validated evidence goes to the top, whatever its effort. A serious problem with low confidence goes into a test before it goes into a sprint. A cosmetic issue on a rarely used screen waits, however much it annoys the design team.

Two categories are easy to forget and often the most valuable. Stop building: features in the backlog that the evidence says users will not reach or do not need. And measure first: places where the product cannot currently tell you whether anything is working. Every audit should have both.

What the audit report includes — and what it does not

A useful report is shorter than people expect and more specific than they are used to. It includes:

• An executive summary — the few problems that matter most, in business language, with their consequences.
• The scoped journeys as they work today, step by step, with evidence attached to the steps where users struggle.
• The findings, each with its status, severity, confidence, reach and evidence.
• The priority order — fix now, test first, plan next, stop building, measure first.
• Two or three wireframes for critical flows, where a correction cannot be understood from words alone. Oksana’s rule: if it cannot be explained, it has to be shown, or the team will build the wrong fix.
• UX KPIs for the team and product managers: which indicators should move, and how they will be measured.

It does not include a new interface for the whole product or a score out of 100. Scores look good on a slide and tell a team nothing about what to do on Monday.

Depth varies with the product. Oksana describes a full audit — accessibility, heuristic review, interviews, support and review analysis, card sorting, analytics and KPI work — as a deep clean of a house, where you check under the tiles and behind the wallpaper rather than dusting the visible shelves. On a large product that can take a month to six weeks; a narrower audit of one journey takes far less. Match the depth to the decision.

Set UX KPIs from your own baseline, not from Reddit

Audits often end with metrics, and metrics are where teams fool themselves most comfortably. Oksana’s favourite example is churn: a team reports 20% churn, someone finds a founder on Reddit complaining about 40%, and suddenly 20% feels like a success.

It is not a benchmark. It is one stranger’s number from a different product, market and pricing model. In Oksana’s experience, churn should be heading towards single digits — seven, five, ideally three percent — though what is realistic always depends on the niche, the brand and the product. The point is not a universal target. It is that a product’s KPIs must come from its own baseline, segmented properly, with a direction and a reason.

Good UX KPIs are tied to the journeys you audited: the share of new users who reach first value within a day, completion of the core task without support, the number of support contacts per thousand active users on a given flow, time to complete a key action for established users. They are few, they are owned, and each audit recommendation says which one it should move.

Choose the right scope: full audit, activation or AI feature

Not every problem needs a full product audit. Picking the right scope saves weeks.

• A full UX audit examines the product system broadly: consistency, flows, accessibility, heuristics, content, support evidence, public feedback, analytics and KPIs. It is the right choice when drift is everywhere, the backlog has lost its order, or a major launch is coming. When a team wants an independent partner for this, that is the job of our UX audit service.
• An Activation Audit narrows the diagnosis to understanding, onboarding, first value and feature adoption — one segment, one critical journey, from sign-up to the moment the product proves its worth. If the problem is that new users never get it, the Activation Audit is faster and sharper than a full review.
• An AI feature UX audit focuses on whether users can understand, control and recover from AI-assisted behaviour inside a real flow — the failure modes we describe in our guide to AI UX design mistakes.
• Research or usability testing is the better scope when the team already knows where the problem is but not why, or needs behavioural evidence on one critical flow. UX research builds the evidence; usability testing observes whether people can complete the journey.

Common UX audit mistakes

We review a lot of audits other teams have commissioned, and the same mistakes keep turning up:

• Auditing screens instead of journeys. Every page looks acceptable in isolation; the product fails in the transitions between them. Walk the flow, not the gallery.
• Using the demo account. Perfect data hides empty states, slow states and the first-run experience — which is where new users actually live.
• Findings without evidence. “The navigation is confusing” with no ticket, recording, metric or session behind it is a preference. It might be right. Label it as a hypothesis.
• Everything is critical. A report with forty “high priority” findings has no priorities. If the audit cannot rank, it has not finished its job.
• Recommendations that are really a redesign. “Rebuild the dashboard” is not a recommendation; it is a new project. Say what specifically is wrong, what should change and how you will know.
• One reviewer, one perspective. Even an experienced auditor has blind spots. Combine the expert view with user evidence and, on larger audits, a second reviewer.
• No follow-through. The report is presented, everyone nods, and three months later the same problems are in the same places. More on that below.

Presenting the findings without starting a war

An audit tells people that things they built do not work. Present it badly and the team spends the meeting defending decisions instead of fixing them.

Lead with the user and the business, not with the interface: “New users on the free plan cannot find where to create a project, and most of them never do” lands better than “the empty state is poorly designed”. Show the evidence before the conclusion — a session clip, a support ticket in the customer’s own words — so the room reaches the conclusion with you. Keep authorship out of it: the audit is about the product, not about who made which call two years ago. And end with the order of work, so the meeting finishes on what to do next rather than on everything that is wrong. In our experience the teams that hear an audit best are the ones who asked the hardest questions in the kickoff; invite those questions early.

After the audit: make it change something

An audit that ends as a PDF in a shared folder has cost money and changed nothing. The follow-through matters as much as the review.

• Turn priorities into tickets with the finding, the evidence and the KPI attached, so the reason survives the trip into the sprint.
• Test the hypotheses that need it before building on them.
• Ship, then measure against the baseline recorded in the audit.
• Repeat the review at a cadence that matches how fast the product changes. For a product changing weekly with several people and agents shipping into it, three months is not paranoia.

The cobbler’s children always go barefoot: the teams that build experiences for a living are often the last to look at their own with fresh eyes. The ones that do it regularly are the ones whose products stay coherent while they grow.

Do not wait until the team has tried every redesign, tool and AI assistant. Audit before you put a product in front of a large audience, and repeat the review whenever delivery speed has let the experience outgrow its logic. What you should get back is not a new UI, but an evidence-linked order of work — supported by a few critical wireframes where words are not enough — that tells the team what to fix, what to test, what to defer and what to stop building.