UX Audit: The Practical Guide with Checklist

Traffic is fine, rankings are okay, the ad budget is running — and still too few people buy. Or the support tickets keep revolving around the same three spots. Or a relaunch is coming up, but nobody can say precisely what is actually broken about the current product. If any of these scenarios sounds familiar, you don't need a new design — you first need an honest diagnosis. That is exactly what a UX audit delivers: a systematic analysis that answers a single question — where exactly are you losing users, and why.

This guide shows you what concretely happens in a professional UX audit, hands you a checklist you can start with today, and gives an honest assessment of what it costs and when it pays off. As a UX design agency we run audits like these regularly — the examples here come from real projects, not from a textbook.

What a UX audit is — and what it isn't

A UX audit is a structured expert analysis of your digital product along established criteria, complemented by hard data from actual user behaviour. The result is not a gut feeling but a prioritised list of concrete problems with recommendations for action. Think of it as a technical inspection for your website or app: it is checked against known standards, the defects are recorded, and in the end you know what to repair and in which order.

Just as important is the distinction, so expectations are right:

• An audit is not a redesign. It delivers the diagnosis, not the new interface. Implementation is a separate step (and often the reason the audit pays for itself — you then redesign deliberately, not on suspicion).
• An audit is not a usability test with real users. A test observes real people doing real tasks. That is valuable and can be part of an audit, but it is more expensive and slower. An audit relies primarily on expert evaluation plus existing behavioural data.
• An audit is not "I like it / I don't like it". No single designer subjectively commenting on a few screenshots. The quality comes from method and traceability — every finding can be traced back to a principle or a data source.

The difference between an audit and pure user research also matters. An audit tells you what about your product falls short of good practice. If instead you want to understand what your users actually want, how they think and what needs they bring, qualitative user research methods are the right path. In practice the two complement each other: the audit finds the obvious brakes quickly and cheaply; research answers the deeper questions.

The 5 phases of a professional UX audit

An audit worth anything follows a clear process. Not "have a look and take notes", but five phases that build on each other. Without this structure you end up with an unsorted list of defects — impressively long, but useless.

Phase 1: Scope and goals

The starting point is not the product but the business goal. "Check the whole website" is not a scope, it is a guarantee of superficiality. Instead we first define: what is the product supposed to achieve, and which two or three user flows are critical for that? For an online shop that is usually product search, product detail page and checkout. For a SaaS application perhaps onboarding, the core feature and reactivation. This focus determines the quality of the entire audit — it makes sure the analysis goes deep exactly where revenue and satisfaction are actually created.

Phase 2: Data analysis

Before anyone voices an opinion, we look at real behaviour. Analytics show where users drop out of the critical flows. Funnel evaluations reveal at which step the biggest drop-offs happen. Heatmaps and scroll maps show what users see and what never comes into view. Session recordings capture concrete moments of failure — the angry rage-click on an element that isn't clickable at all, or the helpless back-and-forth scrolling before a form is abandoned. This phase delivers the hypotheses and, at least as importantly, the priority: a problem on a page with 50,000 monthly visitors weighs more than one on a page with 300.

Phase 3: Expert evaluation

Now the method comes into play. The core is heuristic evaluation against Jakob Nielsen's established usability heuristics — ten principles such as visibility of system status, consistency, error prevention or match with the real world. Every critical flow is walked through step by step as a cognitive walkthrough, from the perspective of a user who wants to reach the goal. Added to that is an accessibility quick check against WCAG fundamentals: contrast, keyboard operability, meaningful labels. Accessibility is no longer a nice-to-have — under the German Accessibility Act (BFSG) it is a legal requirement for many digital products.

Phase 4: Prioritising findings

An audit that spits out 200 findings is not a good audit — it is a capitulation before the real work. The art lies in filtering out of everything discovered the twenty problems that truly matter. We rate every finding along two axes: how big is the effect on the business goal (impact), and how costly is the fix (effort). A problem with high impact and low effort goes to the top of the list — a cosmetic detail nobody cares about drops out. That is how a collection of material becomes a basis for decisions.

Phase 5: Roadmap and quick wins

The result is not a PDF grave good that disappears into a folder after one skim. It is an actionable roadmap: prioritised recommendations, each with the concrete problem, the justification (data point or violated principle) and a clear proposed solution. Up front are the quick wins — the changes that are fast to implement and work immediately. A good audit gives your team something to do on the Monday after, not just something to read.

The DIY UX audit checklist

A full audit belongs in experienced hands, but you can go through the most important checkpoints yourself today. Take one of your product's critical flows, open it once on desktop and once on your phone, and honestly answer the question in each row. Every "no" or "don't know" is a candidate for your later audit.

First impression

