Product Experience7 min read

The UX Audit Checklist for SaaS Products That Aren't Growing

The product areas to evaluate when growth has stalled, what to look for in each, and how to prioritize what you find.

By RNO1Michael GaizutisMarko Pankarican
Apr 22, 20267 min read

When a SaaS product stops growing, the first instinct is to add features. The second instinct is to redesign the marketing site. Both instincts are usually wrong. Most growth stalls are caused by UX friction in existing workflows, not missing functionality or insufficient awareness.

The same friction drives churn. Users rarely leave because a competitor has more features — they leave because the daily workflow is harder than it needs to be. The clearest signal is support ticket volume: when the same three workflows generate 60% of your support load, those workflows are your retention problem. Every ticket is a customer saying "I tried to do the thing and couldn't." Stack enough of those and the customer starts evaluating alternatives.

A structured UX audit identifies where the friction lives before committing resources to the wrong fix.

The 12-surface audit

1. First-run experience (signup to first value)

What to measure: Time to first value action. Drop-off rate at each step. Percentage of users who reach the "aha moment" within the first session.

What to look for: Steps that don't contribute to reaching first value. Mandatory profile completion before the user can do anything useful. Feature tours that show everything instead of the one thing that matters. Permission requests that feel premature.

Benchmark: Best-in-class SaaS products deliver first value in under 3 minutes. If yours takes longer than 10, the onboarding is the growth blocker.

2. Core workflow

What to measure: Task completion rate. Time per task. Error rate. Number of steps to complete the primary job-to-be-done.

What to look for: Extra clicks. Unnecessary confirmations. Information that's spread across multiple screens when it could be consolidated. Input fields that require formatting the user has to guess.

3. Navigation and information architecture

What to measure: How many clicks to reach the five most-used features. Search usage rate (high search usage often indicates navigation failure). Support ticket volume related to "how do I find X."

What to look for: Navigation labels that use internal company language instead of user language. More than two levels of nesting. Inconsistent placement of actions (save buttons in different positions on different screens).

4. Empty states

What to measure: Conversion rate from empty state to first content creation. Time spent on empty state pages before abandoning.

What to look for: Empty states that say "No data yet" instead of guiding the user toward creating their first item. Missing templates or sample data that would help users understand the product's value before investing their own content.

5. Error handling

What to measure: Frequency of user-facing errors. Time to recovery after an error. Support tickets generated by error states.

What to look for: Technical error messages shown to non-technical users. Errors that lose user input (the form resets after a submission failure). No distinction between user errors and system errors.

6. Settings and configuration

What to measure: Time to find and change a specific setting. Percentage of available settings that are actually modified by users.

What to look for: Settings pages that expose every possible option instead of surfacing the ones users actually change. Missing search within settings. Configuration options that require understanding implementation details.

7. Notifications and communication

What to measure: Email open rates by notification type. In-app notification click-through rates. Unsubscribe rates.

What to look for: Notifications that don't link to the relevant context. Batching that creates notification fatigue. Missing notification preferences.

8. Mobile experience

What to measure: Feature parity between mobile and desktop. Task completion rates on mobile vs. desktop. Mobile session duration.

What to look for: Desktop interfaces squeezed onto small screens. Touch targets smaller than 44px. Features that require hover states on a touch device.

9. Performance

What to measure: Page load times across all major views. Time to interactive. Largest Contentful Paint. Response time for user-initiated actions.

What to look for: List views that load thousands of items without pagination or virtualization. Actions that block the UI without loading indicators. API calls on every keystroke without debouncing.

10. Upgrade and expansion surfaces

What to measure: Percentage of users who encounter upgrade prompts. Conversion rate from free to paid trigger points. Feature discovery rate for paid-tier features.

What to look for: Upgrade prompts that interrupt the user's workflow. Missing contextual upgrade surfaces at the moment the user hits a limit. Paid features that are invisible to free-tier users.

11. Help and support

What to measure: Self-service resolution rate. Average time from question to answer. Support ticket volume per user.

What to look for: Help documentation that doesn't match the current UI. Missing contextual help (tooltips, inline guidance). Search that returns irrelevant results.

12. Account management

What to measure: Time to add a team member. Billing change completion rate. Data export accessibility.

What to look for: Billing pages that require contacting support. Team management that requires admin privileges for basic actions. Missing data export options.

How to prioritize findings

Rate each surface on two dimensions:

Impact: How many users does this surface affect, and how much does it influence conversion, retention, or expansion? A friction point in onboarding affects every new user. A friction point in the billing settings affects users once a year. Weight accordingly — and cross-reference with customer complaint data. If the same workflow shows up in support tickets, churned-customer exit interviews, and low-star G2 reviews, that workflow moves to the top of the list regardless of what the NPS survey says.

Effort: How much design and engineering time is required to fix the identified issues?

Start with high-impact, low-effort fixes. These are usually interaction-level changes (button placement, copy changes, flow simplification) rather than architectural changes. A typical UX audit produces 8-12 high-impact, low-effort fixes that can be shipped in 2-4 sprints. Forrester's research on UX ROI shows that every dollar invested in usability returns $10-100 in reduced development costs and increased revenue.

Once the audit identifies where friction lives, quantifying the revenue impact of fixing it builds the business case for investment. Many of the same principles apply to website conversion optimization — the audit methodology translates directly to marketing surfaces.

RNO1 conducts UX audits as a standalone engagement and as the diagnostic phase of product experience redesigns. The audit typically requires 2-3 weeks and produces a prioritized roadmap that aligns design, engineering, and product leadership on what to fix first.

Frequently Asked Questions

How long does a UX audit take?

A comprehensive 12-surface audit takes 2-3 weeks with a senior UX team. This includes heuristic evaluation, analytics review, 5-8 user interviews or session recordings, and a prioritized findings report. A lighter-weight audit focused on 3-4 surfaces (typically onboarding, core workflow, and navigation) can be completed in 1 week.

How is a UX audit different from usability testing?

A UX audit is an expert evaluation across multiple surfaces using heuristics, analytics, and established benchmarks. Usability testing observes real users performing specific tasks. They complement each other — the audit identifies likely problem areas quickly, and usability testing validates whether those problems actually affect users in practice. Start with the audit to focus the testing.

What tools do you need to run a UX audit?

Analytics (Mixpanel, Amplitude, or equivalent for funnel data), session recording (Hotjar, FullStory), the product itself on multiple devices, and access to support ticket data. The most valuable input is often qualitative — 5-8 conversations with recent churned users reveal friction that analytics alone cannot surface.

When should a SaaS company run a UX audit?

Three triggers: (1) growth has stalled and the team disagrees on why — revenue is flat, churn is climbing, and nobody can isolate whether the problem is acquisition, activation, or retention, (2) the company is planning a major product investment and needs to prioritize where design effort will move the number most, (3) post-acquisition when two products with different UX patterns are being evaluated for integration. A less obvious but equally urgent trigger: customer complaints clustering around the same workflows. When support tickets, G2 reviews, and churned-customer interviews all point at the same three screens, that's not a feature gap — that's a UX debt problem the audit will quantify. The worst time is mid-redesign — run the audit before committing to a direction, not after.

Ready to build?

We help companies turn brand, website, and product experience into measurable revenue.

Book a Strategy Call