Insights
A 40-check SaaS UX audit checklist for onboarding, your core workflow and billing, with the standards behind each check and how to rank what you find. To audit your SaaS product's UX yourself, choose one journey in each area (onboarding, your core workflow, billing), walk it as every role that uses it, and test each st
Insights · Checklist
Last reviewed October 5, 2026.
To audit your SaaS product's UX yourself, choose one journey in each area (onboarding, your core workflow, billing), walk it as every role that uses it, and test each step against the 40 checks below. Write down what you saw, who it affects and how sure you are. Have at least two people do it separately.
How do I run a UX audit of my SaaS product myself?
Set the scope before you open the product. A review of "everything" produces a long list that nobody can rank. Pick the journeys where friction costs you most: the path from sign-up to a first useful result, the one workflow your customers pay you to support, and the path from choosing a plan to leaving it. Support tickets and sales-call notes tell you where to start.
Then set up three things.
- Roles. Walk every journey as each role that uses it: an account owner, an invited colleague, a person with restricted permissions, and whoever handles billing. Some defects exist for one role only.
- Realistic data. Use a test account with the volume and mess a real customer has, not a clean demo. Tables with five rows hide problems that tables with five thousand rows show.
- Two reviewers, working separately. Compare notes only after both are done. In a 2003 review of eleven studies, Hertzum and Jacobsen found that the average agreement between any two evaluators using the same usability evaluation method ranged from 5% to 65%, so one reviewer's list is a partial one. Nielsen and Molich's original heuristic evaluation experiments had the same shape: individual evaluators found between 20% and 51% of the known problems, and pooling the findings of three to five did much better.
The checks draw on three kinds of basis. Some come from published standards or documentation, which are linked in the check. Some come from the ten usability heuristics that Nielsen refined in 1994 from a set of real usability problems. The rest are practice: reasonable things to look for that no standard requires. Treat those as prompts for judgment rather than pass or fail rules.
Mark each check Pass, Fail or Not applicable, and add a note for every Fail: the screen, the role, what happened. A check that fails for one role is still a fail.
Onboarding: can a new user reach a first result? (checks 1 to 12)
Walk sign-up through to the first moment the product does something useful, once as the person who creates the account and once as someone who was invited into it.
| # | Check | Pass when |
|---|---|---|
| 1 | The first result is clear | A reviewer who has never seen the product can say in one sentence what to do first, and the screen after sign-up points to it |
| 2 | Sign-up asks only for what the first session needs | You can state why each required field is there; profile and company questions that can wait are deferred |
| 3 | Password rules follow current guidance | Password managers and autofill work and pasting is allowed, there are no character-mix rules, a show-password option exists, and common or breached passwords are rejected. NIST SP 800-63B-4 requires support for password managers, bans composition rules and requires a blocklist, and recommends allowing paste and offering a show-password option |
| 4 | Sign-in does not rely on memory or puzzles alone | Nobody has to remember a password by memory alone, transcribe characters or solve a puzzle unless an alternative or an assisting mechanism (such as a password manager or paste) is available; see WCAG 2.2 criterion 3.3.8 |
| 5 | Information given once is reused | Name, email and workspace details entered in one step are not asked for again in a later step or in the invite flow (criterion 3.3.7) |
| 6 | Verification and invite links behave | The link works on the first click, an expired link says so and offers a new one, and the person lands where they were heading |
| 7 | Invited people see the right context | An invitee sees the workspace name, who invited them and their role, not an empty "create your account" experience |
| 8 | Roles are explained before they are assigned | An admin can see what each role can and cannot do before choosing one |
| 9 | Empty screens say what belongs there | Each empty state explains what will appear, why it is empty, and offers the one action that fills it; any sample data is clearly labeled as sample |
| 10 | Setup shows progress | A person can tell what is done and what remains, and long jobs such as imports show their status (Nielsen's heuristic of visibility of system status) |
| 11 | Setup can be left and resumed | Leaving midway and returning puts the person back where they stopped; any tour can be dismissed and reopened |
| 12 | Form errors say what to do | Each error appears next to its field, names the problem and the fix, keeps what the person typed, and is also listed at the top of the page (GOV.UK Design System; WCAG 3.3.1 and 3.3.3) |
Core workflow: can each role finish the job? (checks 13 to 28)
Choose the workflow customers rely on most, such as creating and approving a request, building a report, or managing a record through its life. Walk it end to end for each role, with realistic data.
| # | Check | Pass when |
|---|---|---|
| 13 | Each role can finish the task | Every role you test reaches the end without leaving the product, asking a colleague or contacting support |
| 14 | Each screen has one obvious primary action | A first-time user can point to the next step on every screen of the workflow |
| 15 | Labels use the customer's words | Buttons, statuses and fields use the terms your customers use, not internal or database names (Nielsen's heuristic of matching the system to the real world) |
| 16 | Location and return paths are clear | The person can tell where they are, and going back to a list keeps their search, filters and place in it |
| 17 | State and ownership are visible | Each record shows its state in words, who holds it and what happens next, including at hand-offs between people such as assign or approve |
| 18 | Saving is unambiguous | The person can tell whether a change is saved, a failed save is announced, and leaving with unsaved changes warns them |
| 19 | Mistakes can be undone or canceled | Canceling leaves no half-finished data, and reversible actions can be reversed (Nielsen's heuristic of user control and freedom) |
| 20 | Irreversible actions name what they affect | A confirmation states what will change or be removed, with counts where relevant; submissions that change legal, financial or user data can be checked, confirmed or corrected (WCAG 3.3.4) |
| 21 | Permissions are visible before they fail | A control a role cannot use is hidden or explained, rather than failing after the click; each role sees only the data it should |
| 22 | Every main screen has all its states | Empty, loading, error and partial-data states each exist for the screens in the workflow, and each says something useful |
| 23 | Lists and tables hold up at real volume | Search, filter, sort and bulk actions work with hundreds or thousands of rows, and active filters are visible and easy to clear |
| 24 | Interactions respond quickly | Common actions answer promptly on realistic data; Google's Interaction to Next Paint guidance rates a page's responsiveness good at 200 milliseconds or less, measured from an interaction to the next frame shown at the 75th percentile of page loads (it does not time how long a task takes to finish), and slower operations show progress |
| 25 | The workflow works from the keyboard | You can complete it without a mouse, the focus indicator is visible (2.4.7) and a sticky header or banner does not completely hide the focused item (2.4.11) |
| 26 | Text and targets are readable and hittable | Text meets a 4.5:1 contrast ratio, or 3:1 for large text (1.4.3) and targets are at least 24 by 24 CSS pixels or spaced to compensate (2.5.8) |
| 27 | Notifications are specific and linked | An email or in-app notice says what happened, to what, and links to that exact item; people can control which ones they get |
| 28 | Help is in the same place every time | A help or contact option sits in a consistent location across pages (3.2.6), and rules that confuse people are explained where they apply |
Billing: can a customer pay, change plan and leave without asking for help? (checks 29 to 40)
A confusing billing screen can turn directly into a support ticket, a chargeback or a complaint, so billing deserves its own pass. Walk it as a new buyer, as an existing customer upgrading and downgrading, as someone whose card has failed, and as someone trying to cancel.
A note on law before the checks. In the United States, the Restore Online Shoppers' Confidence Act requires sellers who charge consumers online under a negative option feature (such as automatic renewal) to disclose the material terms clearly before taking billing information, obtain express informed consent before charging, and provide a simple way to stop the recurring charges. A 2022 FTC staff report described hard-to-find cancellation paths and fees hidden until late in a purchase among the practices it called dark patterns. In the EU, Directive (EU) 2023/2673 adds a clearly labeled withdrawal function for consumer distance contracts concluded online that carry a statutory right of withdrawal, applying from June 19, 2026; it is a withdrawal-right function, not a general cancellation button. These rules are written about consumers, so they may not cover a product sold only to businesses, and which apply to you is a question for your lawyer. The checks below treat the same behaviors as usability questions that matter either way.
| # | Check | Pass when |
|---|---|---|
| 29 | Plans match everywhere | Plan names, limits and prices are identical on the pricing page, in the product, at checkout and on invoices |
| 30 | The cost is clear before card details | The price, billing period, how renewal works and any usage-based charges are visible before payment details are requested |
| 31 | Recurring charges need clear consent | The buyer is told that charges repeat and agrees to that specifically; a trial states when it ends and what is charged then |
| 32 | Upgrades preview the change | Before confirming, the person sees what changes, what they will be charged today and when the next charge falls |
| 33 | Downgrades and seat removals say what is lost | Features, data or seats affected are listed before confirmation, with no dead end afterward |
| 34 | Billing roles are clear | It is obvious who can change billing, and a person without permission who hits a paywall can see whom to ask |
| 35 | Payment methods can be updated without support | A customer can change a card or billing address from the account area; Stripe's customer portal documentation shows this pattern, including updating tax IDs |
| 36 | Failed payments are handled in the open | The customer is told by email and in the product what failed, when the next attempt will happen and how to fix it, and what access they keep meanwhile; retries and failure emails are settings in billing platforms such as Stripe, so check what your own configuration does |
| 37 | Invoices are usable by finance teams | Invoices and receipts can be downloaded, and the customer can edit the legal entity name, address, tax ID and purchase order number |
| 38 | Limits warn before they block | A person approaching a plan or usage limit is warned, and the screen that stops them explains the limit and the options |
| 39 | Cancellation is self-serve and specific | It can be started from the account area without contacting anyone, says when access ends and what happens to data, and offers an export |
| 40 | Billing changes are confirmed in writing | Each plan change, cancellation and renewal produces a confirmation, and annual renewals or price changes are announced before they occur |
How do I turn 40 checks into a ranked list?
A list of Fail marks is not a plan. Convert each Fail into a finding with the same fields, so the findings can be compared:
| Field | What to write |
|---|---|
| Observation | What you saw, on which screen, as which role |
| Evidence | How you know: your own walkthrough, a support ticket, a recording, analytics. Say how many |
| Consequence | What can go wrong for the customer or the business |
| Confidence | High, medium or low, and why |
| Next step | Fix, investigate, test with users, or accept with a reason |
| Owner | One named person or team |
Rank by consequence and confidence together. A high-consequence finding backed by thin evidence calls for a quick check with real users before anyone redesigns anything. A high-confidence finding with a small consequence can wait in the backlog. Avoid collapsing the fields into one numeric score: a number looks more precise than a two-person walkthrough can support.
An illustration of one finding, written the way it should read: Observation: on the plan-change screen, an account owner cannot see whether removing seats takes effect now or at renewal (checks 32 and 33). Evidence: both reviewers, one support ticket. No frequency data. Consequence: a customer may be billed for seats they believe are gone, which could lead to a dispute. Confidence: medium. Next step: show the effective date and the amount before confirmation, then watch billing-related tickets afterward. Owner: the billing product owner.
If you are unsure whether the next step should be a review against heuristics, user testing or a broader audit, this comparison of the three explains what each can answer.
What can a self-audit not tell you?
A checklist finds what the checklist asks about. It cannot show how often a problem occurs, how customers actually think about the task, or whether a defect is a local screen problem or a symptom of a product rule that is unresolved or invisible. Your team's familiarity with the product also works against you: people who built a workflow can overlook the steps they now take for granted. And a Pass on a check says the behavior exists, not that customers can use it.
A self-audit is the right tool when the symptoms are visible and you can name the workflow. It is a weaker one when stakeholders disagree about the cause, when the same friction keeps returning after fixes, or when you need a written record of findings and owners. In that situation, Tcules's UX Product Audit examines representative workflows, roles, states and implementation evidence, and delivers a finding-to-decision ledger with consequence, confidence, owner and a validation step for each finding. If you already know what needs to change, commission that work instead of another audit.