How to conduct a UX audit that actually changes the product

There is a specific failure mode for UX audits. The work is competent, the findings are accurate, the deck is well made. It gets presented, everyone agrees it is useful, and nothing in the product changes. Six months later someone commissions another one.

The cause is almost always decided at the framing stage, before any evaluation happens.

An audit commissioned to 'review the user experience' will produce a list of problems with nowhere to go. An audit commissioned to answer a decision: should we rebuild or repair, why has onboarding conversion dropped, can this product support the enterprise segment: produces findings that are automatically relevant to something someone is about to do.

Before starting, write down the two or three questions the audit must answer and who will act on the answers. If you cannot name the person, the audit has no destination.

Gather evidence in the right order

Behaviour first, opinion last. Opinions are cheap and contaminate how you read everything afterwards.

1. Analytics: where do people go, where do they stop, which paths are real versus assumed
2. Session replay on the highest-traffic and highest-value flows
3. Support tickets and sales objections, clustered across at least twelve months
4. Search queries inside the product, the clearest statement of unmet need you will find
5. Stakeholder interviews, to understand constraints and history
6. Task-based user sessions, to see failure directly

Heuristic evaluation has a reputation problem because it is often done as unstructured opinion. Done properly it is a repeatable pass with a fixed checklist, applied by more than one evaluator, with findings recorded against specific screens and tasks.

Run accessibility as part of the same pass, not as a separate exercise. WCAG 2.2 AA failures are objective findings and they frequently overlap with usability problems: poor focus handling and unlabelled controls hurt everybody, not only assistive technology users.

This is where most audits lose their power. A flat list of forty findings invites cherry-picking. A scored list forces a conversation about consequence.

Attach evidence to every rating. A severity score without a traceable source is an opinion with a number next to it, and it will be argued with accordingly.

Forty findings are usually six problems. Clustering is the analytical step that makes an audit actionable, and it is the step most often skipped because it is harder than listing.

Look for the cause beneath the symptom. Six navigation findings may all be one information architecture decision. Four inconsistency findings may be one missing governance model. Two teams owning two halves of a journey is an organisational finding, and it should be written as one.

A finding without a recommendation is a complaint. A recommendation without an effort estimate is a wish. Sequence the plan into three bands so the team can start on Monday.

• Immediate. Content, labelling, missing states and obvious accessibility failures. Weeks of work, no rebuild
• Structural. Navigation, information architecture and core workflow. A quarter or two
• Strategic. Platform, service design and organisational ownership. Planned, funded and sponsored

The single highest-leverage change to how audits land: do not present findings. Run a working session where the team interrogates the evidence, challenges the severity ratings and argues about sequencing.

A team that has argued with the findings owns them. A team that has been presented to has received a document. Presentation produces politeness; argument produces commitment.

The audit's real output is not the report. It is an account of the problem that the whole leadership team can act on without reopening the debate.