What a UX audit actually is, and what it is not

A UX audit is a structured review of a product that already has users, run against a fixed set of checks, ending in a ranked list of what to fix first.

That is the whole definition. The word audit is doing the work in it: a scope agreed before anyone starts, a method that does not change halfway through, and an output somebody can act on next week. A designer clicking around your product for an afternoon and sending you a list of things they would have done differently is not an audit. It is an opinion, and opinions about interfaces are not scarce.

What actually happens during one

Two designers walk the product on desktop and on a phone, in the order a new user meets it: the landing page, the moment where someone works out what this thing is, the sign-up, the first session inside the product, and whatever is meant to bring them back on day two.

Every finding gets three things attached to it. A severity. A screenshot of where it happens. A suggested fix. Then the list is ordered by how many users hit the problem and what it costs them when they do. A sign-up form that breaks on a phone outranks a misaligned icon, however much the icon offends the designer who found it.

The output is short on purpose. A hundred findings is a document nobody reads. Fifteen findings in priority order is a fortnight of work for a small team, and the top three usually fit inside a week. We publish the exact checklist we run, so there is nothing mysterious about what is being looked at.

It is not a redesign

An audit tells you that your sign-up form asks for a company name before it has shown anyone a reason to want an account. It does not hand you the redesigned form. Those are two pieces of work with different costs, and blurring them is how a two-week review turns into a three-month project nobody budgeted for.

This matters more than it sounds. A studio that only sells redesigns will find redesign-shaped problems. An audit that can honestly end with your interface is fine, your problem is somewhere else is worth more than one that cannot.

It is not a usability test

A usability test puts real users in front of the product and watches what they do. An audit puts experienced designers in front of the product and applies principles that are already known to hold. Both find real problems. They find different ones.

Designers spot the broken pattern fast: the empty state with no next step, the two buttons competing to be primary, the error that says something failed without saying which field. What they cannot spot is the thing your users believe about your product that nobody on your side of the table believes. That takes watching a real person try. If you are choosing between the two, the trade-off is worth reading properly.

It cannot prove a fix will work

An audit finds friction. It does not prove that removing one particular piece of friction moves your particular number. That takes a change, a release, and a measurement, in that order. Anyone who quotes you a percentage improvement before touching your product is quoting you somebody else’s product.

The things it does not look at

Your offer. If people do not want what you are selling at the price you are selling it, the product will pass every usability check and still lose them. An audit cannot see motivation, and a clean audit on a weak offer is an expensive false negative.

Your code. Slow screens and heavy pages appear in the findings, because users feel them. The audit reports the symptom. Working out which query is responsible belongs to your engineers.

Your brand. Whether the blue is the right blue is not a usability question. Treating taste as a finding wastes the one document your team has agreed to read.

Your analytics. A public URL or a test account is enough, and most audits run without any numbers at all. Sharing them makes the findings sharper, because a drop-off at step three is a good reason to look at step three very hard. Nothing depends on it.

Who should get one

Your product has users and a number you care about has gone flat. This is the clearest case. The audit tells you whether the interface is a plausible suspect before you spend a quarter assuming it is.

You are about to commission a redesign. Do this first. A brief written from a ranked findings list is a different document from one written after a board meeting, and it is cheaper to argue about.

You shipped fast and never stopped. Products built by three people in a hurry collect a specific kind of debt: four different date pickers, three opinions about where Save lives, an empty state that was a to-do comment two years ago. Nobody inside the team can see it any more, which is exactly the point of asking someone outside it.

You are handing the product to a larger team. An audit is a cheap way to write down what is actually there before more people start adding to it. Dashboards and B2B products collect this drift faster than marketing sites do, because every customer request arrives as one more control on a screen that was already full. You can see how that pressure plays out across the twelve products we have designed: the ones with the most modules are the ones where navigation, not screens, turned out to be the first problem.

Who should not bother yet

If nothing has shipped, there is nothing to audit. Reviewing a Figma file is a design review: useful, cheaper, and a different conversation.

If you already know what is wrong and have known for six months, you do not need a document confirming it. Fix that, then look again.

If last quarter’s churn arrived the week a competitor halved their price, an interface review will not tell you anything you can use.

Why studios give the first one away

A good audit sells the work that follows better than any deck does. That is the commercial logic and it is worth saying out loud, because it also tells you how to read the report you receive. Findings should point at problems, not at a proposal. If every item in a report happens to require the studio that wrote it, read it again more slowly.

It also means a genuinely free first audit is not a trick. If you take the findings, fix them internally and never speak to us again, that is a fine outcome. You had a problem and it is smaller now.

Start with the smallest version

Before you commission anything, open your own sign-up flow on your own phone, as a stranger, and count the fields between the first tap and the first useful thing your product does for someone. Most teams find their first real finding in about ten minutes.

If you would rather have two designers do it, the free 15-point audit takes a live URL or a test account and comes back within one working day, ranked, with a screenshot and a fix for each item.