Your SaaS Looks Polished. So Why Are Users Still Getting Lost? Run This UX Audit

A SaaS UX audit is a structured review of whether real users can finish real jobs inside your product. It measures task completion, error recovery and time-to-value, not visual quality. The output is a ranked list of usability defects, each with a severity score, a frequency estimate and a fix.

Visual polish and usability are separate properties. Teams buy the first because it is visible in a design review. Nobody presents a slide saying "our users can't find the export button." They present the dashboard, everyone nods, and support keeps answering the same four questions.

So audit against tasks. Not screens.

What is a SaaS UX audit, and what is it not?

A UX audit is a diagnostic. It identifies where users fail, how often, and what that costs. It is not a redesign, not a brand refresh, and not a design-system project. Those are treatments. An audit is the examination telling you which treatment you need.

Someone asks for an audit and gets a mood board with a new colour ramp that never says which task fails, or for whom. An audit produces evidence; a redesign consumes it. When we scope UI/UX design work on a live product, the audit stays a separate phase with its own deliverable.

How do you pick the tasks worth auditing?

Pick five jobs that carry activation and renewal: the first-value job, the daily-driver job, the invite-and-permissions job, the billing or upgrade job, and the get-my-data-out job. Score each on revenue impact and frequency. Anything outside the top five waits for the next round.

That fifth job gets skipped because nobody demos plumbing. It surfaces in cancellation calls as "we could never get our numbers out." A dashboard where export hides behind a kebab menu inside a modal is a failed product for the finance manager who needed a CSV before a board meeting.

What should you measure in first-run and onboarding?

Measure time-to-first-value: how long from signup to the first output the user considers useful. Count the steps, integrations and permissions required before that moment arrives. Check every empty state for a next action. Confirm onboarding survives a pause and resume without losing what was already entered.

The setup wall kills trial conversion. Connect your calendar, your CRM, import contacts, invite two teammates. Only then does anything happen. Each step is defensible alone. Stacked, they're a wall. Segment your own cancellations by whether the account ever reached first value, and the setup wall stops being a design opinion and becomes a churn number you can put in front of finance.

"No projects yet" is not a next action. Working through AI chat interface patterns taught us the blank prompt box is the hardest empty state in software: nobody knows what to type.

Can people find things without using search?

Information architecture is measured by prediction, not appearance. Run a tree test and a first-click test across your five tasks: can a user say where a feature lives before clicking, and is the first click correct? Track how often people reach for search on core, repeated work.

Search dependency is a symptom that plenty of teams read as a success metric: heavy search on a daily task means people route around the navigation. The usual culprit is language. Labels carry the names of whoever built the modules. Entities. Workspaces. Resources. Users came looking for customers, projects and files. Then Settings becomes a junk drawer where billing, API keys and team roles share one flat list of 22 items.

How do you run the task-completion pass?

Give each participant the task as a goal, never as instructions, then stay quiet. Record whether they finish unaided, how long it takes, where they backtrack, and how confident they feel afterwards. Six to eight participants per role is enough to expose the failures that repeat.

The hint rule matters more than any score. Say "try the top right" and you've stopped auditing, started training. Jakob Nielsen has argued since 2000 that five users surface about 85% of a design's usability problems, so sample size is rarely what limits an audit. Rigour is. Completion with assistance is a failure, logged as a pass by teams who want good news.

What breaks in forms, errors and destructive actions?

Check three things. Forms: inline validation, sensible field order, no data loss on back. Errors: messages naming the field and the fix, in plain language. Destructive actions: a confirmation saying what will be deleted, plus an undo path wherever data can be restored.

Error copy is where a product reveals its manners. "Invalid input" tells the user they were wrong and nothing more. "Phone numbers need a country code, like +91" tells them what to do next and removes a support ticket permanently. More on that in designing AI error states, where the system can be confidently wrong rather than plainly broken.

Confirmation dialogs are weaker than undo: people click through them reflexively by the third time. Keep dialogs for irreversible actions, and test the back button mid-form.

Why is accessibility a usability problem, not a compliance checkbox?

WCAG 2.2 Level AA is the baseline: every function operable by keyboard, a visible focus indicator, contrast of at least 4.5:1 for normal text and 3:1 for large text and UI components, correct labels for screen readers, and targets of at least 24 by 24 CSS pixels.

Run the keyboard pass first: an afternoon's work, and it finds the most. Unplug the mouse, tab through all five tasks, and you'll hit a dropdown that won't open, a modal that doesn't trap focus, and a focus ring somebody deleted in CSS because it looked untidy. WCAG 2.2 added a criterion for focus obscured by sticky elements, the exact bug sticky headers cause.

