UX audit checklist: 40 checks before a redesign

Introduction

Redesigning a product without auditing it first is like repainting a house with a cracked foundation. The surface looks better. The structural problems stay exactly where they were.

Many teams jump straight to wireframes when a product feels dated or conversions stall. The result? A polished interface that still confuses first-time users, still buries the primary action, still loses people at the same step in onboarding.

A UX audit is a structured review of the existing product across user goals, business goals, content, flows, accessibility, and performance. It happens before redesign decisions get made, not after.

This article walks through 40 specific checks, organised into five groups, that form a practical screening framework. Every finding should carry evidence before it becomes a redesign requirement.

Key Takeaways

• A pre-redesign audit identifies what to preserve, what to fix, and what needs deeper research
• Review the experience from both user needs and business goals, especially for complex B2B and deep-tech products
• Document each issue with location, evidence, affected users, severity, root cause, and next step
• Treat the 40 checks as a screening tool, then validate high-impact assumptions with real data

How to Set Up a UX Audit Before a Redesign

A useful audit starts with a defined scope, a clear user journey, and agreed success criteria. An unbounded review of every screen rarely produces anything actionable.

Define the Audit Scope and Goals

Pick one workflow, not the entire product. Good candidates include:

• Discovery-to-demo for a sales-led B2B tool
• Onboarding or account setup for a self-serve product
• Dashboard use for an operational platform
• A single high-value conversion path

Once you've chosen the scope, identify the primary user groups and their jobs to be done. Pair that with the business objective the redesign is meant to move, whether that's trial-to-paid conversion or reduced support volume.

Baseline evidence matters here. Gather it before writing a single recommendation:

• Analytics and site search data
• Support tickets and sales objections
• Past research and known technical constraints

Narrowing scope to one task or section supports a deeper review. Broad "audit everything" efforts usually produce shallow findings.

Prepare the Audit Workspace

Build a finding log before you start reviewing screens. At minimum, it needs fields for:

• Screen or URL
• Issue description and evidence
• Affected user segment
• UX category (navigation, content, accessibility, performance)
• Severity and estimated effort
• Recommendation and owner

Capture screenshots, screen recordings, device details, and the exact flow steps for each issue. This lets stakeholders understand a problem without repeating the audit themselves.

Include people from product, design, engineering, and customer-facing teams. For technically dense products — battery management systems, carbon capture platforms, ESG data tools — verify that whoever reviews the UX actually understands the underlying workflow.

A reviewer who doesn't understand hydrogen electrolysis will miss where the interface mismatches the science.

Choose Complementary Review Methods

No single method catches every problem. Nielsen Norman Group's original comparison found that heuristic evaluation and user testing uncover different sets of usability problems.

That's why effective audits combine expert review with analytics, accessibility checks, content review, and selected user research.

Decide upfront which findings need validation with real users before anyone finalises a redesign decision. This matters most for:

• Technical terminology and jargon
• Trust signals on high-stakes pages
• Anything involving perceived credibility or risk

Set a consistent severity scale before scoring anything. Blocking, high, medium, low, and cosmetic works well. Define what each level means in writing so two reviewers don't disagree on what counts as "high."

40-Check UX Audit Checklist Before a Redesign

Mark each check pass, concern, or fail, and attach evidence. Don't treat these as subjective design opinions.

Product Strategy, Users, and First Impressions — Checks 1–8

1. Clear positioning — Does the product or site state who it's for and what problem it solves, within seconds of arrival?
2. Jargon-free value proposition — Can a new visitor understand the core value without decoding internal or technical terms?
3. Obvious next action — Does the first screen give users a clear step aligned with their intent?
4. Priority alignment — Does the experience support the highest-value user and business journeys, rather than spotlighting low-value features?
5. Message-to-stage match — Do copy, proof points, and calls to action match where the user actually is in their decision?
6. Consistency across touchpoints — Do website copy, product terminology, sales materials, and in-product guidance say the same thing?
7. Documented goals — Are user needs and business goals written down clearly enough to separate a real UX problem from a stakeholder's personal taste?
8. Flagged assumptions — Are assumptions about users, markets, or technical literacy noted for validation, rather than treated as fact?

