A real UX audit report has six parts: a scope page, the method used, and findings with evidence. Then a severity score on every finding, a recommended fix for each one, and a prioritized backlog the team works from. If a document calling itself an audit is missing the backlog, it is a list of opinions, not a deliverable.
Most audit examples online describe the document rather than show it, or crop screenshots from unrelated client work. Almost none apply the severity rubric to real findings, which is the part that turns observations into a plan.
It is the output of the process described in the complete UX audit guide. This post walks a full report end to end, using an anonymized composite of a B2B SaaS signup and onboarding flow, the way an agency presents work still under NDA.
| Section | What it answers | Typical length | |---|---|---| | Scope | What was and was not tested | Half a page | | Method | How the review was done | A few sentences | | Findings | What is broken, where, and why | Bulk of the doc | | Severity scores | How bad, and how urgent | One line per finding | | Recommended fixes | What to build instead | One paragraph per finding | | Prioritized backlog | What ships first | One table |
The scope page: the part everyone skips
A real audit starts with scope, not findings. A finding only means something once you know what the review did and did not cover.
A proper scope page states, in plain language:
- Which flow is in scope. In this example: signup through the end of first run onboarding, five screens.
- Which flows are explicitly out of scope: billing, team invites, the admin console.
- Devices and browsers tested: desktop Chrome and Safari, plus one mobile width.
- States covered: empty, loading, error, and success, not just the happy path. The UX audit checklist is the fixed list every state gets walked against.
- What was not tested, and why: no live usability sessions this pass, no analytics review because tracking was not in place yet.
That last line matters more than it looks. An audit that does not state its limits is a sales document dressed up as a deliverable. It reads impressively but leaves you unable to tell what was actually checked.
The severity rubric, and actually applying it
Every audit template says to score findings by severity. Almost none show the scoring. Here is the rubric, applied for real two sections down.
| Severity | Definition | Test to apply | Fix window | |---|---|---|---| | Critical | Blocks the task entirely, or loses data | Can any user complete the task at all? | Immediately | | High | Task completes, but users drop off or misread it | Would a first time user recover without help? | Next sprint | | Medium | Adds friction, no drop off | Does it slow the user without stopping them? | Next planning cycle | | Low | Polish and consistency | Would fixing it change any user's outcome? | Backlog, no deadline |
Severity alone does not set shipping order. A second axis does: reach crossed with effort. A High finding that needs a quarter of engineering can ship after a Medium that takes an hour, because the quick fix removes real friction today.
A fast check on any severity score: read its justification out loud without the word "critical" in it. If the sentence still sounds urgent, the score is right. If it needs the label to feel serious, downgrade it.
Five findings, in full
This is the anonymized composite: a B2B SaaS signup screen and the first run onboarding sequence that follows it. It is the kind of flow the B2B design agencies worth hiring get called in to fix. Client details are stripped, but every pattern below turns up on live products, repeatedly.
Worth saying upfront: severity here is scored against the primary sighted path, and on that path this pass found nothing Critical. On that path, nobody gets fully stuck and nobody loses data. That is a good result, not a gap in the review, and it is the kind of outcome a rubric that scores everything Critical could never produce. Finding 5 is where that scoring boundary gets uncomfortable, and I say so there rather than hide it.
Finding 1: The SSO button shifts the whole form when it loads
Where: Signup screen, first load.
What happens: Email and password fields render first. A third party single sign on button loads a second later and pushes the form down 40 pixels. Users who click fast land on the wrong control.
Heuristic broken: Error prevention. Design the mistake out rather than rely on careful timing.
Severity: Medium. No task is blocked, but everyone on a slow connection hits it, and a misclick costs a second attempt.
Fix: Reserve a fixed height container for the button before it loads, the way you would for an image.
Finding 2: Password rules only appear after a failed attempt
Where: Signup screen, password field.
What happens: The field accepts input with no visible requirements. Only after a failed submit do the rules appear, as red text under the field.
Heuristic broken: Error prevention again, same screen. Requirements belong before the mistake, not after it.
Severity: High. The task completes, but it costs many users an extra failed attempt, and some abandon there.
Fix: Show requirements the moment the field is focused. Replace the helper text "Password" with "8+ characters, 1 number, 1 symbol."
Finding 3: Signing up with an existing email is a dead end
Where: Signup screen, on submit.
What happens: If an email is already in the system, the form shows "An error occurred. Please try again." No mention of the existing account, no link to log in.
Heuristic broken: Help users recognize, diagnose, and recover from errors. The message names neither the problem nor a way out.
Severity: High, not Critical. The person can reach the login page themselves, so the task is not blocked. But few will find that path from a generic error, and this moment becomes a support ticket.
Fix: Replace the message with "An account already exists for this email." Add a "Log in instead" link under it, prefilled with the email they typed.
Finding 4: The onboarding email checkbox is a double negative
Where: Final onboarding screen, before the dashboard.
What happens: A checkbox is checked by default, labeled "Don't send me a copy of my onboarding checklist." To opt in, a user has to uncheck a negatively worded box. Most people read that backwards on a skim.
Heuristic broken: Match between the system and the real world, one of Nielsen's ten usability heuristics. Natural language does not stack two negatives to express one choice.
Severity: Medium. Nobody is blocked, but many end up in the state opposite to what they intended.
Fix: Replace the label with one positive statement, "Email me a copy of my onboarding checklist," unchecked by default.
Finding 5: The required field error is color only
Where: Every required field across signup and onboarding, shared component.
What happens: An empty required field on submit gets a red border. No icon, no error text near the field, no aria-invalid or aria-describedby for assistive tech.
Heuristic broken: Not a Nielsen heuristic, this one. It is WCAG 1.4.1, Use of Color: information cannot rely on color alone.
Severity: High, and this is the score worth arguing about. Sighted users still complete the task. For anyone on a screen reader the error is invisible, which means they are stuck. Scored against a WCAG conformance scope, this is Critical. It reads as High here only because severity in this audit is measured against the primary sighted path. That is a scope decision, not a fact about the product. If accessibility is in scope for you, move this to the top and treat the ranking below as wrong.
Fix: Add an error icon, a one line message, "Company name is required," and aria-invalid="true" with aria-describedby pointing at it. Fix the shared component once and every form inherits it.
A real audit runs to fifteen or thirty findings like these. The next section is what turns that list into work.
The prioritized backlog
Findings get read once. Backlogs get worked from for a quarter.
| Order | Finding | Severity | Reach | Effort | Ticket title | |---|---|---|---|---|---| | 1st | F4, double negative checkbox | Medium | High | Low | Rewrite onboarding opt in as a single positive checkbox | | 2nd | F2, password rules hidden | High | High | Low | Show password requirements inline before first attempt | | 3rd | F5, error is color only | High | Medium | Medium | Add icon, text, and aria-invalid to the shared error component | | 4th | F1, SSO button shifts layout | Medium | High | Medium | Reserve fixed height for the SSO button before it loads | | 5th | F3, existing email is a dead end | High | Medium | High | Add a log in instead path to the duplicate account error |
The order is not a straight severity ranking. F3, the dead end signup error, is High but ships last, because a real fix needs a product decision about account merging, not a copy change. F4, the double negative checkbox, is only Medium, but it is a small change with high reach, so it ships first.
If accessibility is in scope for you, F5 moves to first and everything else shifts down. That is the same ranking logic, run against a different scope.
F4, rewritten as an actual ticket:
Rewrite onboarding opt in as a single positive checkbox
Problem: the checkbox is checked by default and negatively worded. Its state does not map cleanly to user intent.
Acceptance criteria:
- Label reads "Email me a copy of my onboarding checklist," with no negation.
- Checkbox is unchecked by default.
- Checking it triggers exactly one transactional email, not a marketing subscription.
- QA confirms both states trigger the correct email before this ships.
Quick audit vs comprehensive audit
Not every audit is the same size. Here is how the two ends differ.
| Dimension | Quick | Comprehensive | |---|---|---| | Scope | 1 to 2 flows | Full product surface | | Depth | Primary path, spot checked | Every state: empty, loading, error, success | | Accessibility | Automated scan plus manual spot check | Full WCAG pass with screen reader testing | | Deliverable | Findings doc and prioritized backlog | Findings, backlog, research plan, stakeholder workshop | | Turnaround | 3 to 5 days | 3 to 6 weeks |
The example above is the quick end, done properly: two flows, four states, one accessibility pass built in rather than bolted on. That is genuinely enough for most teams running their first audit. Below the quick end sits a bare inspection pass with no backlog attached.
It stops being enough in a regulated industry that needs documented WCAG conformance. It also stops being enough once the product has a dozen flows, multiple roles, and an admin console, because a two flow sample cannot represent that.
What you actually receive
At the quick scope shown here, the deliverable is: a written scope page, five to fifteen findings with evidence and severity, an annotated screenshot per finding, and a prioritized backlog with ticket ready descriptions.
Worth being just as clear about what it is not. It is not usability testing with real users, which is a separate engagement with its own recruiting and script. It is not a research plan. Fixes are described in detail, with real replacement copy where it applies, but they are not redesign mockups. The backlog tells your team what to build. It is not a file to hand off.
An audit that ends in observations is homework. An audit that ends in a ranked backlog is work someone starts on Monday.
If you would rather run this yourself, the 40 checks I walk every flow against are the place to start. If you would rather hand it to someone else, our roundup of product design agencies covers who to call.
And if you want it run on your product, you have now seen the whole thing before paying for it, and what it typically costs is public too, which is the only honest way to sell it. That is the UX audit service.