None of this is charity. The same defects hurt the power user on a trackpad in a moving train. Scanners catch contrast and missing alt text; none tells you your table reads as gibberish.

Does performance count as UX?

Yes. A slow screen is an unusable screen. Google's Core Web Vitals thresholds are LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, assessed at the 75th percentile of real users. INP replaced FID as the responsiveness metric in March 2024.

The authenticated app gets a pass for being "behind the login," with its 4,000-row table and a filter that re-queries on every keystroke. Users don't grant that exemption. The limits have held since R. B. Miller's 1968 work on man-computer conversational transactions, and Nielsen Norman Group's summary of them puts 0.1 seconds as the ceiling for feeling instantaneous and 1 second as the point where a user's train of thought breaks. Past that, lag becomes distrust: the double-click, the duplicate record. The commercial side is in Core Web Vitals and revenue, and the fix starts with testing throttled, on a mid-range Android.

What does the data tell you that interviews don't?

Analytics tell you what happened and how often: funnel drop-off, rage clicks, dead clicks, repeat trips to settings, internal search queries. Interviews and moderated sessions tell you why. Quantitative data sizes a problem, qualitative research explains it, and running one alone leaves you half a finding.

Your internal search log is the cheapest research artifact you own. If 300 people searched "cancel subscription" last month, you don't need a workshop to interpret that.

Support tickets behave the same way once you tag them by task instead of by module. "Billing" splits into "can't change the card on file" and "invoice missing GST number," one of which is a five-hour fix. The reverse trap is as common: a recording shows an eight-second pause, and only asking tells you whether that was confusion or a colleague walking over.

How do you turn findings into a prioritised backlog?

Rank by severity multiplied by frequency, not by opinion. Score severity 1 to 4, where 4 blocks the task outright and 1 is cosmetic. Score frequency as the share of sessions hitting it. Multiply, then break ties with fix cost.

Without a formula, priority defaults to whoever spoke last, and a founder's dislike of a button colour outranks a blocker 40% of trial users meet on day one.

Anything causing data loss goes to the top regardless of frequency, because a rare catastrophe is still a catastrophe. Anything fixable in under two hours ships next sprint, because clearing 15 small annoyances is more visible than one large refactor.

The SaaS UX audit checklist

1. Name the five tasks carrying activation and renewal.
2. Create a fresh account with no seeded data, then measure time-to-first-value.
3. List every integration and permission demanded before the product is useful.
4. Check each empty state names a next action, and onboarding survives a resume.
5. Run a first-click test on all five tasks.
6. Compare nav labels against what users type into search.
7. Run moderated sessions, six to eight per role, silently.
8. Record completion, time, errors, recovery, confidence and interventions.
9. Log any task finished only after a hint as a failure.
10. Walk each form by keyboard, hit back mid-flow, check for data loss.
11. Rewrite every error message so it names the field and the fix.
12. Confirm destructive actions say what's deleted and offer undo.
13. Check focus visibility, modal focus traps, contrast at 4.5:1 and 3:1.
14. Test your two busiest screens with a real screen reader.
15. Measure LCP, INP and CLS on authenticated screens, throttled.
16. Pull drop-off, rage clicks, search logs, and tickets tagged by task.
17. Score findings on severity and frequency, sort, and assign owners.
18. Re-run the five task sessions after the fixes ship.

Where do you start this week?

Take one task. The export one. Ask someone outside your team to get last month's data out, then say nothing for five minutes. Whatever happens next is your first finding. If you'd rather have the whole pass run properly, book a call and we'll scope the five tasks with you. There's a 7-day free trial on new engagements.

Frequently Asked Questions

How long does a SaaS UX audit take?

A focused audit across five tasks runs two to three weeks: a week to recruit and write scripts, a few days of sessions, then analysis and scoring.

What's the difference between a UX audit and usability testing?

Usability testing is one method inside an audit. A full audit adds heuristic review, accessibility checks, performance measurement and analytics, then merges everything into one prioritised list. Testing shows where people struggled; the audit tells you what to do about it.

How many users do we need to test with?

Six to eight per distinct role. An admin, an everyday user and a viewer are three different products behind one login. Recruiting 40 rarely surfaces new problems, just the same ones more expensively.

Can we audit a product that hasn't launched?

Yes, against a prototype, though you lose the analytics half. Task sessions, IA testing and accessibility review work on a clickable prototype. Drop-off and performance need real users, so plan a lighter pass after launch.

How often should we re-run it?

Re-test the five core tasks after any release that touches them, and run a full pass once or twice a year. Products drift: features get added at the edges until navigation built for eight modules is carrying nineteen. Keep one engineer and one support person watching sessions live. Nothing ends the argument about whether a problem is real like watching three people fail the same step.