UX Audit: Find the Friction

A UX audit should answer a product decision, not judge every screen

A useful UX audit starts with a visible problem. People abandon account setup, support requests rise after a navigation change, or a sales team keeps explaining a feature the product should explain itself. The audit traces that friction across the journey, tests plausible causes, and ranks changes by user consequence and delivery effort. It does not award the interface a mysterious score out of 100.

Before hiring anyone, write the decision in one sentence. For example: “Should we repair checkout inside the current product, or redesign the complete purchase journey?” That question determines the journeys, users, data, environments, and stakeholders in scope. Without it, the audit expands into every inconsistency the reviewer can photograph, which is a reliable way to buy eighty slides and one new meeting.

Scope the UX audit around complete journeys and real conditions

Pages are a weak unit of scope because users arrive with goals, history, devices, permissions, and interruptions. Select three to six representative journeys with a clear start, outcome, and failure state. Include the routes around the interface: confirmation email, payment handoff, error recovery, support contact, and any offline step that determines whether the task succeeds.

Name the user groups and conditions that can change the result. A first-time buyer on a narrow phone, an account administrator using a keyboard, and a returning customer with saved data may meet three different products. GOV.UK's service standard recommends testing all parts of a service that users interact with, across devices that reflect their behavior. The principle matters beyond government services: scope the experience people have, not the rectangle your team owns.

Prepare access before work starts: current product, representative accounts, analytics definitions, research archive, support themes, design files, component documentation, release history, and the people who own the journey. If the team is still unsure which problem deserves attention, a focused product discovery workshop should come first. An audit can diagnose an experience; it cannot choose the company's priorities in a vacuum.

Combine four evidence layers before recommending a redesign

Each method sees a different failure. Analytics can reveal where behavior changes but rarely why. Expert review can find broken conventions quickly but cannot represent every user's context. Usability testing shows people attempting realistic tasks, while accessibility and performance checks expose barriers that a short session may miss. The audit should connect these layers rather than flatten them into one confidence-free backlog.

Nielsen Norman Group's heuristic evaluation guidance is explicit that expert review cannot replace user research. GOV.UK describes moderated usability testing as watching participants complete specific tasks with neutral instructions. Google, meanwhile, distinguishes field Core Web Vitals from lab diagnostics because a synthetic run is only one slice of real conditions. These are complementary tools, not rival religions.

Test the riskiest explanation with people, not another workshop

Turn uncertain findings into research questions. If analytics show that many people leave the pricing page, possible causes include price, missing information, unclear plan differences, slow loading, or an irrelevant audience. A usability session can reveal whether likely buyers understand the offer and can choose a plan. It cannot prove the exact commercial effect of a new layout.

Use realistic tasks and likely users. GOV.UK's moderated usability testing guidance recommends agreeing research questions, user types, and product areas before sessions, then using clear goals and neutral instructions. A prompt such as “Find the cheapest plan” pushes the participant toward price. “Choose a plan for a team of twelve that needs approval controls” tests whether the interface supports an actual decision.

Include disabled participants when their experience is relevant, which it usually is. Also separate usability research from a formal conformance claim. A website accessibility audit needs a defined scope, representative sample, manual testing, and explicit reporting. A UX audit can identify accessibility risks and interaction failures, but a few screens and an automated scan cannot certify an entire product.

Rank findings by consequence, reach, recurrence, and confidence

Severity is not the volume of red ink on a screenshot. For each finding, record who is affected, the blocked or degraded task, how often the pattern appears, the evidence behind it, and the cost of leaving it in place. Then add confidence and reversibility. A broad recommendation supported by one observation should not outrank a repeated failure confirmed by product data and user sessions.

Consider a hypothetical subscription product. Three participants cannot find invoice settings, support logs show the same question, and account analytics show repeated visits to unrelated billing pages. That evidence supports a navigation and terminology problem. The first response might be a small information architecture change with an instrumented follow-up, not a complete account-area redesign.

Preserve disagreement in the report. If product data suggests success while sessions reveal confusion, check event definitions, user segments, task wording, and whether people eventually succeeded through a workaround. Nielsen Norman Group recommends triangulating methods because qualitative research provides context while quantitative data estimates patterns. Contradiction is often the useful part, not a formatting error to remove before the executive readout.

The deliverable must survive contact with the roadmap

Require an evidence register and a decision-ready roadmap. Every priority should include the journey, user, observation, source, consequence, recommendation, effort assumptions, dependency, owner, and verification method. Annotated screens help teams find the issue, but they are supporting evidence. The core deliverable is a sequence the product, design, engineering, content, and analytics owners can actually release.

Organize the sequence into containment, repair, and learning. Containment removes immediate harm, such as a keyboard trap or destructive action with no recovery. Repair changes the design or implementation. Learning adds an event, session, or follow-up test where confidence is still low. Connect system-level findings to the design system audit rather than fixing the same broken component screen by screen.

End with a playback using the live product, not only slides. Let owners challenge evidence, confirm constraints, and choose the first release slice. Agree acceptance criteria and a retest date before the engagement closes. Otherwise the report becomes a museum of perfectly preserved problems.

Know when a UX audit is the wrong purchase

Do not buy an audit when the team already knows the problem and lacks capacity to fix it. Fund the repair. Do not buy one to settle a taste dispute between executives. Test the decision with users. And do not expect a short audit to establish a conversion lift, legal compliance, or the needs of every audience. Those require appropriate measurement, specialist review, or longer research.

The serious objection is that external reviewers lack product context. That is true unless the engagement includes stakeholder interviews, representative data, working sessions, and a challenge period. External distance is useful for exposing assumptions, but it does not grant magical domain knowledge. Ask how the provider will learn the rules, edge cases, and operating constraints before judging the interface.

An audit is most valuable before a roadmap commitment, redesign, major release, or investment decision where evidence can still change the plan. If a full website redesign strategy is already underway, use the audit to test its riskiest journeys and migration assumptions, not to restart every design conversation.

UX audit buying checklist

• Write the product decision, user groups, journeys, platforms, markets, and exclusions in scope.
• Provide representative accounts, analytics definitions, research, support themes, designs, code context, and owners.
• Require a clear method for expert review, user research, accessibility, performance, and evidence confidence.
• Ask for one concrete finding format before signing: evidence, consequence, recommendation, owner, and verification.
• Agree how priorities will reflect reach, recurrence, impact, confidence, effort, and reversibility.
• Book the live playback, challenge period, first release slice, measurement update, and focused retest.

Prepare a one-page brief with the decision, journeys, known symptoms, evidence available, delivery constraints, and the planning date the work must influence. Send it to Seuil Digital to scope the smallest UX audit that can change a real product decision.