How to do a UX audit, step by step
Guide · 8 min read · By Utkarsh Dhairya Panwar · Updated
To do a UX audit, agree the scope and the metric it should move, then gather evidence first: funnel data, support tickets, recordings. Walk each core task as each type of user, log every issue with its evidence, rate impact and effort, and hand back a ranked fix list.
What a UX audit is, and what it should leave you with
A UX audit is an expert review of a product, grounded in whatever evidence the team already has. Nobody new is watched using the product, so it isn't a usability test, and it isn't a redesign. It ends in a list of problems, each with proof and a proposed fix, ranked so the team knows what to work on next week.
I mean the whole product here: the handful of core tasks the business depends on, the settings nobody owns, the error states and the parts that grew without a designer. If you only care about signup to first value, the onboarding scorecard is a quicker first pass.
The six steps
- Agree the scope and the metric: Pick the three to six tasks the business depends on and the number the audit should move: activation, retention, support volume or time to finish a task. Write down what's out of scope.
- Gather evidence before opinions: Get step-level funnel data, a few months of support tickets grouped by topic, recordings of the worst step, and 30 minutes with whoever answers support. No step-level tracking is your first finding: you can't fix a drop you can't locate.
- Map each task per user type: Write out the steps of each core task for each kind of user: the admin, an invited member, someone on a self-hosted setup. B2B products tend to fail for the second or third user type rather than the first.
- Walk the tasks and log everything: Use fresh accounts and real data, and trigger every state you can. Log each issue in one sheet: screen, what happened, evidence, the heuristic it breaks.
- Rate impact and effort: Impact comes from the evidence: how many people hit it and how close it sits to the metric. Effort comes from a quick check with an engineer. Rate effort alone and you'll be wrong about the backend.
- Report a ranked list: Put the top issues on one page and give each finding its own entry (format below). Walk the team through it live and record the call.
What to check in each flow
Walk each task once as a new user with a fresh account, then again as someone without admin rights. I keep these questions open in a second window while I do it.
- How many steps sit between signup and first value? Write the number down.
- Can the person who signed up finish every step alone? Mark any step that needs an admin, owner or billing contact.
- When someone is blocked, does the screen offer a way forward, or only an error?
- Does each setup (cloud, self-hosted, each platform) get its own instructions, or does everyone read one long page?
- Does the user know what success looks like? "Your first pull request was reviewed" is a finish line. "Setup complete" isn't.
- Is anything asked for before it's needed, like team size or a role picker?
- After the first win, does the product link straight into the other things it does?
- Are emails and prompts triggered by what the user did, or sent on a fixed schedule?
- Do empty states say what will appear there and how to make it appear?
- Does every error say what happened and what to do next, in the user's words? Do a timeout and a decline look different?
- Are rules that cost the user something shown before they commit, not after?
Then read twenty support tickets and, for each one, find the screen where the mistake started. It's usually earlier than the screen people complain about.
A finding log, with real findings
These are findings from products I've worked on, logged the way I log them. Most audits leave out the evidence column, and it's the one that gets fixes approved.
| Finding | Evidence | Heuristic | Fix | Result |
|---|---|---|---|---|
| CodeAnt: non-admins can't connect a repo and get no way forward | Drop-off concentrated on the connect step | User control and freedom | Email the admin or share an invite link from the product | 40% less drop-off at that step |
| CodeAnt: self-hosted setup is one dense doc for every platform | Users filtering out steps that weren't theirs | Aesthetic and minimalist design | Step-by-step flows per platform, each with a short video | Part of the work that doubled trial-to-paid |
| CodeAnt: the same UI element built many ways | 18+ patterns doing similar jobs differently | Consistency and standards | One system for those patterns | Design turnaround down 30% |
| FamPay: vouchers are one-time use, users learn it after paying | Support tickets about lost voucher value | Error prevention | State the rule before purchase and at redemption | 80% fewer voucher tickets |
The first row is the admin wall. How the team found it and what shipped is written up in how we doubled trial-to-paid.
Ranking: impact against effort
Severity scales suit heuristic reviews (my heuristic evaluation guide uses Nielsen's 0 to 4 scale). For a whole-product audit I prefer impact against effort: it puts the cost next to the benefit, and a team can argue with it. Impact is mostly about position. A problem one step from first value beats a nicer settings page every time.
| Finding type | Impact | Effort | When to do it |
|---|---|---|---|
| Dead end on a step with heavy drop-off | High | Medium | First. This is where trials die. |
| Unclear rule or missing warning before a commitment | High | Low | This sprint. Often a copy and placement change. |
| Too many setup steps, or questions asked too early | High | Medium | Next, as an A/B test. |
| Emails on a fixed schedule instead of triggered by behaviour | Medium | Medium | Once the funnel itself is fixed. |
| Inconsistent components and spacing | Low to medium | Varies | Fold into design system work. |
High impact and low effort ships now. High impact and high effort gets a small test first. Low-impact items go in a backlog with a review date, so they don't sit there forever.
A report people will read
- Page one: the top five findings, one sentence each, with the fix and its priority.
- A flow map of each core task with the problem steps marked, so people can see where issues cluster.
- One page per finding: screenshot, what happens, evidence, fix, effort, owner.
- An appendix for low-impact items, so they're on record without diluting the main list.
- A recorded walkthrough, since half the people who need the reasoning won't read the document.
My UX audit report template has this structure as a fill-in document, with the severity scale, the finding card and the backlog page.
When to stop auditing and start testing
An audit finds what an experienced eye and your data can see. It can't tell you whether users understand your value, or which of two fixes they'll prefer. When the top finding is a guess about behaviour, take it into a five-user usability test before you build. If you'd rather hand the audit to someone outside the team, my UX audit service page explains how I run it.
Questions people ask
How long does a UX audit take?
One path, such as onboarding, takes about two weeks. A whole product takes longer, depending on how many core tasks and user types are in scope.
Should we audit internally or bring someone in?
Internal teams know the product but stop noticing its problems. An outsider spots them faster; the team is better at estimating effort. I'd want both in the review.
How much does a UX audit cost?
It depends on scope. My own UX audit starts from $900, and the pricing page has the details.
Sources
- 10 Usability Heuristics for User Interface Design, Nielsen Norman Group
- Severity Ratings for Usability Problems, Nielsen Norman Group
- Why You Only Need to Test with 5 Users, Nielsen Norman Group
Working on this?
Tell me what you're building and where it's stuck: book a 30-minute call, email work@utkarshdesign.com or send a brief.