What Is a UX Audit and How Do You Run One? A Guide to Finding Conversion Barriers

Your site gets traffic, yet forms stay empty and carts stall at checkout. Also, nobody on the team can say why. At that point the next step is not a redesign. So the answer is a UX audit. I have worked on corporate websites and online stores since 2012, and the cause is rarely one big flaw. Usually it is a pile of small frictions. In this guide I walk through the audit in the order I actually run it.

What is a UX audit and what does it do?

A UX audit is a structured review of a website's user experience that combines usability heuristics, analytics, heatmaps and session recordings to find the barriers that block conversions. The output is not an opinion piece. It is a list of findings, each tied to a page and to evidence, and ranked by severity.

In other words, a UX audit does not answer "is it pretty?". Instead, it asks where visitors get stuck, why they get stuck and how much effort a fix will take. That shift matters because the real value of an audit is that it moves the discussion from taste to data.

In short, every audit should produce three things: a map of the problems, proof for each problem and a fix order. As a result, the team knows what it is changing and why, and it can measure the outcome later.

How is a UX audit different from a list of UX mistakes?

You can find plenty of "top UX mistakes" articles online. I wrote one myself about UX mistakes that kill sales. However, a list tells you what might be wrong. An audit tells you what is actually wrong on your site.

A list is a general guess, while an audit is a local diagnosis. For example, everyone knows long forms hurt conversions. Still, only your data shows the exact field where your visitors give up. So I treat lists as a source of hypotheses. The audit then confirms or rejects each one.

In practice, I open such a list on day one and use it as a checklist. I look for each item on the relevant page and then try to back it up with data. If the data does not support it, the item goes. That way the team never spends a sprint fixing a problem that does not exist.

When should you run a UX audit?

Not every site needs constant auditing. That said, some signals mean every month of waiting costs you customers. These are the situations where I most often recommend one:

• Traffic is flat or growing, but leads, calls or sales are falling.
• Ad spend went up and cost per conversion went up with it.
• Mobile has a large share of traffic, but mobile conversion lags far behind desktop.
• The site was just relaunched and results got worse than before.
• Support keeps hearing "I could not find this on your website".
• A redesign is coming and you want to know what to keep.

The last point is the most underused and the most profitable. An audit before a redesign protects the parts that work. It also stops you from carrying old mistakes into a new layout. That is why a conversion focused web design project often starts with an audit.

Which goals should you set before a UX audit?

An audit without a goal turns into an endless list of observations. So my first question in the kickoff is simple: what is this site's job? For an online store the answer is sales. For a corporate site it is usually quote requests, and for a SaaS product it is trial signups.

Next, I write down the main conversion and the steps that feed it. For example, if the quote form is the goal, the steps are a service page view, a click to the form page and a form submission. These steps become the skeleton of the audit. I cover goal selection in detail in how to set website conversion goals.

Finally, I limit the scope. Reviewing every page of a large site at the same depth makes no sense. Instead, I focus on the templates that carry most traffic and revenue: the homepage, category pages, product or service pages, forms and checkout.

Write the scope down, too. If blog pages are out of scope this round, say so at the start. Then fix the date range for the data. A campaign month and a quiet month can show very different behavior.

What data do you need to collect for the audit?

A good UX audit never relies on one source. Each source answers a different question, so I gather them together from the start. This is my default starting set:

1. GA4: engagement by page, funnel steps, and device and channel breakdowns.
2. Search Console: the queries people used, which reveal their expectations.
3. Heatmaps and session recordings: clicks, scroll depth and real behavior.
4. Core Web Vitals: field data on speed and visual stability.
5. Support logs: the questions that keep coming in by phone, chat or email.
6. Sales team notes: what prospects ask before they decide.

However, most audits skip the last two. Yet every customer who calls to ask about delivery times is telling you the answer is hard to find on the site. Also, check that your tracking works. One miscounted conversion can send the whole audit in the wrong direction.

How do you run a heuristic evaluation with Nielsen's 10 principles?

A heuristic evaluation is an expert review of an interface against accepted usability principles. The most widely used framework is Jakob Nielsen's 10 usability heuristics. I check each key template against all ten:

1. Visibility of system status: does the user see what is happening?
2. Match between the system and the real world: is the wording the customer's wording?
3. User control and freedom: is it easy to go back or undo?
4. Consistency and standards: does the same thing look the same everywhere?
5. Error prevention: do you stop wrong input before it happens?
6. Recognition rather than recall: is the information on screen or in memory?
7. Flexibility and efficiency of use: do returning users have shortcuts?
8. Aesthetic and minimalist design: do extra elements split attention?
9. Help users recognize, diagnose and recover from errors: does the message offer a fix?
10. Help and documentation: can people find help when they need it?

I log every violation with a screenshot, the principle it breaks and a short note. This turns a finding from "I think" into something anyone can verify.

One warning, though. The heuristics are not a scorecard. A page can pass all ten and still fail to sell. Heuristics measure usability, not persuasion. So I note issues with the value proposition, pricing and trust signals in a separate section.

