Skip to content

UX audit report example

Below is a complete UX audit report — score, findings, evidence and a prioritised fix plan — rendered on this page rather than shown as a screenshot of a PDF. It also publishes the part every other example leaves out: the arithmetic that produced the score, and the limits that stop it claiming more than it measured.

A UX audit report should contain four things: a score with the constraint that bound it, findings each carrying the evidence they were raised from, a prioritised plan with acceptance criteria, and an explicit list of what was not measured. The example below has all four. ProUXAudit scores a page from 18 to 96 — never 0 and never 100 — across 20 coverage checks and 8 weighted score dimensions, with 5 severity levels and 9 separate ceilings, of which the lowest always wins.

About this example. The subject is the homepage of a fictional B2B expense-tracking SaaS, hosted on example.com — the domain reserved for documentation. No real company is being graded here. The findings are written in the shape the rule pack emits; everything derived from them on this page — the plan, the priority scores, the mobile, accessibility and performance scores, the badge verdict, the score band — is computed by the same functions that run inside a real report.

Example report

example.com

https://www.example.com/

60

out of 100 · Fair

Six competing calls to action above the fold, proof placed after the first ask, and a title that names a different product from the H1. None of it is a rewrite; all of it is in the way.

Findings

3

Worst severity

High

Bound by

Raw deductions

How this score was produced

Starting score
100
Findings: 1 high (18) + 1 medium (10) + 1 low (6)
−34
Opportunities: 1 medium
−6
Raw deductions
60
Severity ceiling — worst open finding is high
66
Reported score — the lower of the two
60

Nine constraint sources are evaluated on every run — raw deductions, severity, coverage, uncertainty, confidence, breadth, clean result, evidence density and page intent. The lowest wins, and the report names which one it was. Here the deductions bind before any ceiling does.

Findings

  1. high

    Six links compete for the primary action above the fold

    Above the fold the page offers Start free trial, Book a demo, Watch the video, Read the docs, Pricing and Sign in at the same visual weight. Nothing marks one of them as the action the page wants.

    A visitor who has decided to act has to choose between six routes before they can take one. Competing calls to action are the most common reason a page with good copy still converts badly.

    Above-fold interactive elements
    6
    Elements at the same weight as the primary CTA
    5
    Primary action
    not distinguishable by size, colour or position

    Fix: Keep one primary action above the fold and demote the rest to text links or move them below it.

  2. medium

    No proof appears before the first request for an email address

    The trial form sits above the fold. The first customer logo, review score or named quote appears after it, so the visitor is asked to commit before anything on the page has earned it.

    Proof placed after the ask does not support the ask. This is a placement problem, not a missing-content problem — the page has proof, it is just in the wrong order.

    First trust signal position
    below the trial form
    Trust signals on the page
    3 customer logos, 1 review score

    Fix: Move one concrete proof element above the trial form.

  3. low

    The page title and the H1 describe two different products

    The title tag reads "Expense management for finance teams" while the H1 reads "Close your books faster". Both are reasonable; together they make a search visitor check whether they landed on the right page.

    A visitor arriving from search compares the result they clicked with the heading they land on. When the two do not match they re-read instead of continuing.

    Title tag
    Expense management for finance teams
    H1
    Close your books faster

    Fix: Make the H1 carry the same subject as the title tag.

Prioritised plan

Produced by the same planner a real report uses. Priority is severity×40 + impact×35 − effort×15 + evidence confidence×10, the plan is capped at eight tasks, and every task carries acceptance criteria so the fix can be checked rather than believed.

  1. Six links compete for the primary action above the fold

    priority 72

    high severity finding with 3 evidence point(s).

    KPI: conversionSeverity: highEffort: 2hExpected impact: 0.95
    • Keep Start free trial as the only button above the fold. Render Book a demo as a text link beneath it and move the remaining four into the navigation.
    • Evidence for "Six links compete for the primary action above the fold" is no longer present in the next audit.
    • The changed section is verified on desktop and mobile viewport widths.
  2. No proof appears before the first request for an email address

    priority 62

    medium severity finding with 2 evidence point(s).

    KPI: trustSeverity: mediumEffort: 2hExpected impact: 0.95
    • Move the review score and one named customer quote directly above the trial form.
    • Evidence for "No proof appears before the first request for an email address" is no longer present in the next audit.
    • The changed section is verified on desktop and mobile viewport widths.
  3. Break the feature paragraph into scannable rows

    priority 43

    medium priority recommendation with 2 evidence point(s).

    KPI: conversionSeverity: mediumEffort: 6hExpected impact: 0.55
    • Split the 140-word feature paragraph into four labelled rows so the page can be read by scanning.
    • "Break the feature paragraph into scannable rows" is implemented and visible in the next audit capture.
    • The changed section is verified on desktop and mobile viewport widths.
  4. The page title and the H1 describe two different products

    priority 31

    low severity finding with 2 evidence point(s).

    KPI: conversionSeverity: lowEffort: 2hExpected impact: 0.35
    • Rewrite the H1 so it names expense management, for example "Expense management that closes your books faster".
    • Evidence for "The page title and the H1 describe two different products" is no longer present in the next audit.
    • The changed section is verified on desktop and mobile viewport widths.

