Case Study Details
Client: Mid-size B2B SaaS company (name withheld under NDA)
Industry: SaaS / Software
Service: Product Design & Development
Engagement length: 6 weeks of research + redesign, phased rollout, ongoing support
The Problem
On paper, things looked fine. Marketing was doing its job — steady signups, decent traffic from both paid and organic channels, a healthy top of funnel. But underneath that, something was quietly broken: only a small fraction of people who signed up ever became active, paying users. Most disappeared within the first session and never came back.
The founder, who we'll call the Founder throughout this case study, had a rough sense that "onboarding was confusing," but no one on the team had the bandwidth — or, honestly, the specific expertise — to properly diagnose why. Their team was three engineers and one generalist designer, all fully occupied shipping the product roadmap. Nobody owned the question of why users were leaving; it just showed up every month as a number that didn't move, and eventually as a support inbox full of the same handful of confused questions asked in different words.
"We knew something was wrong in onboarding. Everyone kind of knew. But knowing that and knowing what to actually fix are two very different things, and we didn't have anyone whose job it was to figure out the difference."
They'd made a few attempts to patch it themselves — a new tooltip here, a shortened signup form there — but these were guesses made under time pressure, not conclusions drawn from evidence. Some changes helped marginally. A couple made things slightly worse. Without a structured way to test and measure, the team couldn't tell which was which, so they mostly stopped touching it and treated the drop-off as a fact of life.
What We Did First: Find Out What Was Actually Happening
Before proposing any redesign, we ran a structured UX audit paired with direct user research — because redesigning a flow you don't understand tends to just replace one set of guesses with another.
Session recordings and funnel analysis. We reviewed a large sample of real user sessions through the signup-to-activation flow, paired with quantitative funnel data to see exactly where people were dropping off, not just that they were dropping off. This mattered — the team's assumption had been that people were confused during account setup. The data told a different story.
User interviews. We recruited a mix of users who had dropped off mid-onboarding and users who had made it through, and talked to both. The dropped-off users weren't confused by the setup screens themselves — they were confused about why they were being asked to do certain steps before they'd seen any real value from the product. Several described feeling like they were filling out a form for a product they hadn't actually experienced yet.
Heuristic review. Alongside the research, we ran a structured usability review of the entire flow against established UX principles, which surfaced a handful of smaller but compounding issues: unclear error states, a progress indicator that didn't match the actual number of steps, and a critical setup step with no explanation of why it was needed.
Put together, the real problem wasn't that onboarding was hard to use. It was that onboarding was sequenced backwards — asking for commitment before delivering value. That reframing changed the entire scope of the redesign.
What We Built
Instead of a cosmetic redesign of the existing screens, we restructured the core flow around a simple principle: get users to a real "aha" moment as fast as possible, and only ask for setup effort once they'd experienced enough value to justify it.
Reordered the flow. We moved a simplified, working version of the core product experience to before the heavier account-setup steps, so new users could see and interact with real value within the first couple of minutes, not after a multi-step setup wizard.
Progressive setup instead of a wizard. Rather than front-loading every configuration decision, we broke setup into small, contextual steps that appeared only when relevant — asked at the moment they mattered, with a plain-language explanation of why, instead of all at once up front.
Redesigned error and progress states. Every error message was rewritten to explain what went wrong and what to do next, instead of a generic failure notice. The progress indicator was rebuilt to accurately reflect the real number of steps, which sounds minor but had been quietly eroding trust — several interviewed users had assumed the process was much longer than it actually was and abandoned it for that reason alone.
Design-to-dev feedback loop. Rather than handing off a finished design spec and moving on, we worked in tight two-day cycles with their engineering team throughout the build — design, implementation, quick internal test, adjust — so issues were caught and corrected in days, not discovered post-launch. This was a deliberate change from how the team had worked before, where design and engineering had operated mostly in sequence rather than in parallel.
How We Rolled It Out
We didn't ship the new flow to everyone at once. We ran it as an A/B test against the existing flow for three weeks, watching activation rate, time-to-first-value, and drop-off point by point, with weekly check-ins alongside the Founder to review what the data was showing. Once the new flow was clearly and consistently outperforming the old one — not just anecdotally, but across a large enough sample to trust — we rolled it out to 100% of new signups.
The Impact
Measured over the eight weeks following full rollout, compared to the same metrics in the eight weeks prior:
- Activation rate (signup to real first use) increased by 42%
- Time-to-first-value dropped from an average of several minutes to under 90 seconds
- Support tickets related to onboarding confusion fell by more than 50%, freeing up the team's limited support bandwidth for genuine product questions instead of repeat confusion
- Week-one retention among new signups improved meaningfully, with more users returning for a second session instead of disappearing after the first
Beyond the numbers, the Founder noted a shift in how the team operated: with a clear, evidence-based flow in place and a working design-to-dev loop established, they were able to keep iterating on onboarding themselves after our engagement ended, using the same testing approach we'd set up rather than reverting to guesswork.
"The redesign mattered, but honestly what mattered more was finally understanding why people were leaving. Once we had that, a lot of the fixes were things we could have done ourselves — we just didn't know where to point the effort before." — Founder
This case study reflects a real client engagement. The client's name and identifying details have been withheld in accordance with a confidentiality agreement; the Founder's title is used in place of a name for the same reason.