How many evaluators does a heuristic review need?

One expert catches some problems, never all of them. The Nielsen Norman Group guide on how to conduct a heuristic evaluation says that ideally three to five people should evaluate the same interface independently. That is because each evaluator tends to trip over different issues.

Small businesses rarely have three UX specialists on hand. In that case I add two people from different roles to my own review, for example a sales rep and a support agent. I brief them on the principles and then ask each to browse the site alone.

Above all, independence is the key. If evaluators see each other's notes, they converge on the same issues and you lose variety. So I merge notes only after everyone has finished. Then I combine duplicates into single findings.

How do you find conversion barriers in GA4?

Heuristics tell you where a problem might be. Analytics, on the other hand, tell you how big it is. In GA4 I first build a funnel exploration with the steps of the main conversion path. The step with the biggest drop gets most of the audit's attention.

Then I break the same funnel down by device, channel and new versus returning users. For example, if the form step works on desktop but collapses on mobile, the problem is probably the mobile layout, not the copy. Likewise, if paid visitors bounce from one page, the ad and the page may not match.

• List landing pages with low engagement rates.
• Compare the biggest drop between funnel steps across devices.
• Review site search terms to find things people want but cannot see in the menu.
• Look closely at exit pages, especially form and cart steps.

To read engagement numbers correctly, see my guide on reducing bounce rate on a business website.

What do heatmaps show in a UX audit, and what do they miss?

A heatmap summarizes clicks, scroll depth and sometimes mouse movement on a page in color. As a free option, Microsoft Clarity offers both heatmaps and session recordings, and setup is a single tag.

In practice, heatmaps are good at three things. First, they reveal clicks on elements that are not links, such as images or headings people expect to open. Second, they show when an important section sits below the point where most people stop scrolling. Third, they show attention drifting away from the call to action.

However, a heatmap never explains the cause. A button with few clicks might be hard to see. Or visitors might simply not be convinced yet. So I never use heatmaps alone. I read them next to the funnel drop and the recordings. Also, on low traffic pages the map can mislead, so wait for a meaningful sample first.

What should you look for in session recordings?

Session recordings let you watch how individual visitors move through the site. They are powerful, but random viewing eats hours. So I always filter recordings by a question, for example "mobile visitors who reached the form page and left without submitting".

While watching, I note these behaviors:

• Rage clicks: fast repeated clicks on one spot usually point to something broken.
• Scrolling up and down: the visitor cannot find what they came for.
• Pausing at a field: a form question is confusing.
• Leaving and returning: the visitor is checking price or reviews elsewhere.

Also, mind personal data. Make sure the tool masks form fields and mention it in your privacy notice. Under GDPR and similar laws, skipping this step creates real risk.

Does search intent belong in a UX audit?

Yes, because some conversion problems come from mismatched expectations, not design. A visitor searches for "price", lands on the page and finds no pricing at all. Even the best layout cannot keep that person. So for each key landing page, I pull the top queries from Search Console.

Then I compare two things: what the query promises and what the first screen answers. For example, someone searching "setup time" wants to see the timeline first, not the company history. For paid traffic I run the same check between the ad text and the page headline.

In practice, the fix is often small. You might move the headline closer to the query, add a short answer block above the fold or pull key information higher. As a result, bounces drop and the page answers the searcher more directly.

How do you audit forms and checkout steps?

On most sites, the heaviest losses happen in the final steps. That is why I review the form and the checkout flow in a separate session, field by field. For every field I ask one question: can we do the job without this information?

Next, I test error cases one by one. What happens when I enter a phone number in the wrong format? Does the error appear next to the field or at the top of the page? And does the form wipe my input after a reload? Does the phone field open a numeric keypad on mobile? Details like these are often the real reason people abandon a form.

After that, I audit what happens after submission. Does the thank you page explain the next step? Does the confirmation email actually arrive? I cover the design side in lead form design for bookings, quotes and demos, and I use those rules as a benchmark during the audit.

How do you check mobile experience and accessibility?

I do not check mobile only in a narrow browser window. I browse on a real phone on a real connection. An emulator cannot fully reproduce touch accuracy, a keyboard covering the screen or lag on a slow network.

For accessibility, I also run three quick checks. Is the contrast between text and background sufficient? Can someone navigate the site with a keyboard alone? Do images and form fields have descriptive labels? The WCAG guidelines give measurable criteria here. For instance, normal text needs a contrast ratio of at least 4.5:1.

So do not treat accessibility as a separate charity project. Low contrast pricing is unreadable for anyone looking at a phone in sunlight. In short, accessibility findings are often conversion findings too.

Do speed and Core Web Vitals belong in a UX audit?

They do, because a slow or jumpy page ruins even the best design. Google's Core Web Vitals overview on web.dev sets three thresholds for a good experience: LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less. These values apply at the 75th percentile of page visits.

In an audit I check field data before any lab score. The Core Web Vitals report in Search Console shows which template groups have problems. Then I test that template with Google Lighthouse to find the cause.

