What goes in a UX audit report

A UX audit report contains a score for orientation, a short prioritised list of the problems costing the most, a set of changes that can ship immediately, and the reasoning behind each one. The reasoning is the part that makes it a report rather than a list of opinions.

Most reports fail in one of two directions: they contain everything found and prioritise nothing, or they contain confident assertions with nothing behind them. Both get read once.

What goes in a UX audit report?

Four things, in this order: a score or overall read so the reader knows where they stand, the three or so problems costing the most, five changes shippable this week, and a note on the copy. Everything else found belongs in the report too — further down, where it does not compete with the things that matter.

The reason for leading with a small number is arithmetic about attention, not about thoroughness. A document with thirty findings gets skimmed, filed and forgotten. Three things a team can hold in their heads get argued about in one meeting and shipped that sprint. Everything you found still goes in — you are choosing what to put at the front, not what to leave out.

A workable structure:

1. The score, with what it means. One number is only useful with a published scale behind it — otherwise it is a mood. How the bands work.
2. Critical blockers. Three, ordered by cost. Each with what you saw, what it costs, and what to change.
3. Quick wins. Five, shippable without a redesign. These exist so the team has something to do on Monday.
4. The copy read. The specific lines that add friction. Usually the cheapest fixes in the document and the most frequently skipped.
5. Everything else. Sorted, not prioritised. This is where the report earns its keep six months later.
6. What was not covered. The screens you could not reach, the things outside the method. Stating the boundary is what makes the rest credible.

How should a finding be written?

Each finding needs three parts: what you observed, why it costs something, and what specifically to change. The test is whether a developer who has never spoken to you can act on it. If a finding needs its author present to be understood, it will not survive being forwarded — and forwarding is how reports actually get implemented.

Here is the same problem written three ways:

❌ Poor visual hierarchy in the hero. Untestable, unactionable, and impossible to disagree with usefully.

⚠️ The hero has too many competing elements. Better — names a mechanism — but “too many” compared to what, and which one would you remove?

✅ Four elements compete for the first click: the primary button, the demo link, the video play control, and the plan selector. A visitor arriving to evaluate has to choose which of four things to do before they have decided whether to do anything. Demote the video and the plan selector below the fold; keep the primary button and the demo link, which serve the two real visitor states.

The third version is longer and it is the only one that gets shipped.

What does a good finding look like in practice?

A good finding is specific enough to be wrong. It names the element, quotes the copy, states the mechanism by which it costs something, and proposes a change concrete enough that two people would build the same thing from it. Vagueness reads as diplomacy and functions as noise.

Some patterns that consistently produce good ones:

• Quote the actual words. “The button says Get started where the next screen asks for a card” is a finding. “CTA is unclear” is not.
• Say who it costs. Different visitors are blocked by different things, and a finding that names the visitor is easier to prioritise.
• Separate what you saw from what you infer. “The form has nine fields” is observation. “Which is why signups drop here” is a hypothesis, and marking it as one is what lets a team check it against data you did not have.
• Note the fix’s size honestly. “Move these two fields to after activation” and “restructure onboarding” are different asks, and pretending otherwise costs you credibility the first time someone scopes it.

How many findings should a report contain?

Lead with about eight — three blockers and five quick wins — and put everything else behind them. That is not a rule about how much to find; it is a rule about how much a team can act on at once. The rest of what you found still belongs in the document, sorted and available.

The instinct to include everything at equal weight comes from wanting the report to look worth what was paid for it. It has the opposite effect: a document where everything is important is one where nothing is, and the reader ends up doing the prioritisation you were hired to do.

What format should it be in?

A PDF or a document, not a deck. It needs to survive being forwarded to someone who was not in the meeting, read on a phone, and pasted into a ticket. Decks optimise for the presentation and lose most of their meaning the moment the presenter is gone.

Two practical requirements that sound minor and are not:

• Copyable text. Screenshots of text mean a developer retypes the recommendation into the ticket, which is where recommendations get mangled.
• A stable structure across reports. If you send more than one, the second should be findable in the same way as the first. Consistency is what lets a team build a habit around the document.

See a complete one

The fastest way to judge any of this is to read a finished report rather than a description of one. Download a full sample report — no email required — and compare it against what you would want to receive.

For the same method applied in public, the teardowns run the whole process on well-known product pages, with the score, the blockers and the reasoning all out in the open where you can disagree with them.

---

If you are writing one yourself, how to conduct a UX audit covers the process that produces the findings this report is made of.