The UX audit that fits on one page

I've read a lot of UX audits in fifteen years. Written a fair few too. The pattern is depressingly consistent: sixty slides, a heatmap or three, a colour-coded severity matrix, and a closing section titled "Recommendations" that everyone agrees with in the meeting and nobody ever opens again.

The audit was thorough. The audit was expensive. The audit changed nothing.

So these days I run audits that fit on one page. Not because the product only has one page of problems, but because a team can only absorb one page of truth at a time. The sixty-slide version spreads attention so thin that the important stuff drowns in the interesting stuff.

The five questions

This is the whole audit. Five questions, answered honestly, in this order:

1. Can a new user reach the core job in one sitting? Not explore. Not browse. Reach the thing your product exists to do. Watch one real person try. If they stall, you've found your first finding and it outranks everything else on this page.
2. Where does support traffic actually cluster? Your support inbox is a free usability lab that runs every day. Pull a month of tickets and group them. The top three clusters are UX findings wearing a disguise.
3. Which flow makes the money, and what's rotting in it? Every product has one flow that pays the bills. It usually gets less design attention than the marketing site. Walk it end to end and write down every moment you hesitated.
4. What are users doing that you never designed for? The workarounds are the roadmap. If people are exporting to a spreadsheet to do something, that something is a feature request written in behaviour instead of words.
5. What can you delete? Every screen you remove is a screen that can no longer confuse anyone. The best finding in most audits is a list of things to switch off.

The owner rule

Here's the part that makes it work. Next to every finding goes a name. Not a team, not a squad, a person. If nobody will own a finding, it comes off the page. Sounds harsh, but an unowned finding was never going to be fixed anyway. At least now the page tells the truth.

One page. Five questions. Names attached. You can run it yourself before you ever pay someone like me to do it, and honestly, you should.

FAQ

What should a UX audit include?

Five things: whether a new user can reach the core job, where support tickets cluster, the state of the revenue flow, what users are working around, and what can be deleted. Each finding needs a named owner, or it gets cut.

How long should a UX audit take?

The lightweight version takes a day or two, not weeks. Depth comes later, on the two or three findings that survive contact with the one-page format. Auditing everything at once mostly produces a document nobody reads.

Can I run a UX audit myself?

Yes. Watch one new user attempt the core task, read a month of support tickets, and walk your money flow end to end. That gets you most of the value. Bring in an outside pair of eyes when you want the politics-free version of the findings.