How to Do a UX Audit: Step-by-Step Guide and Checklist

How do you do a UX audit?

You do a UX audit in four stages: scope one flow, gather evidence, review and test it, then rank the issues and write the plan. The point is not a long list of complaints. It is a short, ranked list of fixes your team can start on this month. This guide shows each step, the evidence to collect, a checklist you can copy and the mistakes that make audits useless.

What is a UX audit?

A UX audit is a structured review of a website or product to find where users struggle, why it happens and what to fix first. It combines data, observation and expert judgment. You can run one before a redesign to know what to keep, or on a live product that is not performing as expected.

When should you run a UX audit?

• Before a redesign, so you fix causes and not only looks
• When sign-ups, sales or engagement drop
• After adding several features that changed the flow
• When users keep asking support the same questions
• Before a big campaign that will send new traffic to a key page

What should you prepare before you start?

A little preparation keeps the audit short. Gather these before day one.

• Access to analytics, and a date range that covers a normal period.
• A list of the main tasks users come to do.
• Any earlier research, survey answers, or support tickets.
• A named person on your side who can answer questions and approve fixes.
• The devices and browsers your audience really uses.

Most audits take a few days to a couple of weeks, depending on how big the flow is and how quickly you can reach users. Involve someone from support or sales early. They know the complaints that never reach a dashboard.

What does the whole audit look like?

Four stages, and each one ends with something you can hand to the team.

Step 1: How do you set the goal and scope?

Decide what you are auditing and why. "The whole website" is too broad. "The sign-up flow" or "the path from homepage to contact form" is workable. Write down the goal in one line: more demo requests, fewer support tickets, better activation. Also note who the users are and what they are trying to do.

Step 2: How do you know your users?

Gather any research, personas or customer interviews you already have. If you have none, talk to a few customers or to your sales and support team. They hear the real questions every week, and ten minutes with them often saves a day of guessing.

What should you ask customers and your support team?

Keep the questions open and specific to the flow you chose.

• What were you trying to do the last time you used it?
• Where did you get stuck, or nearly give up?
• What did you expect to happen that did not?
• What do you tell new customers to watch out for?
• Which question do you answer again and again?

Write down the exact words people use. Their words often make better labels and headings than the ones your team invented.

Step 3: Which evidence should you collect?

Use three kinds together. Numbers show where the problem is, watching shows how it happens and talking shows why.

In analytics, look at which pages get traffic and where people leave, how many complete the main action, which devices they use and what they search for on your site. Then watch a handful of session recordings. You often see the problem within minutes: someone hunting for a button, or tapping something that is not clickable.

Step 4: How do you review the experience against good practice?

Walk through the flow yourself, on desktop and on a phone, as if you were new. Check whether it is clear where you are, whether the next step is obvious, whether the design gives feedback and whether people can recover from errors. Use the checklist further down.

Step 5: How do you test with real people?

Ask a few people from your target group to complete key tasks while you watch. Do not help them. Where they hesitate or get lost is where the design needs work. Even a small round of testing reveals problems that internal review never catches, because you already know how the product is meant to work.

Give tasks, not instructions. Say "find out what a project like yours would cost", not "click the pricing page". The way people search for the answer is the finding.

How do you run a simple test session?

1. Set up the task. Write two or three realistic tasks and a short intro that does not explain the design.
2. Ask people to think aloud. Tell them there are no wrong answers. You are testing the product, not them.
3. Stay quiet. If they ask where to click, ask what they would try. Resist the urge to rescue them.
4. Take notes on behavior. Write what they did, where they paused, and what they said. Keep opinions for later.
5. Debrief briefly. Ask what was confusing and what they expected to see.

After a few sessions, patterns appear. If several people trip on the same step, that step is a finding. If only one person does, note it and watch for it again. Five people is a common starting point, and you can repeat the round after the fixes ship.

Step 6: How do you rank the issues?

Not every problem deserves attention now. For each one, note how many users it affects, how much it hurts the goal and how hard it is to fix. Then place it on the grid.