Measured in the browser

The same browser session that captured the page measures three more things. Every point taken off names the rule and the threshold behind it, so a number you disagree with is a line you can argue with.

Mobile

81 / 100 · badge needs 85

The page is re-laid out at 375px wide. Points come off for a missing viewport tag, sideways scrolling, tap targets under 24×24px (the WCAG 2.2 SC 2.5.8 size; its spacing and inline-link exceptions are not applied, so a flag means "review", not "fails WCAG") and body text under 16px.

  • tap_targets_below_minimum — 9 of 42 interactive elements are under 24x24px (WCAG 2.2 SC 2.5.8).−9
  • base_font_below_minimum — Body text computes to 15px, under the 16px mobile reading minimum.−10

Accessibility

73 / 100 · badge needs 85

axe-core 4.10.2, pinned so a library upgrade cannot move a score without a commit. Points come off per violated rule, weighted by impact, with the element count kept as evidence.

  • image-alt — critical: Images must have alternative text (2 elements).−12
  • color-contrast — serious: Elements must meet minimum color contrast ratio thresholds (11 elements).−6
  • link-name — serious: Links must have discernible text (3 elements).−6
  • region — moderate: All page content should be contained by landmarks (14 elements).−3

Performance

85 / 100 · badge needs 80

Largest Contentful Paint, Cumulative Layout Shift and time to first byte, read during the page load against the published “good” boundaries (2500ms, 0.1, 800ms).

  • lcp_needs_improvement — Largest Contentful Paint 3140ms, over the 2500ms good boundary.−15

If the browser pass does not run or fails on an audit, all three read “not measured” — never a zero, because a zero would say the page failed a test it was never given.

Badge verdict

Status: not_eligible

  • overall_score_below_90
  • mobile_score_below_85
  • accessibility_score_below_85

A badge needs a score of 90 or more, zero critical findings, at most one high finding, and mobile 85, accessibility 85 and performance 80 or better. A metric the browser pass could not measure blocks it too, and the reason then reads not_measured rather than below — untested is reported as untested, never as a zero.

What a UX audit report should contain

If you are writing one yourself or judging one you have been sent, these four are the test. A report missing the fourth is the one to be careful with.

  1. 1

    The score, and what bound it

    One number, plus the constraint that produced it. A report that shows a score without showing what capped it is asking to be trusted rather than checked.

  2. 2

    Findings, worst first

    Each one carries the evidence it was raised from. A finding with no evidence line is a claim, not a finding.

  3. 3

    A prioritised plan, not a list of problems

    Every finding becomes a task with an effort estimate, an expected impact, a priority score and acceptance criteria you can check afterwards.

  4. 4

    What was not measured

    Named explicitly, with the reason. A metric the run could not measure is reported as not measured — never as a zero.

The severity scale, with its actual weights

Five levels. A finding costs more than an opportunity at the same level, because a finding is something observed and an opportunity is something suggested. The worst open finding also sets a ceiling the score cannot pass, however clean everything else is.

SeverityFindingOpportunityScore ceiling
Critical−28−1442
High−18−1066
Medium−10−680
Low−6−3—
Informational−3−1—

A page with nothing open at all, fully justified, tops out at 93. The remaining seven points are what the method cannot see from a captured document, and they are not awarded.

What this report does not measure

Every audit report is a claim about a website, and a claim you cannot check is worth less than a smaller one you can. No run measures these, however the capture went, so nothing on this page scores them:

And when the browser pass itself fails, mobile, accessibility and performance are reported as not measured rather than as zero, for a specific reason: publishing a zero for a test that never ran tells every reader — including the AI agents that read the public report — that the page failed something it was never given.

Two more limits worth knowing. A page in a language the vocabulary cannot read is not capped on signals it could not assess — a withheld cap is published as withheld rather than silently skipped. And a weak signal that no rule could turn into something you can act on is reported as unconfirmed rather than charged as a hidden penalty, so the score and the findings always add up.

Run this on your own page

The example above is fictional on purpose. The report you get on your own URL is not — same engine, same ceilings, same list of what it did not measure. The free plan runs 3 audits a month.

Want it done for you? The Pro UX Audit is €249, delivered in 3 business days.