What a UX Audit Found Across 10 B2B SaaS Products
After auditing ten B2B SaaS products, five friction patterns appear in almost every one. Here's what they are and what to do about them.
A UX audit is a structured review of a product's experience — mapping where users get stuck, where they drop off, and which friction points are costing the most revenue. After completing audits across ten B2B SaaS products in the last eighteen months, certain patterns appear so consistently that they're worth naming.
These aren't obscure edge cases. They show up in well-funded, well-staffed products. They show up in products that have been through design sprints and usability studies. They're persistent because they're structural — the result of how growth-stage software gets built, not how it gets designed.
Here are the five patterns that appeared in at least seven of the ten products I audited.
1. The setup wall
Almost every B2B SaaS product requires some configuration before it delivers value. That's unavoidable. What's avoidable is requiring all of it before the user can experience anything.
I call this the setup wall: the sequence of account configuration steps that stands between signup and first value. In most products, the setup wall is longer than it needs to be, structured around what the product needs from the user rather than what the user needs from the product.
The impact is measurable. In products where I had access to funnel analytics, setup wall abandonment accounted for between 20% and 45% of trial drop-off. Most of those users never reached the activation event — so the product never had a chance to prove its value.
The fix isn't to eliminate setup — it's to defer it. Show the user the value first (with synthetic or sample data if necessary), then prompt them to configure once they've understood why it matters.
2. Empty states that say nothing
The empty state is one of the highest-leverage design moments in a SaaS product. It's the first thing a new user sees after completing onboarding. It's also, in most products I audit, the worst-designed screen in the entire interface.
The typical empty state is a blank panel with a vague headline ("No items yet") and a generic call to action ("Create your first item"). This tells the user nothing about what the item is, why they would create one, or what will happen when they do.
A well-designed empty state answers three questions: what would appear here if you had data, why that data matters, and exactly what to do to create it. Done well, an empty state is a tutorial. Done badly, it's a dead end.
In products where empty states were redesigned as part of the audit follow-up, the teams consistently reported meaningful improvements in first-week task completion — often without any other onboarding changes.
3. Terminology that belongs to the team, not the user
Every product develops internal vocabulary during its build. The names teams use for concepts in planning meetings, Slack channels, and sprint tickets often find their way into the product interface — unchanged.
The problem is that these terms reflect how the engineering and product team thinks about the system, not how users think about their work. When users can't map product terms to their own mental vocabulary, they can't navigate confidently. They slow down, they open support tickets, and they use fewer features.
The audit pattern is consistent: products with high support volume on basic features almost always have a terminology mismatch between the product and the user's workflow language. A vocabulary audit — asking users to describe their own workflow in their own words, then comparing it to product terminology — typically surfaces three to eight mismatches that are easy to fix.
Renaming doesn't require engineering time. It requires editorial discipline and the willingness to acknowledge that the internal name isn't the right external name.
4. Navigation that reflects the org chart
Products that have grown through multiple teams often develop navigation that reflects how the company is organised rather than how users work. Feature areas are grouped by the team that built them, not by the user job they serve.
This is most visible in the top-level navigation. I've audited products where the navigation items are essentially the names of internal squads: "Insights" (built by the data team), "Automation" (built by the platform team), "Integrations" (built by partnerships). These labels are meaningful to the people who built them. To a new user, they're opaque.
The fix requires an information architecture review grounded in user task analysis — understanding the five to seven jobs users actually come to the product to do, and restructuring navigation around those jobs rather than internal ownership.
This is usually a significant project. But it's often the change that has the highest long-term impact on product adoption.
5. Confirmation dialogs that don't confirm anything
The final pattern is more specific but worth naming because it appears so consistently and has such an outsized effect on user confidence.
A confirmation dialog is supposed to do two things: protect the user from accidental destructive actions, and give them enough information to make the confirmation decision confidently. Most confirmation dialogs in B2B SaaS do only the first.
The typical dialog: "Are you sure you want to delete this item? This action cannot be undone." The user is asked to confirm something without being told what "this item" is, what it's connected to, or what downstream effects the deletion will have. For a user who manages complex data relationships, this is a genuine blocker. They can't confirm confidently, so they cancel and look for help.
Well-designed confirmations name the specific item ("Delete 'Q1 Campaign Report'?"), describe the consequences ("This will also remove all associated tasks and cannot be recovered"), and if the action is reversible, say so clearly.
This is a small change per dialog. Across a product with dozens of destructive actions, it's a meaningful improvement to the experience of data management — which is often where enterprise users focus their attention.
What these patterns have in common
None of these patterns are caused by a lack of design effort. They're caused by building features without a governing experience model — without someone whose job is to ask "how does this fit the existing product, and what does a new user need to understand to use it?"
That's the gap a structured UX audit is designed to surface. And it's the gap fractional UX leadership is designed to prevent from growing back.
If you recognise any of these patterns in your product, a structured SaaS UX audit will give you a severity-ranked view of what to fix and in what order — with revenue impact tied to each finding.
