UX audit checklist

A UX audit is a structured review of a product's user experience against usability principles, accessibility standards and the product's own data, ending in a ranked list of fixes. This UX audit checklist gives you 40 checks for SaaS products and apps, grouped into onboarding, navigation, forms, content, accessibility, performance and conversion. It ends with a UX audit template for scoring what you find, so the fixes that matter most get done first.

These are the checks we work through when a founder asks us for a ranked user experience audit. Each one says what to look for and how to test it. You can run them yourself with the product open in one window and this page in the other.

What is a UX audit?

A UX audit is an expert review of how well a product lets its users get their work done. Reviewers walk through the main tasks and compare what they see against known principles. They back each finding with evidence: a screenshot, an analytics drop-off, a support ticket or a failed accessibility criterion. The result is a ranked list of problems with a suggested fix for each, not a redesign.

The method behind most audits is heuristic evaluation, described by Jakob Nielsen and Rolf Molich in a 1990 paper, together with the usability heuristics Nielsen published in 1994. Modern audits add the Web Content Accessibility Guidelines (WCAG) 2.2 and real product data. An audit finds where problems probably are. Usability testing methods then show whether real users run into them, and how badly.

How to prepare for a UX audit

• Pick the core tasks. List the three to five things users come to the product to do, such as sending an invoice or inviting a teammate. Audit those paths first.
• Gather the data. Pull funnel analytics, the most common support ticket themes and any recordings or survey answers you already have.
• Set up the devices. Use one phone, one laptop, a keyboard with no mouse and a screen reader such as VoiceOver or NVDA.
• Use more than one reviewer. In Nielsen and Molich's experiments, single evaluators found only 20 to 51% of the usability problems, while the pooled findings of three to five evaluators performed well.
• Start from a new account. Your own account has data and habits that hide onboarding problems.

The UX audit checklist: 40 checks

Mark each check pass, fail or not applicable, and write down the evidence for every fail. Once the first audit is done, keep the list as a UX checklist for every major release, not only for the moments when something feels wrong.

Onboarding and first use

1. The first screen says what the product does. Show it to someone new for a few seconds, hide it, then ask what the product is for and who it serves.
2. Sign-up asks only for what the first session needs. Every field should be needed now. Company size and phone number can usually wait.
3. Sign-in needs no memory test. Password managers and paste both work, and there is no puzzle to solve. WCAG 2.2 criterion 3.3.8 sets this at level AA.
4. Empty states teach the next action. A new account shows one clear first step, not a blank table.
5. A new user reaches a useful result without help. Time a fresh account from sign-up to the first real outcome and note every pause.
6. Setup shows progress and can be resumed. Users can leave halfway and come back to the point where they stopped.
7. Blank starts have a shortcut. Templates, sample data or an import option exist wherever an empty canvas would stall people.

Navigation and structure

8. Labels use the user's words. Menu items and buttons match the terms customers use in support tickets, not internal team names.
9. Users can tell where they are. The current section is marked, and each page title matches the link that led to it.
10. Core tasks are easy to reach. Each core task starts from the main navigation or the home screen, without hunting through settings.
11. Back and undo behave. The browser back button returns people to the previous screen in the state they left it, and common edits can be undone.
12. Search forgives. Typos, plurals and empty results get suggestions instead of a dead end.
13. Help sits in the same place everywhere. Contact options and help links appear in the same relative order on every page, as WCAG 2.2 criterion 3.2.6 asks.

Forms and input

14. Every field has a visible label. Placeholder text alone disappears as soon as someone types. WCAG criterion 3.3.2 asks for labels or instructions wherever input is needed.
15. Errors say what happened and how to fix it. Messages sit next to the field and in a summary at the top, in plain words. The GOV.UK Design System guidance on error messages is a good model.
16. An error never clears the form. Everything the user typed is still there after a failed submit.
17. Nothing has to be typed twice. Information already given earlier in a process is filled in or offered again, as WCAG criterion 3.3.7 requires.
18. Inputs fit the data. Number fields open a numeric keyboard, dates have a clear format, and browser autofill works for names, emails and addresses.
19. Long forms are broken up. Split them into short steps. The GOV.UK Design System recommends starting with one question per page, which helps people focus.
20. Destructive actions are confirmed or can be undone. Deleting a project or cancelling a plan asks once, clearly, or offers an undo.

