How to Prioritize UX Fixes When Everything Looks Broken
A UX review produces thirty problems and capacity for three. Learn a simple, evidence-based way to rank fixes by reach, severity, and effort, how to avoid the common prioritisation traps, and how to defend the order to stakeholders.
Short answer: score each problem on three things you can observe: how many people hit it (reach), how badly it stops them (severity), and how much work the fix needs (effort). Fix high-reach, high-severity, low-effort issues first. Problems on the path to payment or signup outrank problems elsewhere. Use evidence for the scores, not opinion, and write the evidence beside each item.
Table of Contents
- Why Prioritisation Fails
- Three Scores
- Where the Evidence Comes From
- A Worked Example
- Rules That Override the Score
- Key Takeaways
Why Prioritisation Fails
- The loudest voice wins. Whoever argues hardest gets their issue fixed.
- The most recent complaint wins.
- The most visible page wins. Hours on the homepage hero while checkout is broken.
- The easiest wins. A list of trivial fixes shipped, none of which mattered.
- The most interesting wins. A redesign instead of a one-line fix.
- Everything is "high".
A simple scoring method does not remove judgment. It makes the reasoning visible so it can be challenged.
Three Scores
Reach: how many people hit it
Estimate the number of sessions affected per week. Use real counts: sessions reaching the page, multiplied by the share showing the problem.
| Score | Meaning |
|---|---|
| 1 | A handful |
| 2 | A noticeable minority on a low-traffic page |
| 3 | Many, or everyone on one device |
| 4 | Most visitors to an important page |
| 5 | Nearly everyone on a main flow |
Severity: how badly it stops them
| Score | Meaning |
|---|---|
| 1 | Cosmetic. Noticed, no effect |
| 2 | Slows them down |
| 3 | Causes errors they recover from |
| 4 | Many give up |
| 5 | Blocks the task entirely |
Effort: how much work
| Score | Meaning |
|---|---|
| 1 | A text or style change |
| 2 | A small code change |
| 3 | A few days |
| 4 | A sprint |
| 5 | A project |
Priority = Reach × Severity ÷ Effort.
Then multiply by a weight for where it happens: problems on a conversion path count double.
Where the Evidence Comes From
Every score should point to something observed.
| Score | Evidence |
|---|---|
| Reach | Sessions reaching the page, share with the problem, funnel step counts |
| Reach | Sessions affected by an error group (JS errors) |
| Severity | What users do next in recordings: retry, recover, or leave |
| Severity | Exit rate after the problem, compared with sessions that did not hit it |
| Severity | Rage clicks and repeated attempts |
| Effort | An estimate from whoever will build it |
"Seen in 9 of 15 mobile checkout recordings, and 6 of those left" is a severity score with a reason. "This feels really bad" is not.
A Worked Example
| Problem | Evidence | Reach | Severity | Effort | Path | Score |
|---|---|---|---|---|---|---|
| Pay button hidden by keyboard, mobile checkout | 9 of 15 recordings, 6 left | 4 | 5 | 1 | ×2 | 40 |
| Coupon error unclear | 4 of 15, 3 left | 2 | 4 | 1 | ×2 | 16 |
| Homepage hero image slow | Load data, mobile | 5 | 2 | 2 | ×1 | 5 |
| Blog sidebar misaligned | Visual review | 3 | 1 | 1 | ×1 | 3 |
| Navigation redesign | Opinions | 4 | 2 | 5 | ×1 | 1.6 |
The ordering is not surprising when laid out. The value is that a team was about to spend a month on the navigation.
Treat scores as rough. A 40 against a 16 is meaningful. A 16 against a 14 is not.
Rules That Override the Score
Some things should not wait for a ranking.
- Fix what is broken now. A failing checkout, a form that does not submit, data loss.
- Legal and accessibility problems have costs the score does not capture.
- Security and privacy issues, such as unmasked personal data.
- Problems on the money path first. Payment, signup, lead form.
- Cheap fixes can be batched. Twenty one-line fixes in an afternoon are worth doing even if each scores low.
- One big bet at a time. Larger projects need separate justification (revenue impact).
And two cautions:
- Reach on a small segment can still matter. A problem affecting 2% of visitors is serious if they are your largest customers.
- Re-score after fixing. The next problem may have been hidden behind the first.
After shipping, check that the behavior changed: watch a few sessions and compare the step's conversion. A fix that was not verified may not have worked.
Write the evidence in the ticket
A fix with "9 of 15 recordings, link attached" gets scheduled. A fix with "this is confusing" gets debated.
Key Takeaways
- Score reach, severity, and effort from evidence.
- Weight problems on conversion paths.
- Broken, legal, and privacy issues skip the queue.
- Verify the fix and re-score.
Conclusion
Prioritisation is deciding what not to fix yet. Do it with numbers anyone can check, and the conversation moves from whose opinion to which evidence.
Frequently Asked Questions
Related articles
Stay in the loop
Get the latest insights on product analytics and user behavior delivered to your inbox.
