UX Audit Checklist: 60 Checks for Web Apps and SaaS Products

Most UX checklists are organized by heuristic: visibility of system status, consistency, error prevention. That's useful for learning, but awkward for fixing, because one heuristic touches every screen and no one owns 'consistency'. This checklist is grouped by the journeys users actually take through a SaaS product, so a failed check lands on a specific flow and a specific person.

What should a UX audit checklist include?

A UX audit checklist should include checks for every journey a user takes, in the order they take them, plus cross-cutting checks for errors, feedback and accessibility. For a typical SaaS product that's signup, onboarding, the core task, navigation and search, settings, and billing.

Each check is a yes-or-no question about the product, phrased from the user's point of view. A 'no' becomes a finding with a severity and a fix. If you're new to audits, our UX audit guide explains how the checklist fits into the full process and what the final deliverable should look like. For the principles behind many of these checks, see our walkthrough of heuristic evaluation on a real SaaS app.

How do you run a UX audit with this checklist?

Run the checklist by completing each journey as a new user, answering every check as you go, and logging failures immediately with a screenshot. It takes discipline to stay in the user's shoes, so set up the session before you start.

1. Create a brand-new account with a fresh email. Don't use your admin or seeded test account.
2. Pick the user type you care most about, such as a new trial user on a team plan.
3. Walk each journey on desktop, then repeat on a phone-sized screen.
4. Mark each check as pass, fail or not applicable. For each fail, write the screen, the problem and a first idea for the fix.
5. Rate each failure for severity and effort, then merge duplicates that share a root cause.
6. Compare your findings with real behavior in analytics or session replays before you present them.

Which signup and onboarding checks matter most?

The signup and onboarding checks that matter most are the ones about effort and clarity: how many fields a user fills before seeing value, and whether they know what to do next on every screen. Problems here hit every new user, so they usually rank highest.

Signup (8 checks)

• Can a user tell what the product does and who it's for from the signup page alone?
• Is signup limited to the fields you truly need now?
• Are password rules shown before the user types, not after a failed attempt?
• Does social or single sign-on work, and is it offered where your users expect it?
• Is email verification non-blocking, or clearly explained if it blocks access?
• Do validation messages appear inline, next to the field, in plain language?
• Does the signup flow work fully on a phone, including any verification step?
• Is it clear what happens after signup: trial length, card required or not, next step?

Onboarding and first run (8 checks)

• Is there one clear first action that leads to the product's main value?
• Can users skip optional setup and return to it later?
• Do empty screens explain what goes there and offer one button to fill them?
• Is sample or template data available so the product doesn't look broken?
• Are setup questions explained, with sensible defaults prefilled?
• Does progress through setup show how many steps remain?
• Can a user invite teammates without leaving their current task?
• Is help reachable from the first screen without opening a new tab?

What should you check in the core task flow?

In the core task flow, check that users can start, complete, save and find the result of the main job your product does, without guessing. This is where your product earns retention, so even medium-severity issues here deserve attention.

• Is the primary action on each screen visually obvious and labeled with a verb?
• Do labels use the user's words rather than internal names for features?
• Does the system confirm when work is saved, and is autosave behavior clear?
• Can users undo or reverse the most common destructive actions?
• Do long operations show progress and let users keep working?
• Are loading states distinct from empty states and error states?
• Can users find work they created yesterday within a few seconds?
• Do defaults match what most users choose?
• Is the flow usable with keyboard shortcuts for frequent actions?
• Does the result of the task match what the user expected before starting?

If your core task involves AI, add checks for confidence, review and undo. Our UX readiness checklist for adding AI to a SaaS product covers those in depth, and web app performance checks for dashboards cover the speed side of this journey.

Which navigation, search and settings checks should a web app audit include?

A web app audit checklist should test whether users can always tell where they are, get anywhere in a few steps, and change their own settings without contacting support. These checks often reveal inconsistency that has built up as features were added.

Navigation and search (7 checks)

• Does every screen show where the user is, with a clear page title and active nav state?
• Is navigation grouped by user goals rather than by internal team structure?
• Is search available where users expect it, and does it tolerate typos?
• Do filters show which are active and make clearing them easy?
• Do links and buttons behave consistently (links navigate, buttons act)?
• Does the back button behave as expected, including after filters and modals?
• Is there a way to reach any page in three steps or fewer?

Settings and account (7 checks)

• Are settings grouped by what users want to change, with clear section names?
• Does each setting explain its effect, especially if it affects teammates?
• Is it clear when a setting saves (instantly or on a save button)?
• Can users manage team members and roles without support?
• Are permission errors explained, with who to ask for access?
• Can users export their data in a usable format?
• Is account deletion findable, with consequences explained before confirming?

What should a SaaS UX checklist cover for billing and plans?

A SaaS UX checklist should cover the full billing journey: seeing the current plan, understanding usage, upgrading, downgrading and canceling. Billing is often skipped in audits, yet confusion here directly affects revenue and support load.

• Can users see their current plan, price and renewal date in one place?
• Is usage against limits visible before users hit the limit?
• When a limit is reached, does the message explain what happened and how to continue?
• Does the upgrade flow show exactly what changes and what it costs today?
• Are downgrade consequences (lost features, data kept or removed) stated before confirming?
• Is cancellation findable without contacting support?
• Are invoices and receipts downloadable without a support request?
• Do failed payments produce a clear, non-alarming message with one way to fix it?

Our guide to in-app billing and upgrade UX shows patterns for each of these, including paywalls and usage meters.

Which error, feedback and accessibility checks apply everywhere?

Error, feedback and accessibility checks apply to every journey, so run them as you go rather than as a separate pass. When these fail on many screens, the fix usually belongs in shared components.

• Do error messages say what went wrong and how to fix it, without blaming the user?
• Does entered data survive an error, so users don't retype everything?
• Are success messages specific ('Invoice sent to finance@acme.com') rather than generic?
• Are destructive actions confirmed with the specific consequence named?
• Do offline or timeout states explain what happens to unsaved work?
• Is text contrast sufficient against its background throughout?
• Can every interactive element be reached and used with a keyboard?
• Is the keyboard focus always visible?
• Do all form fields have visible labels, not just placeholders?
• Do icons that act as buttons have accessible names?
• Is information never conveyed by color alone?
• Does the layout work when text is zoomed to 200%?