How to prioritize UX audit findings

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 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 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 definitions from the W3Experts audit template, version 1.1.

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:

1. State the widths, browsers or roles the check covers.
2. Prefer a check a script can repeat. Our sample audit scripts double as regression tests.
3. 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.

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?

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?

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?

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 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?

1. Close items with evidence. Attach the re-run script output or a new screenshot to the ticket. “Fixed” without proof reopens the debate later.
2. Re-rate after each release. A fix can lower the severity of a related item. A new feature can raise one.
3. Move Validate-first items when data arrives. Promote them with a confidence change, or close them as “not a problem”.
4. 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 includes the severity table, the scoring rule and this sample backlog as a worked page. For SaaS products, the SaaS UX audit checklist helps you produce the findings in the first place.

Does the backlog point at deeper problems? If the onboarding model needs rethinking, UI/UX design or 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.