How to Run a UX Audit

An audit done well is the most economical UX intervention a team can commission. An audit done badly is a waste of two weeks and a wedge of credibility. The difference is process, not talent. Senior practitioners follow the same six-stage methodology every time. The framework below is the one I've used across retail (Selfridges), travel, scientific publishing, and now JD.com.

Stage one: plan and scope

Scope is where audits collapse. Teams agree to a vague "audit the product" brief, the practitioner spends two weeks producing fifty findings, half of which the team considers out of scope. The deliverable lands flat.

Scope on three axes.

Write the scope as a single paragraph. Read it back to the stakeholder. Get explicit written sign-off before any walking-the-product begins. The paragraph is the document everything else hangs off. Without it, the audit drifts and the report becomes negotiable.

Worked example

"Audit the checkout flow on iOS and web for a UK retail client. Scope covers from cart to order confirmation, including guest and account-holder paths. Heuristic review against Nielsen's 10 plus WCAG 2.2 AA accessibility coverage. Output: written report with prioritised findings, a one-hour stakeholder presentation, and a recommended roadmap for the next two sprints. Delivered within three weeks of kickoff."

That paragraph names the surface, the depth, and the audience. The team can disagree with it before work starts. After work starts, scope creep becomes a change request.

Stage two: align stakeholders

Before any screen is reviewed, the audit needs three things from the team: an owner, an authority, and a list of constraints.

• The owner is the person responsible for actioning findings after delivery. Usually a head of product or head of design. They sign off on scope and attend the final presentation.
• The authority is the senior figure who can unlock budget and engineering time when the audit lands. Sometimes the same as the owner; often a level higher.
• The constraints are the things the audit shouldn't bother flagging because the team already knows about them. Existing tickets, planned migrations, known design system drift. A constraints document at the start saves you embarrassing both parties later.

Run a 30-minute kickoff with the owner. Hand over the scope paragraph. Ask for the constraints document. Confirm the presentation date. Then begin.

Stage three: gather evidence

This is the longest stage in elapsed time and the easiest one to underestimate. Two passes through the in-scope surface, with different mindsets each time.

Pass one: walk as a user

Do the tasks. Open the app cold, sign up, complete the core flow, abandon halfway, come back, sign in, recover a password. Don't take notes yet. The first pass is for impression, not findings. You're looking for the moments that feel wrong, the points where you slow down, the places where you accidentally tap the wrong thing.

Pass two: walk as an auditor

Now systematically. Screen by screen, with the heuristic and WCAG checklists open beside you. For each finding:

• Screenshot the issue.
• Name the heuristic or success criterion it violates.
• Note the path that surfaces it (URL, user role, device).
• Capture an initial severity guess (you'll refine in stage four).
• Note a candidate fix.

Capture findings the moment they appear. Writing-up at the end of a day loses thirty percent of the detail. Use the UX audit checklist as the working document; the categories and severity columns are built for this stage.

Tools that earn their place

For the deterministic parts of the audit, lean on tools. They run faster and don't get tired. The contrast checker for colour pairs, the focus state checker for the new WCAG 2.2 criteria, WAVE for an automated accessibility pass, PageSpeed Insights for performance baselines. None of these replaces expert review; all of them speed up the parts of expert review that are mechanical.

Stage four: score severity

An unscored finding is a suggestion. A scored finding is a decision the team has to make. The scoring stage is where the audit transitions from observation to prescription.

Severity has three component questions. Apply them honestly to every finding.

• Frequency. How often will users encounter this? Every session, or once a year?
• Impact. When they encounter it, what happens? Minor friction, dropped task, financial harm?
• Persistence. Does it improve with familiarity (people learn around it) or does it get worse (each repeated encounter erodes trust)?

The temptation is to score everything as severity 3. Resist it. A flat severity distribution is a failure of the rubric. Aim for roughly one third 1–2, one third 3, less than ten percent 4. If everything is major, nothing is.

Stage five: recommend fixes

Findings without recommendations are complaints. The recommendation is what makes the audit actionable.

For each finding, the recommendation should answer three questions:

• What changes? A specific behavioural description, not a pixel-level mock. "Surface the saved-card state during the payment step so users don't re-enter card data unnecessarily."
• What does it cost? An effort estimate in T-shirt sizes: S (under a day), M (one to three days), L (a sprint), XL (multiple sprints).
• What does it gain? Expected impact in plain terms: "Reduces drop-off in payment step. Estimated lift: low-to-moderate."

If a recommendation needs a sketch to be understood, include the sketch. But the sketch supports the behavioural description; it does not replace it.

Stage six: present findings

The deliverable is not the document. The deliverable is the team understanding what to do next. A finely typeset report that doesn't change behaviour is a failed audit.

Lead with the top three

An audit can produce forty findings. A team can act on three. The executive summary opens with the three highest-severity findings, the business impact of each, and the recommended action. Everything else is appendix.

Walk it live

Don't email the deck. Run a 45 to 60 minute working session with the team. Engineering will surface implementation constraints. Product will surface roadmap constraints. The recommendations sharpen. Ownership transfers.

Capture the next sprint live

End the session with the team agreeing which findings ship in the next sprint. Write the tickets there and then. Audits that don't generate tickets in the room rarely generate them later.

See the example audit report for what good looks like end to end. Audit templates include the report structure, executive summary format, and presentation deck.

Turning audit into roadmap

The roadmap is a separate artefact from the report, even though it's derived from it. Score every finding on a two-axis grid of impact and effort.

Most audits surface ten to twelve findings in the high-impact-low-effort quadrant. That's the first sprint's worth of work and the audit's most visible return on investment. Present the quadrant grid as a single slide; teams adopt it faster than they adopt long ranked lists.

Common failure modes

Five ways a methodologically correct audit still ends up filed and forgotten. Avoid these and you're already in the top quartile.

• Scope creep accepted in silence. Mid-audit, the stakeholder asks "while you're at it, can you also look at...". Saying yes without changing the timeline is the fastest way to a poor deliverable.
• Severity inflation. Everything is severity 3. The team treats the list as a flat backlog and drops it in the parking lot.
• Recommendations that read as design ideas. "Try a sticky CTA pattern" is a suggestion. "Add a sticky CTA pattern to the payment step where the in-place CTA falls below the fold on iOS" is a recommendation.
• Presenting only to leadership. The senior stakeholder loves it. The team that has to ship the fixes never sees it. Six months later nothing has changed.
• No follow-up. A two-week check-in after the audit closes the loop. Without it, the audit is theatre.

Frequently asked questions