How to prioritise UX findings without guesswork

Don’t reduce everything to one score

Some findings matter a lot and are hard to fix. Others are easy to fix and barely matter. If you blend severity, reach and effort into one unexplained number, those differences disappear, and the team ends up arguing about the number instead of the problem.

So we start by making the reasoning visible. For each issue: which task does it affect, what does it cost the user, and what’s the evidence? Then note how many people it’s likely to reach, how uncertain it is, and what it depends on. Don’t invent a percentage of affected users when there’s no data. “Seen in two of the support tickets you shared” is more honest, and more useful, than a confident figure nobody can defend.

Separate severity from confidence

Imagine an account setup flow with two issues. A required field can’t be reached with a keyboard. Elsewhere, a secondary label might be confusing. The first can be reproduced by anyone in thirty seconds. The second is a reasonable guess that needs testing. Both deserve attention, but you’d act on them differently.

We use plain categories teams can remember:

• Blocker: stops people finishing the task.
• Serious: makes the task hard, slow or risky.
• Minor: adds avoidable effort or friction.

Then, separately, how confident are we? Reproduced and confirmed, supported by your data, or a hypothesis to test. A blocker we’re unsure about might need a quick check before anyone writes code. A serious issue we’ve reproduced can probably go straight into the backlog.

One note on accessibility: an audit can flag visible accessibility problems, but a priority list isn’t a WCAG conformance assessment. Where something needs specialist testing, the finding should say so.

Bring engineering into the conversation early

We can suggest design directions, but your engineers know the systems, the dependencies and the release constraints. Our founder started out as a front-end engineer, and the main lesson from that is the size of a screen change tells you very little about the size of the work behind it.

Showing a clearer approval status might need changes to the underlying state model. That’s a small visual tweak with a big dependency. The reverse happens too. A major source of confusion can sometimes be fixed with a change in wording. So ask for effort estimates after talking through the actual behaviour, not by pointing at a mock-up.

Choose a small first set

Sort the findings into three piles: work that can go ahead now, questions that need more evidence, and changes that depend on another decision. Then choose a short first set around the most important task. Avoid promising to fix everything in the next sprint; an over-committed list soon loses credibility.

For each chosen action, write down:

• The problem and who it affects.
• The evidence, and what’s still uncertain.
• The proposed change or investigation.
• The owner and any dependencies.
• The signal that will tell you whether it helped.

That last point is easy to skip. A label change might be checked in a few quick usability sessions. A fix to error recovery might show up in completion rates and support contacts. Pick a check that relates to the original problem, rather than celebrating that a ticket was closed.

Come back to it after you ship

An audit is a snapshot of the product and the evidence at that moment. A platform change, a new customer group or a reworked process can change what matters. Keep the decision record short enough that someone will maintain it.

Our UX Audit ends with exactly this kind of ranked list, plus a walkthrough to agree it with your team. If the findings point to a bigger interaction change, Complex Workflow Design can take the chosen direction forward.