UX Audit Template: Copy-Paste Sections and Examples

What should a UX audit template include?

A useful UX audit template connects each problem to a user task, records the evidence, and defines how to check the fix. A screenshot with “this looks confusing” is not enough to guide development.

Use the template below for a marketing site, SaaS product, online store, or service business. Copy it into your shared document or project tracker, then remove sections that do not apply.

The core record is simple: task → observed problem → consequence → severity → fix → acceptance test. That structure keeps an audit focused on usability rather than personal design preferences.

If you are still deciding what belongs in the review, this plain-English guide to UX audits explains the scope. Here, the goal is a document someone can act on.

How do you define the scope before reviewing pages?

Start with a journey, not a list of URLs. “Review the homepage” is vague. “Help a first-time visitor choose a plan and start a trial” gives you a task to test.

Choose one primary journey for the first pass. Include the entry page, decision points, form or checkout, and confirmation state. Note branches such as invalid input, unavailable products, and forgotten passwords.

Record the conditions too. A layout may work with a mouse on a wide screen but fail with a keyboard or an open mobile keyboard. Testing only the default state leaves those problems invisible.

Copy-paste audit brief

Keep user and business goals separate. A visitor may want to understand the cancellation terms before subscribing. Hiding those terms could push the business action while making the user’s decision harder.

What sections can you copy into your audit document?

Paste these sections below the brief. The summary is first in the finished document, but write it last, once you know which findings matter.

1. Decision summary

Avoid broad statements such as “the UX is poor.” State the condition: “The signup journey works on desktop, but the submit control is inaccessible at the tested mobile width.”

2. Journey review

3. Coverage checklist

Use pass, issue, not tested, or not applicable for each area. “Not tested” is important: a blank cell should not imply that something works.

This is a usability review, not proof of accessibility compliance. Record the checks you actually performed and flag specialist testing where needed.

For more detailed checks by page type, use the CRO audit checklist alongside this document. Keep only checks relevant to your chosen journey.

4. Individual finding record

Duplicate this table for every distinct problem. Split findings when they have different causes, owners, or acceptance tests.

How should you rank UX issues by severity?

Use severity to describe the consequence for the affected user. Keep reach, confidence, and implementation effort separate. A problem does not become harmless because it is expensive to fix.

The following is a working scale for this template, not an industry benchmark.

Rate the observed behavior, not the category. A typo in supporting text may be minor; a typo that changes a payment amount is not.

For confidence, use high when you can reproduce the behavior and directly establish its consequence. Use medium when the issue is reproducible but its broader impact is uncertain. Use low for a plausible concern that needs testing.

Do not invent reach. Write “affects the tested mobile layout; traffic share unknown” unless you have supporting analytics. Avoid weighted scores that turn guesses into precise-looking rankings.

What do well-written UX audit findings look like?

These are illustrative examples, not findings from a real website. Their severity assumes the conditions described; your site may justify a different rating.

Example: Keyboard focus is trapped in a signup dialog

Finding: UX-001. After opening signup, keyboard focus cycles inside the dialog. Its close icon cannot receive focus, Escape does not dismiss it, and the pricing details behind it remain unavailable.

Consequence and severity: A keyboard-only visitor cannot return to pricing without reloading and losing progress. S3 because a disruptive workaround exists. The reproduction steps and focus sequence would be the evidence.

Recommended change: Provide a keyboard-operable close control, support expected dismissal behavior, and return focus to the control that opened the dialog.

Acceptance test: Open the dialog with the keyboard, dismiss it without a pointer, confirm focus returns to the trigger, and continue navigating the page.

Example: Validation clears unrelated form fields

Finding: UX-002. Submitting the enquiry form with an invalid email shows an error but clears the valid name and message fields.

Consequence and severity: The visitor must re-enter unrelated information to recover. S2 in this example; loss of substantial work could justify a higher rating.

Recommended change: Preserve valid values and associate a specific correction message with the email field.

Acceptance test: Submit an invalid email alongside valid text elsewhere. Confirm that other values remain, the error is available to assistive technology, and correcting the email allows submission.

Example: A plan card omits its billing commitment

Finding: UX-003. A plan card displays a monthly equivalent, but the annual charge is disclosed only after account creation.

Consequence and severity: The visitor must provide information before understanding the commitment. S2 for this example, pending review of the full payment flow. Do not claim this causes abandonment without evidence.

Recommended change: Show the billing cadence and total charge beside the displayed price and primary action.

Acceptance test: A visitor can identify the amount charged and billing interval before starting signup, including on mobile.

How do you turn the audit into a fix queue?

Start with confirmed blockers and serious harm, then consider reach and importance to the primary journey. Within comparable issues, effort can help determine what ships first. Keep uncertain concerns in a validation queue rather than treating them as confirmed defects.

Assign one accountable owner per finding. “Design and engineering” describes collaborators, not who moves the issue forward.

An automated review can help identify candidates. You can run a free UX audit with SiteScoper to get an initial list, then verify relevant findings manually. Automated output is not evidence that a visitor experienced a problem.

How do you verify fixes and keep the audit useful?

Retest each fix using the original reproduction steps and conditions. Check the adjacent behavior too: a repaired mobile layout might introduce an overlap at another width, or a new error message might fail to reach screen-reader users.

Record the retest date, reviewer, result, and remaining limitations. Move an issue to verified only when its acceptance test passes, not when the code ships.

Where analytics are available, monitor the relevant journey afterward. An improvement in completion can support your assessment, but a before-and-after change alone does not prove causation.

Reuse this UX audit template when a release changes navigation, pricing, forms, or another important journey. The deliverable is a traceable record of what failed, why it mattered, what changed, and whether the task now works.