Information Architecture, Navigation, and User Flows — Checks 9–16

9. User-centred structure — Does the information architecture reflect how users think, not just how departments are organised internally?
10. Familiar navigation labels — Are labels specific, consistent, and free of internal naming conventions?
11. Progress visibility — In a multi-step flow, can users tell where they are and what's left?
12. No dead ends — Are there broken links, orphaned pages, or loops that force a restart?
13. Friction audit — How many steps, decisions, and context switches does the primary task require? Fewer clicks isn't automatically better — check whether each step adds real value.
14. Wayfinding tools — Do search, filters, breadcrumbs, or dashboards match the actual content and workflow complexity?
15. Role clarity — For multi-role products, are permissions, account states, and handoffs understandable to each user type?
16. Edge-case walkthroughs — Walk the flow as a new user, a returning user, an interrupted user, and a secondary user type.

Content, Visual Hierarchy, and Design Consistency — Checks 17–24

17. Attention direction — Does the page hierarchy point users toward the single most important action?
18. Scannable copy — Are headings, labels, and technical explanations written for how people actually read a page?
19. Progressive disclosure — Are complex concepts broken into examples, diagrams, or contextual help rather than dense paragraphs?
20. Specific calls to action — Do buttons describe the outcome, instead of vague labels like "Learn More"?
21. Styling consistency — Do typography, spacing, colour, and components match across comparable screens?
22. Cognitive overload check — Are there visual elements competing with the primary task without adding decision-relevant information?
23. Supporting content review — Are empty states, tooltips, confirmation messages, and error copy clear and useful?
24. Trust-appropriate brand expression — Does the visual language support credibility, particularly for scientific, financial, or environmental claims?

Interaction, Forms, Feedback, and Accessibility — Checks 25–32

25. Interactive consistency — Do buttons, tabs, menus, and cards look and behave the same way across the product?
26. State coverage — Are hover, focus, disabled, loading, success, and error states defined for every important component?
27. Form design — Are labels clear, field order logical, and input types appropriate? Is every requested field actually necessary?
28. Validation timing — Does validation appear at the right moment, and can users recover without losing their entered data?
29. High-consequence action safeguards — Do destructive or irreversible actions include warnings, confirmation, or undo options?
30. System status visibility — Can users tell when something is loading, saving, syncing, or pending approval?
31. Accessibility testing — Does keyboard navigation, focus order, and screen-reader labelling work, per the applicable WCAG guidance? This matters more than most teams assume: WebAIM's analysis of one million home pages found detectable WCAG 2 failures on 95.9% of them.
32. Responsive and touch testing — Do layouts, text scaling, and touch targets hold up across representative screen sizes?

Technical Quality, Performance, Measurement, and Readiness — Checks 33–40

33. Performance measurement — Are loading, interaction, and rendering issues tracked with real tools, not subjective impressions? Google's Core Web Vitals set clear thresholds: a "good" Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift is 0.1 or less.
34. Asset weight review — Are images, fonts, scripts, or third-party integrations adding unnecessary load time?
35. Visual stability — Are there layout shifts, flicker, or broken animations undermining confidence in the interface?
36. Failure-state testing — Do slow, offline, timed-out, and failed states get handled, not just the happy path?
37. Measurement readiness — Do analytics events and conversion goals actually capture the behaviours the redesign needs to evaluate?
38. Qualitative vs quantitative comparison — Where do user feedback and behavioural data agree, conflict, or need more investigation?
39. System capacity check — Can the current design system and content model support consistent redesign decisions?
40. Redesign readiness — Does every proposed change have a defined problem, business rationale, success measure, owner, and validation plan?

How to Interpret and Prioritise UX Audit Findings

A checklist produces observations, not ready-made solutions. Every issue needs interpretation against user impact, frequency, business importance, accessibility risk, and effort to fix.

Classify the Type and Severity of Each Issue

Separate issues by category so the right team can act on them:

• Usability blockers
• Comprehension problems
• Accessibility barriers
• Trust issues
• Visual inconsistencies
• Performance defects
• Content gaps
• Strategic misalignment

Use a severity framework with real definitions:

• Blocking — prevents task completion
• High — creates substantial abandonment risk
• Medium — adds friction
• Low — polish only

Never assign severity from gut feeling. Require evidence: a failed task, repeated feedback, support tickets, an analytics pattern, or a documented accessibility test result.

Prioritise by Impact, Confidence, and Effort

Map findings on two axes: user/business impact versus implementation effort. Add a third dimension, confidence, to separate validated problems from hypotheses that still need testing.

This produces four categories:

• Quick wins — high impact, low effort, act now
• Strategic improvements — high impact, high effort, plan for the roadmap
• Deferred items — low confidence, needs research before committing resources
• Low-priority polish — cosmetic issues that shouldn't displace blockers

For climate tech, green tech, and deep-tech teams, tie each priority to a concrete outcome: faster technical comprehension, stronger partner confidence in due diligence, higher onboarding completion, or smoother handoffs between engineering and operations.

A four-month redesign of the Susteon website followed that rule. Work focused on making carbon capture and hydrogen production technology legible to investors and partners, not on a cosmetic refresh. When the product is technically dense, prioritise comprehension and trust outcomes over visual novelty.

Turn Findings into a Redesign Brief

Convert your highest-priority findings into problem statements: user, context, obstacle, consequence. Skip the visual solution at this stage; that comes later.

For each major change, define:

1. Acceptance criteria and a measurable success metric
2. Which findings need prototype testing, usability sessions, or accessibility validation before sign-off
3. Which existing patterns have evidence behind them and should stay untouched

A redesign should reduce UX debt. Replacing a familiar, working pattern with something novel just because it's new isn't a win — it's a risk without a documented upside.

Common UX Audit Errors and Best Practices

A handful of mistakes make a pre-redesign audit unreliable:

• Auditing every screen at once — Start with the highest-value journey and expand only when findings justify it
• Confusing aesthetics with usability — Record visual inconsistency separately from issues that block comprehension or task completion
• Reviewing only the happy path — Include new users, returning users, different roles, failed inputs, and recovery flows
• Treating heuristic findings as proof — Use expert review to generate hypotheses, then validate high-impact ones with actual users
• Writing vague recommendations — Specify the flow, the problem, the likely cause, the proposed direction, and the owner
• Letting internal language dominate — Test technical terminology with people who match the real audience, not internal stakeholders
• Skipping engineering and content sign-off — Check feasibility, data dependencies, and content governance before finalising scope

Conclusion

A UX audit turns a redesign from a visual reset into an evidence-led decision. It separates what's genuinely broken from what merely looks dated.

Reliable auditing combines the 40 checks above with product analytics, accessibility review, expert evaluation, and real-user validation. No single method catches everything on its own.

Prioritise the problems most likely to affect user success and business outcomes. Then turn those findings into a focused redesign brief, rather than trying to change everything at once.

Frequently Asked Questions

What are the 7 key elements of UX design?

Common frameworks cite usefulness, usability, desirability, findability, accessibility, credibility, and value. Different sources use slightly different terminology, but the underlying ideas overlap closely.

What is a UX audit before a redesign?

It's a structured review of an existing digital experience to surface usability, accessibility, content, interaction, and performance issues before any design changes get planned or built.

How many checks should a UX audit include?

It depends on scope. This article provides 40 checks as a practical pre-redesign framework, but prioritise critical user journeys rather than superficially auditing every screen.

What is the difference between a UX audit and usability testing?

A UX audit is expert-led evaluation against established principles. Usability testing observes real users attempting real tasks. They answer different questions and work best combined.

How do you prioritise issues found in a UX audit?

Weigh user and business impact, severity, confidence level, accessibility risk, and implementation effort together. Validate high-impact assumptions with real users before committing resources.

When should a team conduct a UX audit?

Before a major redesign, after significant product growth or feature changes, when key metrics decline, or at recurring intervals that match your release velocity.