How to run a UX audit that leads to useful fixes

A UX audit is a structured review of how well a product helps people complete their tasks. A useful audit combines a walkthrough of the interface with available usage evidence, then turns the findings into a prioritised set of changes. Its value is in the decisions it enables, not the length of the slide deck.

Start with one important journey. “Review the app” gives you an endless list of observations. “Find out why new account owners cannot finish setup” gives the work a boundary. You can still record problems outside that boundary, but they should not displace the question the audit was commissioned to answer.

1. What should you collect before reviewing the interface?

• The task and the people who need to complete it.
• The intended success event and the current steps leading to it.
• Support themes, known defects and customer feedback.
• Available funnel data, including the period and audience it represents.
• Representative accounts: new, established, empty and unusually complex.
• Technical or commercial constraints that a proposed fix must respect.

Keep observation separate from explanation. Analytics may show a drop between two steps without telling you why people left. A reviewer may find a confusing label without knowing whether it affects many users. Record both, then identify the research or instrumentation needed to connect them. Do not dress an expert opinion up as something users demonstrated.

2. How do you walk through the product?

Use the product as a person with a job to finish. Begin where they would begin, with the information they would have. Follow the main path and then the likely interruptions: missing data, a validation error, an expired session, a return visit and a smaller screen. Check whether the product explains what happened and how to recover.

A workflow can be technically complete and still leave someone uncertain. Does “Save” mean a draft or a published change? Has an invitation actually been sent? Can someone undo a decision? These are often more useful audit questions than whether a card has the latest visual treatment.

Where possible, watch representative users attempt the task. GOV.UK’s moderated usability-testing guidance describes observing participants complete specific tasks to identify usability problems. Keep the task neutral: asking someone to “click the settings icon” tests obedience to an instruction, not whether they can find the account controls.

3. What belongs in each finding?

• The screen or step where the problem occurs.
• What happened, with a screenshot or reproducible example.
• Who it affects and which task it interrupts.
• The evidence available and how confident you are in the explanation.
• A proposed change or the next question to investigate.
• Dependencies, an owner and a way to check the result.

For example, a useful finding might say that invited users reach an empty workspace without knowing how to request access. The proposed fix could include clearer invitation status and a recovery action. “Improve onboarding” is too broad to estimate, assign or verify.

4. How should you prioritise the fixes?

Consider the consequence for the user, how often the situation occurs and the strength of the evidence. Then consider delivery effort and dependencies with the engineers. A severe problem can deserve attention even when it affects a small group. An easy cosmetic change should not automatically outrank a task that cannot be completed.

Avoid turning uncertain estimates into a false scientific score. A short ordered list with reasons is often more useful. Separate confirmed defects, promising design changes and questions that need research. Each calls for a different next step.

5. What happens after the audit?

Take the highest-priority flow into a prototype or a small implementation. Check the change against the original problem, then observe the released behaviour. A task-completion measure, support theme or recovery rate may be more useful than a general satisfaction question. Use a consistent definition so the before and after mean the same thing.

Refract’s product sprint is designed for this handover from diagnosis into a working direction. We audit the flow, prototype it on real content and test it with users before setting out the build plan. If the audit already identifies a straightforward defect, fix it rather than inventing a workshop around it.

6. Questions

Is a UX audit the same as user research?

No. An expert review examines the product; user research observes or asks the people who use it. They can inform each other, but an audit should clearly identify which findings came from actual user evidence.

Should a UX audit cover accessibility?

It should consider keyboard use, readable content, focus and other access barriers. A general UX audit is not a substitute for a defined accessibility assessment with an agreed standard and appropriate user testing.

How many screens should an audit include?

Scope the task end to end rather than choosing an arbitrary screen count. Include the important entry, success, failure and recovery states for that task.