A shortlist is more useful than a mysterious number
A product can receive an impressive usability score while still blocking an important group of people from completing a task. A score is meaningful only when its method, evidence and limits are understood. When you have limited information, start with a list of questions instead. Can someone understand the task? Can they see the commitment? Can they operate the flow, recover from a mistake and recognize success? Have you watched intended users try it? These questions create specific investigations instead of implying that an interface has been fully evaluated.
Separate known gaps from unverified areas
For each concern, record what you observed, where it occurred and how you checked it. “The save button is unreachable using the keyboard in this build” is a known barrier with reproduction steps. “We have not checked keyboard access” is an important unknown. “Users probably dislike the layout” is a hypothesis that needs a clearer basis. Treating these as equivalent encourages confident guesses. Keep an evidence label beside every item so the team knows whether the next action is repair, verification or research.
Begin with consequential barriers
Investigate blocked tasks, inaccessible interactions, loss of work and unclear financial commitments early. Their consequences can be significant even when the affected population is small. Consider severity and recoverability together: a minor delay with a clear workaround differs from a failure that loses an application. Also consider reach, frequency and the conditions under which a problem occurs. A rare event may still deserve urgent attention if the cost is high. Do not let low usage automatically excuse an access barrier or a serious recovery failure.
Use effort to sequence work, not erase the problem
After identifying consequences, ask what it takes to investigate or repair each item. A wording change might be inexpensive, while reliable recovery could involve state management, backend behavior and duplicate prevention. Split a large issue into the next useful action: reproduce it, confirm a dependency, specify the missing state or plan a task session. Give that action an owner. A difficult repair does not make the problem less important; it changes how the team approaches it and what interim mitigation might be possible.
Let the self-check start a conversation
The UX Friction Check orders your own answers using simple rules. Known access and recovery gaps come first, followed by other known gaps and areas you have not checked. It does not read your website, inspect code, interview users or establish accessibility compliance. Use its output to decide where to look next. Add product context, evidence and severity before treating the list as a delivery plan. If you mark everything as checked, keep the evidence and continue observing the experience; the result is not a certificate that the product is finished.
End with three explicit next moves
For the first three priorities, write the concern, evidence, consequence, owner, next action and review date. Describe what would count as resolution and what needs retesting. Avoid closing an issue solely because a new screen was designed; verify the behavior in the implemented flow. Revisit the order when new evidence arrives, a dependency changes or a release affects the task. A practical prioritization process stays connected to what people can actually do, rather than protecting the appearance of a healthy dashboard.
Put this guide to work
Need an experienced review of the priorities in your actual flow?
See the deliverables, boundaries, and next step before you book.
Explore the scope ↗Keep exploring
A better-looking redesign is a hypothesis. Here is how to test it.
What to bring to a UX review so you leave with useful decisions