SaaS UX audit checklist

What is in the checklist? An eleven-page PDF with 64 checks for SaaS products, grouped into eight sections. Every check is written as a statement you can mark pass or fail. Each one comes with how to test it, plus the WCAG 2.2 success criterion or usability heuristic behind it. Section Checks Examples Sign-up and onboarding 8 Password managers can paste. Onboarding resumes at the same step. Activation and first value 6 Steps to the activation event are counted. Empty accounts offer sample data. Navigation and information architecture 8 Labels match customer words. Deep links reopen the same view. Forms and validation 9 All errors show at once. The first error is focused and fully visible. Empty, loading and error states 7 Offline submits keep the input. Status messages are announced. Settings, roles and billing 8 The next charge date is visible. Cancelling takes no more steps than signing up. Accessibility spot checks, WCAG 2.2 AA 10 Keyboard only, focus not obscured, contrast, 24-pixel targets, reflow at 320 pixels. Mobile 8 Sticky bars never cover fields. The right keyboard opens for each input. The eight sections of the SaaS UX audit checklist, version 1.1. The PDF also has a how-to page, the severity definitions used for failures, a notes area per section, a results summary and a sign-off table. Who is it for? Product managers, designers and founders of SaaS products who want a structured pass over the flows that decide trials and retention. QA leads can use the forms and accessibility sections as a release check. It works on a live product, a staging build or a clickable prototype. Prototype reviews skip the checks that need real data. How do you use it? Pick three to six tasks that matter to the business, such as sign-up, first project and inviting a teammate. Prepare one test account per role, plus a brand-new account for the sign-up and empty-state checks. Test at 390 and 1440 pixels, then do one pass on a real phone. Emulation misses on-screen keyboards and slow processors. Mark each check Pass, Fail or N/A. A check passes only when you actually ran the test. Log every failure as a finding with evidence and a severity. Then prioritize the findings into a backlog. The UX audit report and backlog template has the ledger and the priority rule for that last step. Our guide on how to prioritize UX audit findings walks through it with a real example. Why is every item phrased as a test? “Onboarding should be simple” cannot fail, so it cannot guide a fix. “Leaving onboarding and returning resumes the same step” can fail, and the test tells you how to check it. That makes results comparable between reviewers and between releases. Several checks come from our own sample audit. Running the brief form on w3experts.com, we found a focused field hidden under a sticky header after a failed submit. That is check D5 and check G3 in this list. The guide on how a UX audit works shows that audit in full. What does the checklist not cover? It finds likely problems. It does not replace usability testing with people who use your product. Passing the accessibility section is not a WCAG conformance claim. A claim needs every page and state reviewed. It does not cover pricing strategy, marketing pages or growth experiments. Want the review done for you, with a scored backlog at the end? See our UX audit service. When the failures point at the product model rather than single screens, SaaS product design and UI/UX design take it from there.