Sevginur Ak Parlak
May 12, 2026
13 min read
UX Audit for SaaS Products: How I Run One and What to Fix First
Most teams do not call me because the product is broken. They call me because the numbers are quietly wrong. Signups are fine, activation is not. Demos go well, week 2 retention does not. Support answers the same 3 questions every day. Nobody can point at the cause, because there is no single cause. There are 40 small ones.
A UX audit is how I find those 40 things and turn them into a short list you can actually ship. This post explains what a UX audit is, what I look at, how I score what I find, how long it takes and what it costs. I also included the checklist I use, so you can run a first pass yourself before you pay anyone.
What is a UX audit?
A UX audit is a structured review of a product against known usability principles, your own product data and the real behaviour of your users. The output is not an opinion about the interface. It is a prioritized list of problems, each one with evidence, a severity rating and a proposed fix.
3 methods usually sit inside a UX audit, and it matters which ones you are buying.
Heuristic evaluation. A designer reviews the product against usability heuristics like visibility of system status, user control, error prevention and consistency. It is fast, it needs no users, and it reliably finds the mechanical problems.
Behavioural review. We look at what people actually do: funnel drop off, session recordings, rage clicks, the screens where time on task explodes, the features nobody opens. This tells us where the problems are, while the heuristic pass tells us why.
Usability testing. 5 sessions with people who match your audience, watching them attempt the core task. This is the only method that catches the problems your team cannot see anymore, because you have all been looking at this product for 14 months.
An audit with only the first method is a checklist review. It has value and it is cheap, but it will miss the expensive problems. When I quote a UX audit, I always tell the founder which of the 3 methods is included, because that is the real difference between a $1,600 audit and a $12,000 one.
When does a SaaS product need a UX audit?
You do not need an audit because the interface looks dated. You need one when behaviour and expectation stop matching. These are the signals I see most often.
Activation is low while signups are healthy. People arrive, and something between the first screen and the first result stops them. This is the most common reason teams contact us, and the fix is almost never a redesign of everything.
Support keeps answering the same questions. Every repeated ticket is a sentence the interface failed to say. When I audit a product, the support inbox is usually the highest value dataset in the company, and almost nobody has read it as a design document.
Usage is concentrated in 20 percent of the product. You built 30 features and people use 6. Either the other 24 are not needed, which is a scope problem, or they are invisible, which is an information architecture problem. The audit tells you which.
Sales says the demo goes well and trials do not convert. In a demo, a human explains the product. In a trial, the interface has to do the same job alone.
You are about to redesign. This is the best moment for an audit and the one teams skip most. Redesigning without an audit means you rebuild the problems in a new visual style, at full cost.
You are moving from 1 user role to several. Adding an admin role or a team plan changes navigation, permissions and empty states everywhere. I would audit the current single role experience before adding the complexity.
What I look at in a SaaS UX audit
I review the product in 6 layers, in this order, because a problem in an early layer makes everything after it look worse than it is.
1. Acquisition and first impression
Does the landing page promise the same thing the product delivers? Mismatch here poisons every metric after it, and it shows up as a strong signup rate with terrible activation. I also check what happens before the account exists: is there a way to see the product working without giving an email, and how many fields does the signup form ask for that you do not use.
2. Onboarding and activation
I define the activation moment first, in 1 sentence, with the founder. Something like "the user connects 1 data source and sees their first report". Then I count every step between account creation and that moment, and I measure how many of them are required.
Most SaaS onboarding I audit has 3 problems: it asks for setup before it shows value, it explains the product with a tour instead of putting the user in a real task, and the empty state is empty. An empty state is a screen with a job. It should carry the next action, an example and a reason to continue. We wrote more about this in Onboarding for SaaS 1: Understanding the Current Journey.
3. The core task flow
Every product has 1 or 2 flows that matter more than the rest. I walk them as a new user and count clicks, decisions, page loads and moments of ambiguity. Then I count the same flow for a returning power user, because the design that helps a beginner often punishes the person who uses your product 40 times a week.
What I am measuring here is cognitive load. How much does the user need to hold in their head to finish the task, and how much of that could the system remember for them.
4. Information architecture and navigation
I map the current structure and compare it to how users describe their work. Products drift: features get added to whatever menu had space, labels come from the database schema instead of the user's vocabulary, and after 2 years the navigation is a history of the roadmap rather than a model of the job.
The test I use is simple. I give 5 users a task and ask where they would look. If more than 2 hesitate at the same point, that label or grouping is a finding.
5. States, errors and edge cases
This layer is where I find the most problems and where teams expect the fewest. Every screen has more than 1 state: empty, loading, partial data, error, no permission, success, too much data. In a typical SaaS audit I find between 15 and 40 missing or unconsidered states.
I also read every error message in the product. Most say what happened, few say what to do next, and almost none prevent the error in the first place. Error prevention is cheaper than error recovery, and it is usually 1 line of validation.
6. Accessibility, responsiveness and perceived performance
Colour contrast, focus order, keyboard navigation, touch targets, form labels. Beyond being the right thing to do, this layer blocks enterprise deals: accessibility questions now appear in procurement, and answering them after the fact costs far more than designing for them.
I check perceived performance in the same pass. A 3 second wait with a skeleton screen and a clear status feels shorter than a 1.5 second wait with a frozen button.
The 40 point UX audit checklist I use
You can run a useful first pass on your own product in 1 afternoon with this. Open the product as if you never saw it before, and answer honestly.
Onboarding and activation
Can a new user reach the first useful result in under 5 minutes?
Is value shown before setup is demanded?
Does the signup form ask only for fields you actually use?
Does every empty state contain a next action and an example?
Is there sample or demo data available for a new account?
Can the user skip onboarding and come back to it?
Do you know your activation rate as a number?
Core flow
8. Can you name the 1 task the product exists to do?
9. How many clicks does that task take for a new user?
10. How many for a returning user?
11. Are destructive actions reversible or confirmed?
12. Does the system remember context between sessions?
13. Are there dead ends where the only option is the back button?
14. Is progress visible in any flow longer than 3 steps?
Navigation and structure
15. Do menu labels use the words your users use?
16. Can a user tell where they are at any moment?
17. Is search present where the list can grow beyond 1 screen?
18. Are related actions grouped, or spread across the interface?
19. Does the mobile or narrow layout keep the primary action reachable?
States and feedback
20. Does every action produce visible feedback within 1 second?
21. Is there a loading state for every request?
22. Is there an empty state for every list?
23. Is there an error state for every form?
24. Do error messages say what to do next?
25. Are errors prevented before they can happen?
26. What does the interface do with 0 items, 1 item and 10,000 items?
Content and clarity
27. Is any word on screen internal vocabulary the user would not use?
28. Are labels consistent for the same object across screens?
29. Are tooltips carrying information that should be visible?
30. Would a new user understand the primary button without reading the page?
Trust, permissions and data
31. Is it clear what is shared, private or visible to a team?
32. Can a user see what changed and who changed it?
33. Is there a way to undo?
34. Are permissions understandable without documentation?
Accessibility and performance
35. Does text meet 4.5 to 1 contrast against its background?
36. Can the core flow be completed with a keyboard only?
37. Do all form inputs have real labels?
38. Are touch targets at least 44 by 44 pixels?
39. Does the slowest screen have a skeleton or progress indicator?
40. Have you opened the product on a 5 year old device recently?
If you answer no to more than 10 of these, the problem is not visual design. It is product design, and a redesign of the same structure will not fix it.
How I score and prioritise findings
A list of 60 problems helps nobody. The value of an audit is in the ordering, and I score every finding on 3 axes.
Severity. A blocker stops the user completing the core task. A major finding causes drop off or repeated support contact. A minor one adds friction. A cosmetic one breaks consistency without hurting the task.
Reach. How many users hit this, and where. A blocker in the signup flow touches 100 percent of new users. A blocker in bulk export touches 4 percent.
Effort. A rough size in developer and designer days. This is why I run audits with an engineer in the room for at least 1 session, because I can guess effort and they can tell me.
Then the priority is simple arithmetic: high reach, high severity, low effort goes first. In most SaaS audits I run, roughly 30 percent of the findings are copy and state changes that take under 1 day each and remove a large share of the friction. Those ship in week 1, before anyone discusses a redesign.
How long a UX audit takes
At Studio Scale we deliver most audits in 5 business days, and we share the blocker findings on day 4 rather than holding everything for a final presentation. If something is stopping users from activating, you should learn about it in a week.
What a UX audit costs
These are our prices.
For comparison, public pricing guides put a single flow audit at $3,000 to $6,000 and a full product audit with testing at $8,000 to $18,000. We sit below that because we are a small team and the audit is usually the first piece of work we do together, not a product we sell on its own.
The strongest cost driver is not the size of the studio. It is the number of user roles and whether live usability testing is included. Adding 5 moderated sessions adds about $800 to $1,500, and in my experience it is the line that changes the most decisions.
One thing to check before you sign: ask whether the deliverable includes redesigned screens for the top findings or only the report. A report tells you what is wrong. Screens tell your team what to build. I usually include 5 to 10 redesigned screens for the blockers, because a finding without a solution tends to sit in a backlog for 6 months. If you are still deciding who to work with, we wrote a separate guide on how to choose the best UX/UI design studio for your startup.
UX audit, usability testing or redesign: which do you need?
These 3 get confused in intro calls, so here is how I separate them.
A usability test answers a specific question: can people do this task. It is narrow, fast and evidence based, and it is a method inside an audit rather than a replacement for one.
A UX audit answers a broader question: where is this product losing people, and in what order should we fix it. It covers the whole experience and produces a plan.
A redesign is a decision, not a diagnosis. I would only start one when the audit shows that the structure itself is wrong, meaning the information architecture, the core flow or the product model. If the findings are mostly states, copy and feedback, a redesign is the expensive way to fix a cheap problem.
The order I recommend: audit, then quick wins, then decide about a redesign with data instead of with taste.
Can AI run the UX audit for you?
Partly, and it is worth knowing which parts.
AI tools are genuinely good at the mechanical pass now. Contrast checks, missing labels, inconsistent components, heuristic violations on a static screen, first drafts of interface copy. I use them, and they save me time on the parts of the audit that used to be a spreadsheet exercise.
What they cannot do is know your user. An AI reviewing a screenshot does not know that your users open this dashboard at 6am on a phone in a warehouse, that they share 1 account across a shift, or that the word "project" means something specific in their industry. It also cannot watch a person hesitate, which is where the expensive findings come from. We wrote about this boundary in I let AI design my app, then I did it properly.
So my honest position: use AI to cover the checklist faster, and spend the time you saved watching 5 real people use the product.
Mistakes I see in UX audits
Auditing the interface without the data. Screens alone will give you a tidy list of heuristic violations and no idea which ones cost money.
Auditing without an owner. If nobody on the team owns the findings, the report becomes a PDF that everyone praises and nobody opens. Before I start, I ask who will own the fixes and what their capacity is in the next 4 weeks.
Delivering 80 findings with no ranking. The team then fixes the easy and visible ones, which are rarely the important ones.
Ignoring the returning user. Most audits focus on the first session because it is easy to observe. For B2B products, the daily user is the one who renews.
Stopping at the report. The audit is finished when something shipped and the number moved, not when the document was delivered.
FAQ
What is included in a UX audit?
A heuristic evaluation against usability principles, a behavioural review of your analytics and support tickets, usually 5 usability sessions, and a prioritised report where every finding has evidence, a severity rating, an effort estimate and a recommended fix. Better engagements also include redesigned screens for the top findings.
How much does a UX audit cost?
We charge $1,600 for a single flow audit, $4,000 to $6,000 for a full product audit with user testing, and $7,000 to $10,000 for a multi role B2B product. Across the wider market the same 3 tiers run at $3,000 to $6,000, $8,000 to $18,000 and $18,000 and above. The number of user roles and the inclusion of live testing move the price more than anything else.
How long does a UX audit take?
3 to 5 days for a single flow, around 2 weeks for a full product, 3 to 4 weeks for a product with several roles. We deliver most audits in 10 business days and share blocker findings on day 4.
Can I run a UX audit myself?
Yes, for the first pass. The 40 point checklist above covers the mechanical layer and you will find real problems with it. What is hard to do in house is seeing what you have stopped noticing, and watching users without leading them. That is the part I would bring an outside pair of eyes for.
How many users do I need for the testing part?
5 people per user role. The 6th session mostly repeats what the first 5 already showed, and 5 sessions per role are enough to find the majority of usability problems.
When should I audit instead of redesign?
Audit first, always. A redesign without a diagnosis rebuilds the same problems in a newer visual language. If the audit shows the structure is sound, you will save most of the redesign budget.
Working with us
We run UX audits for SaaS and B2B products, usually in 10 business days, with blocker findings shared on day 4. You get a ranked list with evidence and effort estimates, redesigned screens for the top findings, and a working session with your team so the plan leaves with them instead of sitting in a document.
We also say when you do not need one. If your product has 200 users and you already know from support what is broken, the honest answer is to fix those 5 things first and talk to us after.
If something in your product is losing people and you cannot name the reason, that is exactly what an audit is for. Book a free 15 minute intro call and show us the flow. We will tell you what we see, even if you run the audit yourself afterwards.
