Founders often use the two names for the same thing on a first call: "we need someone to test our UX". They answer different questions. A UX audit asks what is wrong with the product, judged against what we know works. Usability testing asks what happens when a real person tries to use it. Pick the wrong one and you spend three weeks learning something you could have learned in three days.
The short answer
A UX audit is an expert review. An experienced designer goes through your product against established usability principles, your analytics and patterns from similar products, and hands you a ranked list of problems with fixes. It is fast, it covers the whole product, and it finds most of the obvious and many of the subtle issues.
Usability testing is observation. You watch five to eight real users try to complete real tasks, and you note where they hesitate, misread or give up. It is slower and narrower, but it finds problems no expert predicts, and it gives you evidence that ends internal arguments.
Rule of thumb
Audit first when you suspect many problems and have little time. Test first when one flow matters more than everything else and the team disagrees about it.
What a UX audit actually is
Most audits are built on a heuristic evaluation: checking every screen against usability principles such as Jakob Nielsen's ten heuristics, which have been the standard reference since 1994. Visibility of system status, error prevention, consistency, recognition rather than recall. On its own that is a checklist exercise.
What turns it into a useful audit is the context around it. I start with your funnel data in Mixpanel, Amplitude or Hotjar to see where people actually drop off, then spend most of the time on those flows. I add a pass for visual consistency, accessibility and design system health, because inconsistency is usually the first sign of a product that grew faster than its design.
The output is a ranked list. Each finding names the screen, what is wrong, the evidence, a severity, the effort to fix and the fix itself. You can see the full list of what I check in my SaaS UX audit checklist.
What usability testing actually is
You give a participant a realistic task, such as "invite a colleague and assign them the March report", and ask them to think aloud while they do it. You do not help. You watch where they click, what they say, and how long it takes.
There are two common formats. Moderated sessions run live over a video call, so you can ask follow-up questions. Unmoderated sessions use a tool that records the participant on their own, which is cheaper and faster but loses the "why".
Five participants per round is the usual number for one type of user. Nielsen's research showed that five people uncover most of the problems in the flows you test, and that you learn more from three rounds of five than one round of fifteen. The slow part is recruiting. For B2B SaaS your users are busy professionals with specific jobs, so the best recruits are usually your own trial users and customers.
UX audit vs usability testing, side by side
| UX audit | Usability testing | |
|---|---|---|
| Question it answers | Where does the product break good practice, and what is it costing us? | Can real users complete this task, and where do they get stuck? |
| Who judges | An experienced product designer | Your users |
| What you need | Product access and your analytics | Participants, tasks, and a prototype or the live product |
| Typical time | One to two weeks | Two to four weeks, most of it recruiting |
| Coverage | The whole product | The two or three flows you test |
| Evidence | Expert judgement backed by your data | Direct observation, clips and quotes |
| Best for | Low activation with no clear cause, before a redesign, after a year of fast feature work | High-stakes flows, new concepts, settling a team debate |
What each one misses
An audit predicts, it does not prove. An expert knows that a twelve-field signup form loses people, but cannot know that your clinic receptionists fill it in with a queue of patients in front of them, one hand on the phone. Domain context like that only shows up when you watch real users.
Testing misses everything outside the tasks you wrote. Five people completing onboarding will tell you nothing about your settings page, your billing flow or the empty state a user sees on day three. It also misses problems users tolerate but that still cost you: slow paths, inconsistent patterns, missing keyboard support. Participants in a test also try harder than they would at their desk, so a flow that "passed" can still leak in real life.
Which one to run first
- Trial-to-paid or activation is low and you do not know why: audit. The data tells you where, the audit tells you what.
- The team is split on one flow, for example a setup wizard versus an empty dashboard with prompts: test both versions with five users each.
- You are about to redesign: audit first so the redesign fixes the right things, then test the new prototype before it is built.
- Pre-launch, no users yet: test a clickable prototype with five people who match your ideal customer. An audit of an unlaunched product has no data to stand on.
- Large customers complain on sales or renewal calls: test with those customers in their own accounts.
How I combine them
When a client can afford both, I run them in this order: audit, fix the obvious, test the riskiest flow, fix again, measure. Testing a product full of obvious problems wastes your participants. If all five trip over the same unlabelled icon, you paid for five sessions to learn one thing an expert would have flagged in ten minutes. Clear the noise first and the sessions show you the problems only users can show you.
The audit alone is often enough to move the numbers. On The Kids Tales, the audit found where the subscription flow was losing people, and fixing those points lifted lifetime value by about 20 percent.
Questions founders ask
Is a heuristic evaluation the same as a UX audit?
A heuristic evaluation is one part of most UX audits. A full audit adds your analytics, a consistency and accessibility pass, and a ranked fix list your team can act on.
How many users do I need for usability testing?
Five per round for each distinct type of user. If you have admins and end users with different jobs, test five of each. Fix what you find, then run another round.
Can we run usability tests ourselves?
Yes. Write tasks as goals, not instructions, never help the participant, record every session, and make sure the people who design and build the flow watch at least two sessions live.
Does a UX audit replace user research?
No. An audit finds usability problems in what you have built. Research tells you what to build in the first place. They answer different questions.
If you want the audit done for you, my SaaS UX audit takes 7 to 10 business days and ends with a ranked fix list, Figma fixes for the top issues and a live walkthrough with your team.