Checkpoint	The question you answer
Clarity of the offer	Does a first-time visitor understand within five seconds what is offered here and for whom?
Next step	Is it clear at first glance what to do next?
Perceived load time	Does the page feel fast, or are you staring at white space or janky rendering?

Navigation and information architecture

Checkpoint	The question you answer
Orientation	Does the user always know where they are and how to get back?
Labels	Are menu items named in the users' language, not in internal jargon?
Findability	Can core content be found in at most two to three clicks?

Forms and conversion points

Checkpoint	The question you answer
Field count	Does every form ask only for what is truly needed right now?
Error handling	Does an error message say what is wrong and how to fix it?
CTA clarity	Is there one dominant call to action per page, not five of equal weight?

Mobile

Checkpoint	The question you answer
Touch targets	Are buttons and links big enough for a thumb, without mis-taps?
Core function visible	Is the most important action reachable without hunting for it in the menu?
Input	Do number fields bring up the numeric keyboard, email fields the matching layout?

Trust, transparency and accessibility

Checkpoint	The question you answer
Trust signals	Are prices, shipping costs and conditions visible before commitment?
Contrast	Is text readable for weaker eyes too (sufficient colour contrast)?
Keyboard	Can the entire flow be operated by keyboard, without a mouse?

If you notice while going through that many questions cluster around the transitions between steps — users losing the thread between two pages — then it is worth looking at the whole journey. That is exactly what user journey mapping is for: it makes visible where friction arises along the way, instead of judging isolated screens.

Typical findings from practice

Across many audits the same patterns repeat. If you recognise one of them in your product, you already have a starting point.

• The form asks too much, too early. A newsletter sign-up with seven fields, a checkout that forces registration before you may buy. Every additional field before the goal costs completions. In our projects, trimming forms is almost always a quick win.
• CTA competition. Five identically styled buttons fight for attention on one page — "Buy now", "Learn more", "Newsletter", "Book demo", "Contact". The result: the user chooses none. One clear primary call, the rest visually subordinate, often works immediately.
• Mobile hides the core function. The most important action — search, cart, "book appointment" — disappears into the hamburger menu on the phone while desktop shows it prominently. With more than half of traffic being mobile, that is an expensive mistake.
• Error messages without help. "An error occurred." No hint which field, what was wrong, how to continue. The user tries twice and is gone. Good error messages name the concrete problem and the next step.
• System status in blind flight. After a click, seemingly nothing happens — no loading indicator, no confirmation. The user clicks again, triggers the action twice, or gives up. Visible feedback for every action is one of the oldest usability rules and is still constantly violated.
• Inconsistent patterns. The same action type looks different on three pages, terms switch ("cart" here, "list" there for the same thing). Every inconsistency forces the user to relearn what they should already know.

What a UX audit costs — and when it pays off

Honest assessment instead of smoke bombs: a focused, serious UX audit starts at €2,500 with us and typically takes two to three weeks. The upper range depends on scope — a single critical flow is checked faster than a complex application with many roles and states. What justifies the price is not the pure analysis time but the savings afterwards: you redesign deliberately instead of on suspicion, and you avoid pouring six-figure implementation budgets into changes that solve no real problem.

The harder question is often not "what does it cost" but "is an audit even the right thing". A rough orientation:

Situation	What you probably need
Product runs, but conversion/satisfaction lag behind potential	UX audit — fast diagnosis of the friction points
Design is visibly outdated, findings obvious, implementation budget in place	Rather go straight to the redesign (an audit saves little here)
You don't know who your users are or what they want	User research first, then the audit
Relaunch planned, but nobody knows what is good or bad about the current product	UX audit as the foundation for the relaunch briefing

The most common mistake is starting the relaunch before understanding what actually works about the current product. A lot of money then gets spent accidentally throwing away existing strengths and repeating old mistakes in new clothes. An audit before the relaunch is the cheapest insurance against exactly that mistake.

How to recognise a good audit provider

Not every "UX audit" on the market is one. Many are disguised sales presentations for a subsequent redesign. These points separate serious offers from quick opinions:

• Methodological transparency. A good provider tells you up front which criteria are checked — heuristic evaluation, WCAG, defined flows. Anyone who only says "we'll have a look" delivers gut feeling.
• Prioritised findings instead of a lucky dip. Ask for a sample report. Does it contain prioritisation by impact and effort, or is it an endless list of defects of equal rank? Prioritisation is the real value.
• Data and heuristics combined. Pure opinion without a look at the analytics is too weak; pure numbers without UX interpretation are too blind. Good audits combine both.
• Actionability. Every recommendation should be concrete enough that your team knows what to do. "Improve the navigation" is worthless. "Reduce the main navigation from nine to five items, merge X and Y" is a recommendation.
• Independence from the follow-up order. A provider who honestly says "you don't need a big redesign here, just three targeted fixes" is thinking in your interest — not in their own revenue.