Content and feedback

21. Every action gets feedback. Saving, sending and loading each show a visible state, so nobody clicks twice to check.
22. Buttons say what they do. "Send invoice" tells people more than "Submit". Users should be able to predict the result before they click.
23. Messages avoid jargon and codes. No raw error codes or internal terms appear in anything a customer reads.
24. Notifications link to the thing they mention. An email about a comment opens that comment, not the dashboard.
25. Formats follow the user's settings. Dates, time zones and units match the user's region, and every price states its currency.
26. Loading, empty and error states are designed. None of them shows a raw default, an endless spinner or a blank page.

Accessibility

These checks follow WCAG 2.2 at level AA. The W3C's Easy Checks make a quick first pass, but the W3C itself says they are not a full evaluation.

27. Text has enough contrast. Body text reaches at least 4.5:1 against its background (criterion 1.4.3), and icons, borders and focus indicators reach 3:1 (1.4.11).
28. Everything works with a keyboard. Tab through every core task with no mouse (2.1.1) and check that focus is always visible (2.4.7).
29. Focus is never hidden. Sticky headers, cookie banners and chat widgets never completely cover the element that has focus (2.4.11).
30. Meaningful images have text alternatives. Icons that act as buttons and charts that carry data have a text equivalent (1.1.1).
31. Pages reflow and resize. At 320 CSS pixels wide nothing needs sideways scrolling (1.4.10), and text can be enlarged to 200% without breaking the layout (1.4.4).
32. Targets are big enough to tap. Pointer targets are at least 24 by 24 CSS pixels (2.5.8). Android's guidance recommends at least 48 by 48 dp for touch, and primary actions deserve the larger size.
33. Headings give the page a structure. A screen reader user can jump from heading to heading and understand the outline of the page.

Performance

Google's Core Web Vitals give clear thresholds, measured at the 75th percentile of page loads on mobile and desktop.

34. The main content loads fast. Largest Contentful Paint happens within 2.5 seconds.
35. The interface responds quickly. Interaction to Next Paint is 200 milliseconds or less.
36. Nothing jumps while loading. Cumulative Layout Shift is 0.1 or less, so buttons do not move as people reach for them.

Conversion and trust

37. Pricing answers the obvious questions. What it costs, what is included and how to cancel are clear before sign-up.
38. Each screen has one primary action. The main button stands out, and competing buttons are visibly secondary.
39. Reassurance sits where people hesitate. Security, privacy and refund details appear next to payment and data-entry steps, not only in the footer.
40. Every big drop-off has a named cause. For the steps where most users leave the funnel, you can point to a UX reason, or you have a test planned to find one.

UX audit template: score and rank what you find

A list of failed checks is not yet a plan. Record each one in a UX audit template like the one below, score it, then sort. We score three things from 1 to 3 and multiply them, which keeps the math simple enough for any spreadsheet.

• Severity: 3 blocks a core task or excludes some users, 2 slows people down or confuses them, 1 is cosmetic.
• Reach: 3 affects most users, 2 affects one segment, 1 affects few people.
• Ease: 3 is a quick change, 2 takes a few days, 1 is a project.

Priority is severity times reach times ease, so it runs from 1 to 27. Work from the top. Treat accessibility failures on core tasks as top priority whatever they score, because they lock people out completely.

Turning the audit into fixes

Share the top ten findings first, each with its evidence, score and suggested fix. Split them into quick changes the team can ship in the next sprint and larger problems that need design work. For the larger ones, plan a short design pass rather than a patch; our page on SaaS design services explains how we approach that work. Retest each fix against the same check, and rerun the full UX audit after major releases or when a key metric drops.

When an audit is not enough

An audit is an informed estimate of where users struggle. It cannot tell you why a particular customer gave up, or whether a fix really works for people who rely on assistive technology. When findings conflict, or the stakes are high, test with real users. Website usability testing with a handful of people from each user group shows which findings are real and how much each one hurts.

Accessibility can also be a legal duty. In Ontario, the AODA has required businesses and non-profits with 50 or more employees to make their public websites meet WCAG 2.0 level AA since January 1, 2021. Live captions and pre-recorded audio descriptions are exceptions. If that applies to you, give the accessibility checks a full review with assistive technology, not just this list.

Frequently asked questions