# How to prioritize UX audit findings

Rate every finding for severity, effort and confidence, and give it one owner. Send critical issues and WCAG failures straight to the top. Order the rest with a written rule, such as severity times confidence divided by effort. Finish each item with acceptance criteria a tester can check.

## Key takeaways

- Severity describes the problem; priority describes the work. Rate them separately and write the rule that connects them.
- Merge findings that share a root cause before you score, and keep both IDs on the merged item.
- Use gates: critical issues and WCAG 2.2 AA failures go to Now regardless of score.
- Low-confidence findings go to a Validate-first list with the cheapest test, not into the build queue.
- Close each item with evidence, ideally the same script that found the problem.

## Why is severity not the same as priority?

Severity describes the problem. Priority describes what your team does next. A critical problem that needs a two-month rebuild may ship after five minor fixes that take an afternoon each. That is a sound decision, as long as it is written down.

An audit that hands over a list sorted by severity alone leaves the hard part to you. A useful audit adds three more ratings to every finding: effort, confidence and owner. Then it applies a rule that anyone on the team can repeat. Our [UX audit service](/services/ux-audit/) ends with a backlog built this way, and this guide shows the rule in full.

If you have not read it yet, the companion guide on [how a UX audit works](/blog/ux-audit-guide/) explains where the findings come from. The worked example below uses the 14 findings from the sample audit in that guide.

## Which severity scale should you use?

Use a scale with written definitions, and print the definitions in the report. The scale matters less than the definitions. Two reviewers should give the same finding the same rating.

Nielsen’s scale runs from 0 to 4. A 0 means “not a usability problem”, 1 is cosmetic, 2 is minor, 3 is major and 4 is a usability catastrophe. He rates each problem on three factors: frequency, impact and persistence. Persistence asks whether users keep hitting the problem after they know about it.

We use three levels, because teams argue less about three than about five. Each level is tied to what happens to the user’s task.

| Severity | Definition | Points |

| Critical | Blocks the task or loses the user’s data, with no workaround a typical user would find.  | 4 |

| Major | The task can be finished, but many users will fail, give up or need help. Includes WCAG 2.2 AA failures on the flow.  | 3 |

| Minor | Slows people down, confuses some of them or weakens trust, but the task still succeeds.  | 2 |

| Cosmetic | Visual or wording polish with no measurable effect on the task. Fix it when the file is open anyway.  | 1 |

Severity definitions from the W3Experts audit template, version 1.1.

## Tip

Rate severity from the user’s side, before you think about the fix. If you rate while thinking “that’s easy”, easy problems drift upward and hard ones drift down.

## How do you add effort and confidence?

### Who should estimate effort?

The people who will do the work. An auditor can suggest a size, but the front-end lead knows the codebase. Use T-shirt sizes, not hours, because the estimate is made before anyone has opened the code.

- **S**: under half a day, including the check.

- **M**: one to three days.

- **L**: more than three days, or it needs design work first.

### What does confidence mean for a finding?

Confidence says how the finding was produced. It stops a reviewer’s hunch from outranking a measured failure.

- **High**: reproduced with a script, measured in analytics or seen in several test sessions.

- **Medium**: observed by the reviewer and backed by a heuristic, but not reproduced with users.

- **Low**: predicted. It needs data or a test before anyone builds a fix.

Low-confidence findings are not worthless. They go into a separate “validate first” list, with the cheapest way to test them.

## Who owns each finding?

Every row gets one owner role: front-end, design, content or product. One role, not two. When a fix needs design and code, the owner is whoever must start, and the ticket links the second task.

Name roles in the audit and people in your tracker. Audits outlive team changes, and a role still makes sense a year later.

## How do you write acceptance criteria for a UX fix?

An acceptance criterion is a check that proves the fix works. It names the place, the action and the result, and anyone on the team can run it. “Improve the error messages” is a wish. This is a criterion:

```
Given step 2 of /start-a-project/ at 390 px and 1440 px When I press Continue with an invalid URL and a 9-character problem Then both errors show at once, in site wording, above the first field And the hint "At least 20 characters" is visible before I type
```

Three rules help:

- State the widths, browsers or roles the check covers.

- Prefer a check a script can repeat. Our sample audit scripts double as regression tests.

- Keep outcome metrics separate. “Brief completion rises” is a goal to measure later, not a criterion a developer can pass.

## How do you turn the ledger into a backlog?

Use the same five steps on every audit, so the order is never a matter of who argues loudest.

## Steps

- ### Merge findings that share a cause