Specifically, CLS deserves a UX lens. If a button shifts down while the page loads, users click the wrong thing. That leads to rage clicks and lost trust. So speed findings and behavior findings are often two sides of the same problem.

When you write a speed finding, translate it into business language. Instead of "LCP is 4 seconds", write "the product image appears late on mobile and visitors stare at an empty box". Management grasps the priority much faster that way.

Which template should you use to log findings?

Audits most often fall apart when findings get written up. For example, a note like "the menu is bad" tells a developer nothing. So I log every finding on the same card, and I ask the team to do the same:

• Title: the problem in one sentence.
• Location: page, template and device.
• Evidence: screenshot, GA4 drop, heatmap or recording link.
• Principle broken: Nielsen heuristic, WCAG criterion or Core Web Vitals metric.
• Impact: which conversion step it affects.
• Recommendation: a concrete fix, with draft copy if needed.
• Severity and effort score: for prioritization.

With this structure, the list moves straight into your task tracker. Moreover, when someone asks months later why a change happened, the answer sits on the card.

How do you prioritize UX audit findings?

An audit usually produces dozens of findings, and you cannot fix them all at once. I set priority on two axes: impact on conversion and effort to fix. For severity I use a simple table adapted from Nielsen's 0 to 4 severity scale:

Then I add a rough effort estimate to each finding: hours, days or weeks. Where high severity meets low effort, you get your quick wins list. Use the table as a frame for discussion, not as a rigid rule.

What should a good UX audit report include?

First, the report should work in layers for different readers. An executive wants to see the losses and the top three actions on page one. A developer wants the detailed cards. So I build the report in this order:

1. A one page executive summary with key findings and first steps.
2. Scope and method: which pages, which data, which date range.
3. The conversion funnel and its biggest drop points.
4. Finding cards sorted by severity.
5. A split between quick wins and long term recommendations.
6. A measurement plan for tracking each fix.

In short, what matters is usability, not length. A hundred page PDF tends to sit forgotten in a folder. In contrast, a short summary and a well tagged list end up on the task board the next day.

How should you measure the impact of fixes?

An audit stays half done until you measure the fixes after release. That is why every finding card gets a success metric from the start. For example, if you removed form fields, the metric is the ratio of form starts to submissions.

Where possible, compare before and after periods of equal length and similar seasonality. On high traffic pages an A/B test gives cleaner answers. On low traffic corporate sites, though, a test may never reach significance. In that case I read the trend together with qualitative feedback.

For choosing what to report, my article on digital marketing KPIs can help. Above all, read conversion rate changes alongside revenue and lead quality, never in isolation.

What are the most common mistakes during a UX audit?

How you run the audit shapes the outcome as much as the method. Over the years I have seen the same mistakes in my own projects and in reports I inherited:

• Picking a solution first and then using the audit to justify it.
• Reviewing only on desktop, even though most traffic comes from phones on many sites.
• Presenting every finding at the same weight and burying the team in hundreds of items.
• Skipping evidence, so findings get debated as personal opinion.
• Trusting funnel data before checking the tracking setup.
• Never measuring after the fixes and leaving the audit as a one off document.

In other words, all of these share one root. They treat the audit as a deliverable instead of a process. A good UX audit changes how the team makes decisions. So handing over the report is not the finish line. It is the start of an improvement loop.

How often should you repeat a UX audit?

A one time audit is a good start. Still, your site, your campaigns and customer expectations keep changing. Here is my starting cadence, based on field experience and not a guarantee. Adjust it to how fast your site changes:

• Full UX audit: once a year or before a major redesign.
• Focused mini audit: when a new campaign, product line or form goes live.
• Monthly quick check: funnel report, Core Web Vitals and a handful of recordings.

In practice, the monthly check should take half a day at most. The goal is not a new report. It is to catch an unexpected drop early, before small issues pile up into a full rebuild.

Should you run the audit in house or hire an expert?

Put simply, both options have merit. Your team knows the site and the customers well. But it is also used to the site, so it stops seeing problems. An outside reviewer brings fresh eyes, though they need time to learn your business.

The most efficient model is usually a mix. Your team can handle data collection and recording reviews. For the heuristic review and prioritization, add at least one outside expert, which also balances internal debates. If you plan to hire help, my UI and UX design services checklist gives you questions to ask.

Also decide early who will implement the fixes. The bigger the gap between report and execution, the faster findings go stale. If you need design and development support, my web design service turns audit findings straight into an implementation plan.

A one week plan for your first UX audit

If you want to start small before a larger project, try this five day plan. A few hours per day is enough:

1. Start on day 1: write down the main conversion and its funnel steps, then verify GA4 tracking.
2. On day 2, break the funnel down by device and channel, and find the biggest drop.
3. Next, on day 3, review that step's template against Nielsen's heuristics and fill in finding cards.
4. Then use day 4 to study the heatmap for the same page and watch around twenty recordings.
5. Finally, on day 5, rank findings by severity and effort, then plan the first three fixes.

This plan does not replace a full UX audit. Even so, it shows you what matters most, and it helps your team build an audit habit. As you measure results, you can extend the process to the site's other templates.