Triage
Prioritize UX friction without hiding behind a score
UxerProof Editorial · · 3 min read
A journey review can produce more findings than a team can repair in one release. The temptation is to assign numbers, sort the list and call the first item the priority. A score can help organize discussion, but it cannot supply missing context.
Start with the decision each finding affects. An issue that prevents a release-critical task deserves different treatment from a minor inconsistency on a rarely used screen, even when both are easy to demonstrate.
Ask four questions before estimating effort
First, what happens to the intended outcome? Describe whether the person is blocked, needs a workaround, repeats work or merely encounters an inconsistency.
Second, how strong is the evidence? A reproduced failure and an unverified interpretation should not be presented with equal confidence.
Third, is the workaround realistic? An administrator correcting the database is not a customer-facing recovery path. Neither is knowing the exact URL of a hidden page.
Fourth, why does this matter now? Tie urgency to the current release, pilot or known usage. If reach is unknown, mark it unknown rather than substituting a confident-looking estimate.
Compare findings in plain language
Consider three illustrative findings:
- A completed form cannot be saved by the intended role.
- A saved record exists, but the confirmation does not explain where to find it.
- Two secondary buttons use slightly different wording for the same action.
The first may block the promised outcome. The second may cause avoidable searching or duplicate work. The third may matter for consistency but needs context before it outranks the others.
This comparison is already useful without multiplying speculative impact, reach and confidence values into a precise-looking total.
Keep uncertainty visible
Use a short triage record: observation, affected task, evidence strength, workaround, proposed action and owner. Add effort after the problem is understood well enough to estimate a repair.
If a finding comes from a synthetic journey, do not translate one run into a claim about the percentage of customers affected. Use it to identify a problem worth reproducing or investigating with appropriate real-user evidence.
Also distinguish an execution blocker from a product blocker. A broken test dependency may prevent assessment while telling you little about the interface itself.
Decide what happens to every important finding
A useful triage meeting ends with actions: repair before release, investigate, accept temporarily with an owner, or defer with a reason. Avoid “later” without a trigger for reconsideration.
When a fix lands, inspect the original task again. A changed score alone is not enough to establish that the obstacle disappeared. Preserve the evidence for the particular finding and check whether the repair introduced a new limitation.
Next step: Use before-and-after UX validation to define the rerun before implementing a proposed improvement.
Put the evidence structure to work
Inspect UxerProof's fictional sample report, or use the free readiness check to prepare your next journey. External Circuit execution is not yet activated; see current launch status for availability.