SaaS UX audits: what to review and what you should get back

A good audit gives you specific, prioritised findings you can act on. On its own, it does not give you certainty about user behaviour, and it should be honest about that difference.

When an audit is useful

• Support requests or sales feedback keep pointing to the same part of the product.
• Activation, or adoption of a feature, is lower than expected and the cause is unclear.
• You are planning a redesign and need to decide what to change first.
• The product has grown feature by feature and nobody has reviewed it as a whole.
• You have data, such as analytics or session recordings, but no one has had time to interpret it.

An audit is less useful when the problem is already well understood and the team simply needs design capacity, or when the real question is about pricing, positioning or missing features rather than the experience itself.

Three kinds of evidence

“Audit” is used for several different activities. They answer different questions, and the strongest audits combine more than one.

An expert review is often the quickest place to start. It usually draws on recognised principles, such as Jakob Nielsen’s 10 usability heuristics, together with knowledge of how B2B products are used. Its findings are informed judgements. Analytics and testing then show which of them matter most.

Bound the audit around a task

Reviewing a whole product at once tends to produce a long list of small issues. A tighter scope produces more useful findings. Define three things before starting:

1. The task. A specific job, such as “set up a workspace and invite the team” or “find an overdue invoice and send a reminder”.
2. The role. Who is doing it: a new admin, an experienced daily user, a read-only stakeholder. The same screens can work well for one and badly for another.
3. The outcome. What success looks like for the user and the business, such as completing setup without contacting support.

Then work through the task from start to finish with realistic data and the right permissions, including what happens when things go wrong.

What to review in a B2B product

Onboarding

Does a new user understand what to do first and reach something useful without help? Look at empty states, setup steps, sample data and how the product explains what each step is for.

Navigation

Can people find the area they need and tell where they are? Check whether labels use the words customers use, and whether related tasks sit near each other.

Core workflows

Can someone who does the main task every day complete it efficiently? Count the steps, look for repeated data entry, and check whether the product remembers sensible choices.

Tables and filtering

Can users find, compare and act on the records they need? Review search, filters, sorting, column choices and saved views, and how selection works, especially across pages.

Permissions

Does each role see what it should, and understand why something is unavailable? Look for actions that disappear without explanation, and errors that only appear after someone has done the work.

Feedback and system status

Does the product confirm what happened after an action, show progress for long-running work, and make it clear when data is saving, syncing or out of date?

Error recovery

When something fails, does the message explain what happened and what to do next? Can people undo destructive actions or recover work they had partly completed?

Accessibility

Can the task be completed with a keyboard alone? Is text readable, with enough contrast? Are form fields labelled and errors announced to assistive technology? The Web Content Accessibility Guidelines (WCAG) 2.2 are the reference standard.

A checklist to start with

Work through these questions for one task and one role. They are a starting point, not a complete audit.

• Can a new user tell what the task is for and where to begin?
• Do labels use the customer’s language rather than internal names?
• Is the current step, and overall progress, always clear?
• Are defaults sensible, and are earlier choices remembered?
• Does every action confirm what changed?
• Is it clear which records an action will affect before it runs?
• Can destructive actions be undone, or are they confirmed with specifics?
• Do empty, loading and error states explain what to do next?
• Does each role understand why an option is unavailable to them?
• Can the task be completed using only a keyboard?
• Can someone stop halfway and pick up where they left off?

A worked example: one finding

An admin console lists a company’s user accounts, 50 per page. An admin filters to inactive users, ticks “Select all” and chooses “Deactivate”. The filter matches 1,240 accounts.

Observation

“Select all” selects every account matching the filter, including those on other pages. The confirmation asks “Deactivate selected users?” without saying how many accounts are affected or that they extend beyond the visible page.

Evidence available

Expert review against two heuristics: visibility of system status and error prevention. Support tickets or audit logs could show whether accidental bulk deactivations happen; in this example they have not been checked.

Possible consequence

An admin intending to deactivate the 50 visible accounts deactivates 1,240, locking people out of the product. Restoring access takes time and support effort, and may not restore everything if deactivation removes settings.

Confidence

Medium. The interface clearly fails to communicate the selection scope, but how often this causes real mistakes is unknown.

Recommendation

After “Select all”, show “All 50 on this page are selected. Select all 1,240 matching users?” Put the exact count in the confirmation button, such as “Deactivate 1,240 users”, and offer undo once the action completes.

Validation

Check support tickets and logs for unintended bulk changes. Then test the revised pattern with a few admins doing a bulk task, and check they can say how many accounts will change before they confirm.

Written this way, the finding separates what was seen from what is inferred, and tells the team how to find out whether it matters.

What you should get back

A useful audit is more than a deck of annotated screenshots. Expect:

• Annotated findings, each tied to a specific screen and step in the task.
• Prioritisation, based on the effect on the task and the reviewer’s confidence, not only on how visible the issue is.
• Reasoning, so your team can understand and challenge each finding.
• Recommended actions, specific enough to estimate, with trade-offs noted.
• Open research questions: what the audit could not answer, and how to find out.

Agree in advance which of these you will receive and in what format. A shared document or annotated design file is often easier to act on than a presentation.

What an audit cannot tell you

An expert review can identify likely causes of friction. It cannot prove why customers churn, or guarantee that fixing an issue will improve conversion. Churn and conversion depend on pricing, product fit, sales, support and competition as well as usability.

Treat findings as well-reasoned hypotheses. Where a finding is important or expensive to fix, check it with data or user testing before committing significant development time.

Targeted fixes or broader discovery?

Targeted fixes are usually enough when findings cluster around particular screens or patterns, the underlying workflow makes sense to users, and changes can be made without restructuring the product.

Broader discovery may be needed when findings point to a mismatch between how the product is organised and how customers work, when different roles need fundamentally different things, or when the audit raises more questions than it answers. In that case the next step is research, then a scoped redesign. How to scope a SaaS redesign without rebuilding everything covers how to define that work, and How much does a SaaS product redesign cost? explains what drives its budget.