Table of contents
A UX audit is not pointing out minor things like “the button colour is wrong” - with no context, no numbers, no priorities. An audit that works combines heuristics, session recordings, analytics and conversations with the team - and ends with three things worth doing this quarter.
We’ve been running UX audits for six years, for startups, banks and software houses. We’ve met every version of this service - from 25-page documents that end up in the “to read someday” folder, to 3-week processes that genuinely change the product roadmap. This article describes what, in our view, works - and what’s worth avoiding when you order an audit from someone else.
What a UX audit is (and what it isn’t)
A UX audit is an expert analysis of a digital product in terms of the user experience and business goals. The auditor (or team) reviews the interface, the flows, the copy, the analytics data and session recordings - and points out which elements make it harder for the user to achieve their goal or directly cost the company money.
The most important thing most audits don’t do: a good audit doesn’t end with a list of 87 observed problems. It ends with a prioritised map of changes tied to the product’s KPIs and the cost of implementation. The best recommendations are the ones the dev/PM team can take and drop into the backlog on Monday morning.
What to avoid - in the audit and in the auditor
The word “audit” has become a little blurred in UX. Every designer with a week’s experience offers audits - because it’s the easiest way to land a first client. Some audits are excellent. Most are okay. Some are a waste of time on both sides.
The “button colour” trap
The most common mistake of a weak audit: stopping at the visual layer. “Contrast too low”, “button too small”, “don’t use yellow on white”. That isn’t a UX audit - it’s a CSS code review. Business value: zero, until someone shows how that button affects conversion.
Weak recommendations
- "The button colour should be more contrasting."
- "No icons in the menu - add some."
- "Nielsen's heuristic no. 5 isn't met."
- "The hero should have a bigger header."
Good recommendations
- "41% drop-off at step 3 of onboarding - remove the tax-ID field, it's not required at this stage."
- "7 of 8 tested users couldn't find the billing panel."
- "The contact form takes 4 minutes - cut it to 90 sec (tested)."
- "The hero claim describes a feature, not an outcome - based on 9 interviews."
An audit with no business goal
The second common mistake: a “general” audit. You order an audit, you get 70 observations, you don’t know what to do. An audit should always begin with the question - what exactly do we want to improve: conversion, retention, support cost, onboarding time, NPS? Without that question, an audit is just a designer’s opinion.
Four methods we combine in a single audit
A heuristic audit is only the starting point. A full UX audit combines a minimum of four data sources - because each one shows a different truth.
- Heuristic audit. Nielsen’s 10 heuristics + our internal list of 40 points. Fast. A good baseline, a weak diagnosis of individual paths.
- Data analysis. Google Analytics, Mixpanel, Hotjar, FullStory. Funnels, drop-off, heatmaps, recordings. Shows where it hurts - not why.
- User testing. 5–8 moderated sessions. Shows why it hurts. Without this, an audit is just a hypothesis.
- Internal interviews. With the product manager, support, sales. Support often knows more about the product than design - because they get daily calls about what doesn’t work.
- 90 +
- audits
in 6 years - 14
- industries
served - 3 wks
- average
turnaround - 38 %
- average KPI
improvement after rollout
Four methods, not one. A heuristic audit without session recordings easily falls into the trap of the designer’s opinion. Recordings without heuristics - into numerical chaos. They have to be combined.
An audit without numbers is an opinion. An audit without a conversation with the user is a hypothesis. Only together is it an audit.
What our process looks like - step by step
A standard UX audit at Wzór takes 3 weeks. Shorter tends to be superficial, longer - over-engineered. Here’s what happens each week:
Week 1 - Reconnaissance
A kick-off with you and your team. We define 3 KPIs we’ll measure. We get access to analytics, session-recording tools and the production environment. We start the heuristic review and recruiting 6 users for testing.
Week 2 - Exploration
Moderated user testing (60 min each). Data analysis - funnels, retention, session recordings. Interviews with the product manager and support. A picture builds up: where it really hurts, and where we only think it does.
Week 3 - Synthesis and document
Prioritising problems (an impact × effort matrix). Writing the report. A walkthrough session with the team - we explain every recommendation, answer questions and agree who takes what into the backlog.
What you’ll find in the audit report
The report is 30–80 pages, depending on the scale. The structure is always the same - because that’s the easiest way to read it and refer to it.
- Executive summary (2 pages). The 10 most important findings, the impact on KPIs, the top 3 recommendations. For the board.
- Context and methodology. What we studied, how, on what sample. So the report is verifiable.
- A prioritised map of problems. Each problem has: a description, evidence (a screenshot or recording), the impact on KPIs, the cost of implementation, a priority (P0–P3).
- Concrete recommendations. Not “improve”, but “change X to Y, here’s a wireframe or an example from Stripe / Notion”.
- Implementation roadmap. What’s for the next sprint, what’s for the quarter, what comes after.
- Appendices. Session recordings, interview transcripts, raw test data.
Examples from our projects
Two examples of audits that translated into measurable results. The full case studies are further on, in the “Related projects” section - here’s the short version.
Fonia - SaaS onboarding
The audit found 4 bottlenecks in the onboarding of new users. After implementing 3 of them (we left the fourth for later - it required backend changes) drop-off fell by 38%. Time: 5 weeks of audit + implementation.
Swish - B2B product page
An audit of the landing page, pricing and demo form. Six concrete changes, each with a hypothesis and a way to measure it. After rollout: +38% CTR on the demo form, +21% conversion on pricing.
When to order a UX audit (and when to skip it)
A UX audit isn’t a universal cure. Sometimes it’s the best investment of the quarter, sometimes a waste of money. Here’s when it makes sense:
- The conversion funnel is collapsing and analytics don’t point to a single clear cause.
- NPS or retention are dropping for no clear reason - the product seems to work.
- You’re planning a redesign and want a baseline so you know what’s worth changing.
- You’re entering a new industry (e.g. a regulated one - fintech, healthtech) and need an outside eye.
- Support is melting down under the weight of the same questions - that’s a UX signal.
And when it doesn’t make sense:
- The product is at the stage of its first 100 users - more conversations with customers first, the audit later.
- The team has no time to implement the recommendations within 3 months. A “drawer” audit doesn’t pay off.
- You’re looking for confirmation of your own hypothesis. An audit may overturn it - be ready.
Co-founder and President of the UX agency Wzór. Business analyst - she leads interface projects for mobile, desktop and e-commerce applications, from business analysis, research and information architecture to polished UI.