• High impact, low effort: fix first. A confusing button label on a sign-up step that many users hit.
• High impact, high effort: plan it. A flow that needs restructuring.
• Low impact, low effort: batch them. Small copy and spacing fixes in one release.
• Low impact, high effort: leave them. Note them and move on.

Step 7: How do you write the report?

Keep it short and clear. For each issue include what you found, the evidence (data, a recording or a quote), why it matters and the recommended fix. End with a prioritized action list and owners. A report nobody acts on is wasted work.

What does a finished finding look like?

How do you present the audit so the team acts on it?

The way you share findings changes what happens next. Start with a one-page summary: the goal, the three to five biggest problems, and the fixes you recommend first. Put the full issue list after it for anyone who wants detail.

Show evidence, not just conclusions. A short recording clip or a direct user quote persuades faster than a paragraph of opinion. Keep the tone neutral. Describe what users did, not what the designer got wrong. Then walk the team through the ranked list in a short meeting and agree an owner and a target date for each fix-first item. Plan a quick follow-up review after the changes ship, so you can see whether the problem actually went away.

UX audit checklist

Navigation and structure

• Can users find the main pages within a couple of clicks?
• Are labels clear and free of internal jargon?
• Do users know where they are and how to go back?

Content and clarity

• Does the page explain what you offer in the first few seconds?
• Are headings, copy and calls to action clear and specific?
• Is there one main action per page?

Forms and flows

• Do forms ask only for what is needed?
• Are error messages helpful and easy to fix?
• Can users complete key tasks without dead ends?

Visual design and consistency

• Is there a clear visual hierarchy?
• Do buttons, links and components look and behave consistently?
• Is text readable, with enough contrast?

Mobile and performance

• Does the layout work on small screens, with tap-friendly buttons?
• Do pages load quickly on a phone?

Accessibility

• Can the site be used with a keyboard?
• Do images have meaningful alt text?
• Is color never the only way to show meaning?

What are the common UX audit mistakes?

• Auditing without a goal. You will find many issues and no direction.
• Relying on opinions. Back every finding with data or observation.
• Ignoring mobile. Many visitors will only ever see the phone version.
• Listing everything as urgent. Ranking is what makes an audit useful.
• Testing only with colleagues. They know too much. Use people from your real audience.
• Stopping at the report. Assign owners and dates, or nothing changes.

If you found that the dashboard or product screens are the problem, our guide to SaaS dashboard design covers what good looks like. If the audit points to a rebuild, read when to redesign your website before you commit.

Why do these mistakes matter so much?

Each one wastes the same scarce resource: your team's attention. An audit without a goal produces a long list nobody can act on. Opinion-led findings start arguments instead of fixes. Skipping mobile hides the experience many visitors have. Treating every issue as urgent means nothing gets done first. Fix these habits and the audit pays for itself, because the team spends its time on the few changes that matter. For help with structure problems that audits often reveal, read our information architecture guide, and use the website accessibility checklist to go deeper on the accessibility items above.

A practical example

A team notices that many visitors start the sign-up flow and few finish. Analytics show most people leave on step two. Recordings show them tapping a plain heading that looks like a button. In testing, two of five people say they were not sure what happens after they submit. The fixes: restyle the real button, add one line that explains what happens next and remove one form field. All three are low effort, and they sit in the fix-first box. That is what a good audit produces: a small number of clear changes, backed by evidence.

A second example: an audit for a content site

Consider a company blog that gets steady traffic but few readers move on to the services pages. Analytics show most visitors leave after one article. Recordings show readers scrolling to the bottom and finding nothing to do next. In testing, people say they liked the article but could not tell what the company actually offers.

The fixes are modest. Add a short, clear next step after each article. Link related articles in the body where they help. Make the navigation label for services say what it is. Then connect the blog to a page built to convert, which our guide on how to design a website that converts explains. None of this needs a redesign. It needs an audit that noticed where readers were stuck.

The takeaway

A UX audit turns "something feels off" into a clear list of what to fix and in which order. Use data, watch real users, rank the problems and finish with actions your team can start on. Want a UX audit of your product or website? Get in touch and we will review it with you.