Two symptoms with one root cause become one backlog item. Keep both finding IDs on it, so the evidence stays traceable.

- ### Apply the gates

Critical findings and WCAG 2.2 AA failures on the audited flow go to Now, whatever their score. These are the floor, not a trade-off.

- ### Score the rest

Score equals severity points times confidence, divided by effort. Confidence counts 1.0 for high, 0.8 for medium and 0.5 for low. Effort divides by 1 for S, 2 for M and 3 for L.

- ### Bucket by score

A score of 3 or more goes to Now, 1.5 to 2.9 to Next, and below 1.5 to Later. Any Low-confidence item goes to Validate first instead.

- ### Export and assign

Export the backlog as CSV with the acceptance criteria in their own column. Import it into Jira or Linear and assign each item to a person.

The formula is deliberately simple. You can check any rank with mental arithmetic, and a stakeholder who disagrees has to argue with a rating, not with the auditor.

## Worked example: how did we prioritize our own audit findings?

## Warning

This example uses the sample audit of w3experts.com from November 11, 2026. It is our own site, not client work. Effort sizes are our estimates before code review.

### Which findings did we merge?

SA-01 and SA-04 looked like two problems. After a failed Send, the field with the error scrolls out of view. After Continue on a phone, the step heading lands above the window. Both come from the same place: the form scrolls after it moves focus, instead of scrolling to the focused element. We merged them into backlog item B-01, which fixes both with one change.

### What did the scored ledger look like?

| Item | Finding | Severity | Confidence | Effort | Score | Bucket |

| SA-02 | Sticky bar wipes the brief on phones.  | Critical | High | S | 4.0 | Now, gate.  |

| B-01 | Focused field hidden after Send or Continue (SA-01, SA-04).  | Major | High | M | 1.5 | Now, WCAG 2.4.11 gate.  |

| SA-05 | Privacy link contrast 1.53 to 1.  | Major | High | S | 3.0 | Now, WCAG 1.4.3 gate.  |

| SA-07 | Scope output contradicts the service page timeline.  | Major | High | S | 3.0 | Now.  |

| SA-09 | Copy implies past client audits.  | Major | High | S | 3.0 | Now.  |

| SA-06 | Summary shows internal values.  | Minor | High | S | 2.0 | Next.  |

| SA-08 | Skip link is the second Tab stop.  | Minor | High | S | 2.0 | Next.  |

| SA-10 | Breadcrumb points to the wrong page.  | Minor | High | S | 2.0 | Next.  |

| SA-13 | “Scope B” shown before any answer without JavaScript.  | Minor | High | S | 2.0 | Next.  |

| SA-11 | Process cards look clickable.  | Minor | Medium | S | 1.6 | Next.  |

| SA-03 | Hidden 20-character minimum, one error at a time.  | Major | High | M | 1.5 | Next.  |

| SA-12 | Service form uses browser bubbles only.  | Minor | Medium | M | 0.8 | Later.  |

| SA-14 | First field below the first screen.  | Minor | Low | M | 0.5 | Validate first.  |

Sample backlog, 13 items from 14 findings. Score equals points times confidence divided by effort.

Three results are worth a closer look.

- **B-01 scores only 1.5 but goes to Now.** The gate catches it. Without gates, a cheap minor fix would outrank an accessibility failure on the main lead form.

- **SA-03 is Major but lands at the bottom of Next.** It needs custom messages and an error summary, so it is an M. We added a house rule: no Major item may fall below Next.

- **SA-14 waits for data.** We predicted that a tall hero pushes the form below the first screen. Before redesigning the page, we will check scroll depth and form starts once the site has traffic.

### What are the acceptance criteria for the Now bucket?

| Item | Owner | Acceptance criteria |

| SA-02 | Front-end | At 390 px on /start-a-project/, no sticky “Start a project” bar renders. Entered answers survive every visible control on the page.  |

| B-01 | Front-end | Check at 390 px and 1440 px, 1.2 seconds after Continue or a failed Send. The focused element sits fully below the 65 px header and inside the window.  |

| SA-05 | Design | The privacy link reaches at least 4.5 to 1 against its background. axe-core reports zero contrast violations on /services/ux-audit/ at both widths.  |

| SA-07 | Content | The planning scope for “A UX audit” states 5-10 business days, as the service page does, and lists no migration step.  |

| SA-09 | Content | The sample ledger is introduced as an illustration. No sentence on the page claims past client audits.  |

Each criterion can be checked by re-running the audit scripts or by reading the page.

This is how two of those rows look in the backlog CSV, ready to import:

```
id,flow,finding,severity,effort,confidence,owner,bucket,acceptance_criteria SA-02,Brief (all steps; phone),"Sticky Start a project bar reloads the page and erases answers",Critical,S,High,Front-end,Now,"At 390 px no sticky bar renders on /start-a-project/; answers survive every visible control" B-01,Brief (step change and failed Send),"Focused field scrolls out of view or under the sticky header (SA-01, SA-04)",Major,M,High,Front-end,Now,"At 390 and 1440 px the focused element sits below the 65 px header and inside the window 1.2 s after the action"
```

## What we did next

The backlog only pays off if the Now items ship. We fixed 12 of the 14 findings in our own site on November 11, 2026. We also added automated browser tests for the sticky bar, the focus position after Continue and Send, and the form contrast. Two stay open: SA-09 needs a content decision, and SA-14 needs analytics data after launch. The ledger shows the site as we audited it.

## What about RICE, ICE and impact-effort matrices?

RICE scores reach, impact, confidence and effort. It works well for product ideas when you know how many people each change touches. Audit findings often lack that number, especially on a new site or a prototype. Inventing reach to fill the formula hides a guess inside a precise-looking score.

An impact-effort matrix is a good meeting tool. Put the scored items on a two-by-two grid and let the team challenge the outliers. Use it to discuss the ranking, not to replace the written rule.

When analytics are available, add reach as a tie-breaker inside a bucket. Two Next items with the same score? The one on the higher-traffic step goes first.

## How do you keep the backlog honest after the audit?

- **Close items with evidence.** Attach the re-run script output or a new screenshot to the ticket. “Fixed” without proof reopens the debate later.

- **Re-rate after each release.** A fix can lower the severity of a related item. A new feature can raise one.

- **Move Validate-first items when data arrives.** Promote them with a confidence change, or close them as “not a problem”.

- **Measure goals separately.** Track the outcome you care about, such as completed briefs, against the baseline from the audit. Do not credit a single fix with a change you did not isolate.

Our free [UX audit report and backlog template](/resources/ux-audit-report-template/) includes the severity table, the scoring rule and this sample backlog as a worked page. For SaaS products, the [SaaS UX audit checklist](/resources/saas-ux-audit-checklist/) helps you produce the findings in the first place.

## Download

UX audit report and prioritized-backlog template, version 1.1, with severity definitions, the scoring rule and this worked example.

[Download the template (PDF)](/downloads/ux-audit-report-template.pdf)

## Download

The sample backlog as CSV, with every column from the tables above.

[Download the backlog (CSV)](/downloads/ux-audit-backlog-template.csv)

## Download

SaaS UX audit checklist, version 1.1: testable checks for sign-up, onboarding, settings, billing and WCAG 2.2 AA.

[Download the checklist (PDF)](/downloads/saas-ux-audit-checklist.pdf)

Does the backlog point at deeper problems? If the onboarding model needs rethinking, [UI/UX design](/services/ui-ux-design/) or [SaaS product design](/services/saas-product-design/) can take it from there.

## Limits: what this guide does not cover

- The worked example has no analytics, because the site was not live. Reach played no part in the ranking.

- Effort sizes are estimates before code review. They are not measured delivery times.

- The scoring rule is ours. It is a convention for ordering work, not a research finding, and other weights are equally defensible.

- This guide does not cover roadmap planning across many audits, or how to price the fixes.

## Want a backlog your team can ship?

Our UX audits end with a scored, owned backlog and acceptance criteria for every item.

[Scope a UX audit](/services/ux-audit/)

[Scope a UX audit](https://w3experts.com/services/ux-audit/)

- [Nielsen Norman Group: Severity Ratings for Usability Problems](https://www.nngroup.com/articles/how-to-rate-the-severity-of-usability-problems/) — accessed 2026-11-11T00:00:00+00:00
- [Nielsen Norman Group: Using Prioritization Matrices to Inform UX Decisions](https://www.nngroup.com/articles/prioritization-matrices/) — accessed 2026-11-11T00:00:00+00:00
- [Intercom: RICE, simple prioritization for product managers](https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/) — accessed 2026-11-11T00:00:00+00:00
- [W3C: Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/) — accessed 2026-11-11T00:00:00+00:00
- [W3C: Understanding SC 2.4.11 Focus Not Obscured (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html) — accessed 2026-11-11T00:00:00+00:00
- [GOV.UK Design System: Error summary](https://design-system.service.gov.uk/components/error-summary/) — accessed 2026-11-11T00:00:00+00:00

Canonical: https://w3experts.com/blog/prioritize-ux-audit-findings/