What a UX Audit Report Looks Like
This page walks through the structure of our audit reports using a made-up online store. Every name, finding and screenshot description here is fictional, so you can judge the format before asking for a quote.
Short answer
An audit report has six parts: a one-page summary, scope and method, ranked findings with evidence, a severity overview, prioritized recommendations and an appendix. The example below uses a fictional outdoor gear store to show each part.
On this page
About this example
Illustrative, fictional site
The store in this example, "Ridgeway Trail Supply", does not exist. We invented it to show how a report is organized and how findings are written. The findings are realistic in kind, because they describe common problems on retail sites, but they are not drawn from any real client or project. No numbers on this page describe real results.
Part 1: One-page summary
The summary is written for people who will read only one page. It names the scope, the three to five most important problems and the changes we recommend first. For the fictional store, the summary might read:
We reviewed the path from the home page to a completed order on desktop and phone. The most serious problem is that shipping costs appear only at the final step, which is likely to cause doubt and abandoned orders. The size guide opens in a new window that is hard to close on phones. Product filters reset when visitors use the back button. We recommend showing an estimated shipping cost on the product page, replacing the size guide window with an in-page panel, and preserving filter choices.
Part 2: Scope and method
This section records exactly what was reviewed, how and when, so anyone reading the report later understands its limits.
| Item | Example entry |
|---|---|
| Pages and flows | Home page, category page, product page, cart, three-step checkout |
| Tasks | Find a waterproof jacket in a given size; buy it as a guest |
| Devices | Desktop browser at 1440 pixels wide; two phones of different sizes |
| Method | Expert review against Nielsen's ten heuristics, WCAG 2.2 AA spot checks, Core Web Vitals review |
| Evidence type | Expert judgment only; no participant sessions in this scope |
| Limits | Findings are predictions to be confirmed with visitors; logged-in account area not reviewed |
The evidence type row matters. Readers should always know whether a finding came from watching participants or from a reviewer's judgment.
Part 3: Findings
Each finding follows the same structure so that teams can scan, compare and import them into a backlog. Here are three fictional examples.
Finding 1: Shipping cost appears only at the last checkout step
- Where
- Checkout, step 3 of 3
- Severity
- Critical
- Principle
- Visibility of system status; error prevention
- Evidence
- Expert review. Shipping is labeled "Calculated at checkout" on the product page and cart.
- Why it matters
- Visitors commit time before learning the full cost, then face a surprise at the point of payment.
- Recommendation
- Show an estimated shipping cost or free shipping threshold on the product page and in the cart, based on a ZIP code the visitor can enter once.
Finding 2: Size guide window is hard to close on phones
- Where
- Product page, size guide link
- Severity
- Serious
- Principle
- User control and freedom; WCAG 2.2 target size
- Evidence
- Expert review on two phones. The close control is about 16 by 16 CSS pixels and sits under the status bar.
- Why it matters
- Visitors checking their size may lose their place or leave the page.
- Recommendation
- Replace the window with an in-page expanding panel, or give the close control a target of at least 24 by 24 CSS pixels with a visible text label.
Finding 3: Filters reset after using the back button
- Where
- Category page
- Severity
- Moderate
- Principle
- Recognition rather than recall
- Evidence
- Expert review on desktop and phone.
- Why it matters
- Visitors comparing products must reapply size, color and price filters each time they return to the list.
- Recommendation
- Store filter choices in the page address so the back button restores them.
Part 4: Severity overview
A short table counts findings by severity and area, so leaders can see the shape of the problem at a glance. In a real report, this table reflects the actual findings. In this fictional example, it would show one critical, one serious and one moderate issue in the purchase path. We use four levels, described on our usability audits page: critical, serious, moderate and minor.
Part 5: Prioritized recommendations
The recommendations section turns findings into an ordered list of changes. Each item names the change, the findings it addresses, an effort estimate agreed with your team and how to check that it worked. For the fictional store, showing shipping costs earlier would rank first: it addresses the most serious problem and needs moderate development effort. Fixing the size guide would rank second, and preserving filters third.
Where a change could reasonably go either way, such as moving reviews higher on the product page, the report suggests checking it with visitors or a controlled test before committing. The recommendations service explains the full format.
Part 6: Appendix
The appendix holds material that supports the findings without cluttering the main report: the full task list, device and browser details, the heuristic checklist with notes, accessibility test notes and links to any recordings. When the scope includes participant sessions, the appendix also summarizes who took part, described by role and experience rather than by name.
Questions about the sample
Is this a real client report?
No. The store, the findings and every detail on this page are fictional. We use a made-up example because we do not publish client work, and we will not present invented results as real.
How long is a real report?
It depends on the scope. A focused audit of one or two flows fits in a short report with a one-page summary at the front; a larger scope runs longer. The summary always stays to one page.
Do reports include screenshots?
Yes. Every finding in a real report includes a screenshot or short recording with the problem area marked. This example describes them in words because the store is fictional.