What an audit actually looks at

"Audit" is a word that arrives with a deliverable attached — a deck, a list, a score out of a hundred — and almost no agreement about what it is supposed to find. Which is why most of them get read once and filed.

A product experience audit has one job: find where the product loses people, and say why. Not whether it is attractive, not whether it follows current convention. Where someone trying to do a thing stops doing it.

It is not a design review

A design review asks whether the work is good. An audit asks whether the work is working. Those produce different findings, and conflating them is the most common way an audit becomes unusable.

The test is whether a finding survives the question "and what does that cost?". "The spacing is inconsistent" usually does not. "The primary action and the destructive one look identical, and sit next to each other" does, because you can describe the consequence without guessing.

Every finding should name what breaks, for whom, and what it costs. A finding with no mechanism attached is a preference.

It follows paths, not pages

Auditing a product screen by screen produces a list roughly as long as the product, ordered by nothing. The useful unit is the path: a whole attempt to do one thing, from intent to outcome.

Three paths carry most of the value:

1. 01The first run. Everything before the product has any of your data in it. This is the state the team sees least and new users see first, and it is where the gap between "demo" and "product" is widest.
2. 02The core task. The thing the product is for, done the way a frequent user does it — including the parts they have learned to work around. Workarounds are findings.
3. 03The recovery path. What happens after something goes wrong: a failed payment, a wrong entry, a thing deleted. Products are usually designed for success and abandoned at the point of failure, which is exactly where trust is decided.

What it is actually looking at

Moments of commitment

Every point where someone gives something up — money, data, time, the ability to undo. These deserve disproportionate attention because hesitation here is expensive and the interface usually treats them like any other step.

The states nobody drew

Empty, loading, partial, error, too much, stale. These are where a product stops feeling considered, and they are invisible in a design file. There is more on this in what production-ready actually means.

Vocabulary

Whether the product uses one word per concept, and whether those words are the user's or the database's. Two names for the same thing is a structural fault wearing a copy-editing costume.

Dead ends

Screens with no next step, searches with no results and no suggestion, permissions that deny without saying who can grant them. Every dead end is a place where the only remaining action is leaving.

The ordering is the deliverable

An audit that produces eighty findings has produced a backlog, and a backlog is not advice. The work that makes it useful is ranking — and ranking requires a stated axis, because "severity" means nothing on its own.

A defensible ordering separates two things that look similar on a list:

• Structural — the product is organised wrongly for what people are trying to do. Expensive to fix, and fixing anything else first means doing that work twice.
• Local — a specific screen, state or control is wrong. Cheap, independent, and safe to fix in any order.

Mixing them is what produces the audit that gets filed: a team reads two structural findings, estimates them, and stops reading. Separated, the local list can be worked through immediately while the structural question gets the conversation it needs.

What an audit cannot tell you

This is the part usually left out, and leaving it out is why audits get oversold.

• How much any of it is worth. An audit is an expert reading of a product, not a measurement. Anyone attaching a percentage to a finding without a measurement design behind it is decorating.
• Which fix to do first for your business. It can order findings by user cost; it cannot know your roadmap, your contractual obligations or what your team can ship this quarter.
• What users think. Unless someone watched users, an audit is a reasoned prediction about behaviour. That is genuinely useful and it is not research, and the two should never be presented in the same voice.

Running one on your own product

Most of the value does not require anyone external. It requires looking at the product as something you have never seen before, which is the part that is hard rather than expensive.

1. 01Make a genuinely new account and do the core task without touching anything you built. Write down every moment you hesitate — hesitation is the signal, before you rationalise it away.
2. 02Do the same thing on a phone, on a slow connection.
3. 03Break something on purpose: wrong card, wrong file, no permission. Read what the product says back as though you did not know the cause.
4. 04Write down every word the product uses for its main objects. If a concept has two names, that is the finding.
5. 05Sort what you have into structural and local before you share it with anyone.

If you have run that and want a second reading of what you found, tell us what you are building.