You have analytics telling you something is wrong. Conversion drops at a particular step. Support keeps answering the same question. Bounce rate on a key page is climbing. What the data doesn't tell you is *why* — and without that, every proposed fix is a guess.
A UX/UI audit is the systematic version of finding out. Not an opinion about your design, but a structured evaluation against established usability principles, cross-referenced with your own behavioural data, ending in a specific list of what to change and why.
What is a UX/UI audit?
A UX/UI audit is an expert evaluation of an existing product against recognised usability heuristics, interface design principles, and technical performance standards. It identifies the specific problems degrading your users' experience and pairs each one with a concrete, actionable recommendation.
The distinction that matters: an audit examines something that already exists. It is diagnostic, not exploratory. If you don't yet know what to build, you need discovery. If you have built something and it isn't performing, you need an audit.
A properly run audit answers three questions:
- What is broken? Specific, located problems — not "the navigation could be better."
- How much does it matter? Prioritised by impact, so you fix the expensive problems first.
- What should replace it? A recommendation grounded in research, not preference.
What actually gets audited
"UX audit" gets used loosely, which makes it hard to know what you're buying. A complete evaluation covers three distinct layers, and each one surfaces different problems.
Usability
The functional layer — whether people can actually accomplish what they came to do.
- Information architecture — whether the structure matches how users think about the content, rather than how the organisation is structured internally.
- Ergonomics — the physical and cognitive effort required to complete tasks.
- Consistency — whether the same action behaves the same way throughout the product.
- Predictability — whether users can anticipate what will happen before they act.
- Flexibility — whether the product accommodates different levels of experience and different routes to the same goal.
User interface
The visual layer, evaluated for its effect on usability rather than for aesthetics.
- Colour semantics — whether colour communicates meaning consistently, and whether it survives accessibility requirements.
- Typography — hierarchy, legibility, and line length. Text that is technically present but effectively unreadable is a common and expensive finding.
- Affordances — whether interactive elements look interactive. Buttons that don't look like buttons are a reliable source of abandoned tasks.
- Legibility and visual load — how much work the eye has to do to extract meaning.
- Interactivity — whether the product responds visibly to user action.
- Component and design system consistency — menus, headers, breadcrumbs, and repeated patterns behaving predictably across the product.
Technical performance
The layer that quietly undermines everything above it.
- Load speed — the single most reliable predictor of abandonment, and frequently the highest-ROI fix in an entire audit.
- Accessibility — both a legal exposure and a usability issue affecting a substantial share of users.
- Responsiveness — genuine mobile behaviour, not a desktop layout squeezed into a narrow viewport.
- Code and CMS structure — where front-end implementation is creating problems the design cannot fix.
Together these three layers make up the experience users actually have. Auditing only one of them explains only part of the problem.
The methodologies behind the findings
The difference between an audit and an opinion is whether the findings trace back to something established. A rigorous audit evaluates against recognised frameworks rather than personal taste.
Nielsen's usability heuristics — the ten principles that remain the foundation of usability evaluation, covering system status visibility, error prevention, user control, and recognition over recall.
Shneiderman's rules of interface design — eight golden rules addressing consistency, feedback, and reducing memory load.
Gerhardt-Powals' cognitive engineering principles — a framework focused specifically on reducing cognitive load and improving information processing.
Using several frameworks rather than one matters, because each surfaces a different class of problem. A finding that appears across multiple frameworks is a finding you can be confident about.
Evidence, not opinion
This is where audits diverge most sharply in quality. An audit built on the auditor's judgment alone produces plausible-sounding recommendations that are impossible to argue with — and impossible to verify.
A rigorous audit anchors findings in two kinds of evidence.
Your own behavioural data. Analytics platforms, heatmaps, session recordings, and scroll-depth data reveal what users actually do, not what an expert imagines they do. When a finding says "this content block isn't being read," it should be accompanied by the figure showing what proportion of visitors actually reached it.
Working with tools like Google Analytics, Hotjar, Microsoft Clarity, Crazy Egg, Heap, or UserZoom, the audit distinguishes between problems that are theoretically true and problems that are actually costing you something. If your team doesn't currently run analytics, that data can be collected as part of the engagement.
Published research. Recommendations reference established findings — the Baymard Institute's e-commerce usability research, Nielsen Norman Group studies, and the broader body of published usability work. A recommendation that cites the research behind it is one your team can evaluate on merit rather than accept on authority.
The practical effect: an audit that arrives with evidence attached ends the internal debate. Instead of two people disagreeing about whether a layout works, there's a number showing how many users read it and a study showing what the optimal alternative is.
What you receive
The audit is delivered as a structured document. Every finding follows the same format, which makes it usable by designers, developers, and stakeholders who won't read it end to end.
Problem — what is wrong, stated specifically, with the location identified and the evidence attached. Not "the homepage is cluttered," but the actual measurement and the actual consequence.
Recommendation — what to do instead, with the research supporting it and a link to the source, so the reasoning is inspectable rather than asserted.
Mockup — a visual of the recommended solution.
That third element is where audits succeed or fail in practice. A written recommendation gets interpreted, negotiated, and diluted on its way to implementation. A mockup removes the ambiguity — the team sees what was meant, and implementation matches intent. It also serves as a starting point for a redesign rather than a document that gets read once and archived.
Visualisation scope is set per project. Some clients want mockups only for the highest-priority findings. Some want functional wireframes for the whole product. Some go further and want the final, implementation-ready design.
How long does a UX audit take?
Timelines depend on scope and which layers are included:
- Usability audit — around 8 working days for a typical product. This is the deepest module: analytics review, information architecture, journey mapping, and heuristic evaluation.
- UI audit — around 3 days.
- Technical audit — around 2 days. Requires FTP and CMS access to be complete.
- Mockups and visualisations — from 2 days for key recommendations up to several weeks for full wireframes or finished design.
A comprehensive audit covering all layers typically runs 15+ working days.
Audits can be commissioned as individual modules. If the product's problems are clearly visual, a UI audit alone may be sufficient. If conversion is dropping and nobody knows why, the usability module is where to start.
When to commission an audit
Conversion or engagement is dropping and the cause is unclear. The classic case. Analytics show the symptom; an audit identifies the mechanism.
Before a redesign. Redesigning without auditing means rebuilding on the same assumptions that produced the current problems. An audit turns a redesign from a refresh into a fix.
Support is answering the same questions repeatedly. Recurring support tickets are usability findings that have already been paid for once. They are among the cheapest evidence available.
After launch, when reality diverges from expectation. Products behave differently with real users than in staging. An audit six to twelve weeks post-launch catches what testing missed.
When the team disagrees about direction. External evaluation with evidence attached resolves internal debates that have become circular.
Accessibility or compliance exposure. Where legal requirements apply, the audit identifies gaps before someone else does.
Common mistakes in UX audits
Findings without priorities. A list of eighty problems with no ranking is not actionable — it's overwhelming. Teams respond by fixing the easy ones and ignoring the important ones.
Recommendations without evidence. "Users prefer X" without a source is an opinion in professional packaging. It gets overruled by whoever in the organisation has more authority.
Auditing design while ignoring performance. A beautifully evaluated interface that takes six seconds to load has a performance problem, not a design problem. Auditing only the visible layer misses this entirely.
No implementation path. An audit that ends at "this is broken" leaves the hardest work undone. Recommendations need to be specific enough to build.
Ignoring the analytics you already have. Most organisations have more behavioural data than they use. An audit that doesn't examine it is discarding the cheapest evidence available.
Treating the audit as the deliverable. The document isn't the point. The improvement is. An audit that produces no changes is an expensive report.
How we run audits
Every finding in our audits carries three things: the problem, the evidence, and the recommendation with a source. That structure is deliberate — it means findings can be checked, challenged, and prioritised by your team rather than accepted on trust.
We work through your analytics before forming conclusions. Heatmaps, session recordings, and funnel data usually contain the answer to at least half the questions an audit is commissioned to resolve. Where that data doesn't exist, we can put the tooling in place first.
We audit against multiple frameworks rather than one, because different frameworks catch different problems, and convergent findings are the ones worth acting on first.
And we visualise the recommendations, because the gap between "recommended" and "implemented" is where most audits quietly fail.
Two levels of engagement. A full audit — the multi-day, multi-layer evaluation described above — suits products where the stakes justify the depth. For teams that need direction quickly, a rapid design review delivers a focused set of the most consequential findings in a single day. It's a smaller instrument for a smaller question, and we'll tell you which one your situation actually calls for.
The work has covered more than 50 in-depth audits and over 300 rapid design reviews since 2017, for clients in Poland and across Europe — including Netia, Budimex, Roche, Wittchen, Royal Coster, Monevo, Cube Group, and UpMenu, alongside work delivered through partner agencies. Most new clients arrive by referral, which is the metric we pay most attention to.
Audits are run personally by Mateusz Saniewski, certified by the Nielsen Norman Group — the institution that shaped modern UX practice — across information architecture, journey mapping, usability testing, UX leadership, and analytics, with previous work for organisations including Microsoft, ERGO, and ASUS.
Frequently asked questions
What's the difference between a UX audit and usability testing?
An audit is an expert evaluation against established principles — an experienced practitioner systematically examining the product. Usability testing puts real users in front of the product and observes where they struggle. Audits are faster and cheaper and catch a wide range of known problems; testing catches the unexpected ones that no framework predicts. They complement each other, and audits are usually the more efficient starting point.
Do you need access to our analytics?
It substantially improves the audit. Behavioural data separates theoretical problems from expensive ones and lets findings be prioritised by actual impact. Without it, an audit still identifies problems, but ranking them relies more on judgment. If you don't currently run analytics tooling, it can be implemented as part of the engagement.
Can you audit only part of a product?
Yes, and it's often the right call. Audits can be scoped to a specific flow — checkout, onboarding, account management — rather than an entire product. Focused scope produces deeper findings on the area that actually matters.
What if we can't implement all the recommendations?
Expected, and the reason findings are prioritised. Most of the available value sits in the top handful of recommendations. The remainder can be addressed over time or deliberately accepted as known limitations.
Do we need the technical audit if we have a development team?
Your developers know the codebase better than any external auditor will. What an external technical audit adds is the connection between technical characteristics and user behaviour — quantifying what load time is costing in abandonment, rather than just reporting that it's slow.
How is this different from a free audit tool?
Automated tools check technical criteria — page speed, contrast ratios, alt text, broken links. They are useful and worth running. What they cannot evaluate is whether the information architecture matches how users think, whether a flow makes sense, or whether an interface communicates what it does. Those require judgment.
Where to start
If you can name the page or step where things go wrong but not the reason, that gap is what an audit closes.
And if you can't name it either — the analytics you already have almost certainly can.