UX Audit Checklist: What to Check, and in What Order

A UX audit is a structured review of an existing website or product that finds where users get stuck or drop off, then ranks the fixes by impact and effort. This checklist has 48 checks in 10 groups, in the order we work through an audit: scope first, then the journeys, then accessibility, then the evidence that turns each observation into a priority.

Use it on one product area at a time. Mark each check as pass, fail or unclear, and attach a screenshot and a source to every fail. If you would rather have someone else run the review, our fixed-scope UX audit follows the same steps and finishes with a ranked backlog.

How to use it: a check that fails is only a finding once you can point to evidence for it. Everything in the last group exists to make that easy.

Prefer to score as you go? Use the interactive version of this checklist: the same checks, with a running score and a start-here list.

1. Before you start: scope and evidence

Decide what the audit is for before you open the product. These four checks stop it turning into a list of opinions.

• Have you picked the one metric this audit exists to move (activation, trial-to-paid, checkout completion, enquiries)?
• Have you listed the journeys in scope: signup, activation, the primary workflow, and checkout or upgrade?
• Have you gathered the evidence you already hold: analytics funnels, session recordings, support tickets and sales-call notes?
• Do you know who will act on the findings, so each item can be written for the person who has to fix it?

2. Journeys and task success

Walk each journey the way a first-time user would, with no shortcuts and no knowledge of how the product is built.

• Can a first-time user complete each in-scope task without help or a tutorial?
• Is the next step obvious on every screen, or does the user have to guess?
• Is there any screen with no way forward or back?
• Does each step ask only for what it needs at that moment?
• Can users recover from a mistake without starting again?
• Is the most common path also the easiest one to find?

3. Navigation and information architecture

People leave when they cannot find things. Check labels, location and route.

• Are labels written in your users' words rather than internal team language?
• Can a user tell where they are and how they got there?
• Are the pages people look for most reachable from the main navigation?
• If there is search, does it return useful results for the terms people actually use?
• Is there one clear way to get help or contact you from any page?

4. Forms and input

Forms are where intent turns into revenue or into abandonment.

• Does every field have a visible label, not only placeholder text?
• Do error messages say what went wrong and how to fix it?
• Is validation shown next to the field at a sensible moment, rather than only after a failed submit?
• Does each field bring up the right mobile keyboard and support autofill?
• Has every optional or unnecessary field been questioned?
• In multi-step forms, is progress visible and is entered data kept when users go back?

5. Content and calls to action

A user should know what the product is, what to do next, and what it will cost them.

• Can a new visitor say what the product does and who it is for from the first screen?
• Is there one primary action per screen, visibly stronger than the rest?
• Do button labels describe the outcome ("Start free trial") rather than the mechanism ("Submit")?
• Is the price, or the cost of the next step, stated before the user has to commit?
• Is proof (customers, results, security) placed next to the decision it supports?

6. Feedback, states and trust

Most interfaces are designed for the ideal case. Audit the other states.

• Does the interface show status while something loads or saves?
• Are empty, loading, error and success states designed rather than left as defaults?
• Does every important action get a clear confirmation?
• Do destructive actions ask for confirmation or offer undo?
• Do security, privacy and payment moments say plainly what will happen to the user's data or money?

7. Accessibility (a WCAG 2.1 AA pass)

These are the checks that carry legal exposure as well as usability cost. Run them across the same journeys.

• Does body text have a contrast ratio of at least 4.5:1 against its background, and large text at least 3:1?
• Can every interactive element be reached and operated with the keyboard alone?
• Is keyboard focus always visible and in a logical order?
• Do images that carry meaning have text alternatives?
• Is colour never the only way information is conveyed?
• Do inputs, buttons and links have names a screen reader can announce clearly?

8. Mobile and responsive

Check every in-scope journey on a real phone, not only a narrowed browser window.

• Does each journey work at phone width without horizontal scrolling?
• Are tap targets large enough, and spaced so they can be hit without zooming?
• Is the key action reachable without being hidden behind a fixed bar or the on-screen keyboard?
• Do tables, charts and long forms have a considered small-screen layout?

9. Speed as users feel it

Lab scores matter less than whether the interface responds when someone is about to act.

• Does the interface respond quickly at the moment the user needs to act, not only on first load?
• Does content jump around as the page loads?
• Is anything important held back by slow scripts or heavy images?

10. Evidence: tie every finding to a number

A finding without evidence is an opinion. Attach at least one source to each item you record.

• Which funnel step or drop-off figure does this friction explain?
• What do session recordings show at the point where users leave?
• Which support tickets or sales questions point to the same screen?
• Can the problem be reproduced on more than one device and by more than one person?

How to rank what you find

A long list of problems is not a plan. Score each finding on three things: how much it hurts users, how much it costs the business, and how much effort the fix takes. The scores sort the list into quick wins (high impact, low effort), structural work (high impact, high effort) and everything that can wait.

The table is an illustration of the method, not client data.

When a self-run checklist is not enough

A team that built the product knows too much to see it as a newcomer, and a checklist cannot supply the evidence or the ranking on its own. Those are the two parts that make an audit usable. If a rebuild is on the table, an audit is a cheaper way to learn which problems are actually costing money before you commit to it.

For a fuller explanation of what a website audit covers, read what to expect from a professional UI/UX audit. If the friction you find is in research rather than design, UX research is the next step, and for product teams the findings usually feed straight into SaaS product design work. You can see how a research-led redesign played out in the Adda247 case study.