Question
What stops people from finishing onboarding — and is it the same thing on every product?
A portfolio built by different teams at different times shares users but not conventions. The suspicion was that drop-off was a design problem rather than a demand problem. But "the onboarding is bad" is a complaint, not a finding, and complaints do not survive contact with a roadmap meeting. Turning it into a finding was the work.
This is not a second account of a portfolio's outcomes. The companion case follows platform and operating decisions; this one follows the research that made the first roadmap defensible.
Constraint
Live products, millions of existing users, no appetite for a rebuild.
Nothing could be redesigned from zero. Every change had to land on products already in production without breaking the habits of the people already using them — which ruled out the clean-slate redesign and forced the work into inventory, prioritisation and staged replacement.
The scope ran across all products rather than one. That is unusual for a designer without a product title, and it is the reason the findings generalised.
Decision
Four stages. The first one is the deliverable; the rest follow from it.
Decision 01
Count the interface before redesigning it
An interface inventory across every existing application — every component, pattern and flow, catalogued and compared. It converted inconsistency from an anecdote into a measurement, and it produced the argument for a shared design language that no amount of advocacy had managed to produce on its own.
Nobody asks for an inventory. It is unglamorous, it ships nothing, and it is the only reason the rest of this project had a defensible order.
Traded away: weeks at the start with no visible output, on a team that had never seen a designer spend time that way.
Decision 02
Diary studies, not usability sessions
Research ran as diary studies to capture user patterns, pain points and daily usage behaviour across segments. A usability session shows how someone handles a task under observation; a diary study shows what they actually do across days, in their own context, including the days they do not open the product at all.
For an onboarding question that distinction is the whole thing, because the failure being investigated happens once, alone, and is never repeated by the same person.
This was run alongside longitudinal research with high-frequency users — the two ends of the distribution, and the contrast between them is where the onboarding hypothesis came from.
Decision 03
Fix onboarding first, on cohort evidence
Three findings came out of the research, and ordering them mattered more than finding them.
| # | Finding | Solution |
|---|---|---|
| 01 | Complex onboarding flow — drop-off during initial setup from unclear instructions and too many steps | Simplified onboarding with progressive disclosure and contextual help |
| 02 | Inconsistent design language — varying patterns across products created confusion and cut user confidence | A unified design system across every product |
| 03 | Poor information architecture — users could not find features through an unclear navigation structure | Restructured hierarchy with user-centred navigation patterns |
Onboarding went first because the cohort data already said the first 48 hours decided retention — users completing a key activation action inside that window retained roughly three times better. Of the three findings it was the only one whose fix compounded.
Decision 04
Standardise toward the familiar, not the impressive
The overhaul converged on patterns users already knew rather than the ones that would have photographed better. On a live portfolio at this scale familiarity is a feature and novelty is a tax — every unfamiliar pattern is a support cost multiplied by the whole user base.
Rollout was staged, with continuous monitoring and optimisation against feedback and performance metrics rather than a single cutover.
Traded away: visual ambition, deliberately and completely.
What it produced beyond the numbers
The unified design system improved development efficiency and reduced design debt across every product — the second-order return on Decision 01, and the one that kept paying after the project closed.
The behavioural research across all eleven products also became the opportunity backlog for a product management role that did not yet exist. It identified three critical adoption blockers which set the first six months of roadmap, and lifted feature adoption by 15%. That backlog is the reason I was given the PM job: the portfolio case study picks up there.
Outcome
- 20%Onboarding time reduced
- 15%Early adoption increase
- 12%D7 retention improvement
- 3×Retention, 48h activation cohort
- 4.5M+Ecosystem users, from ~1M
The onboarding redesign cut time-to-first-action by 20% and improved D7 retention by 12%. Those two are measured against the change itself, which is what makes them the honest numbers on this page.
These are the same measurements reported in the companion platform case study, not a second set. This page and that one describe one continuous stretch of work at one company, told from two ends — the research and redesign here, the portfolio and platform ownership there. Counting the outcomes twice would double a result that only happened once.
Across the same period the product ecosystem grew from approximately one million users to more than four and a half million. That is the context this work happened in, not a number I am claiming: it ran alongside marketing, distribution and product launches I did not own, and growth of that size is never one team's doing.
The ecosystem figures are company-reported context, not numbers I claim. They sit in public disclosures rather than in anything I compiled.
What the design work owns is the 20%, the 15% and the 12%. What the scale gave me is harder to put in a figure and mattered more — every decision on a live portfolio at that size carries an operating cost behind it, and an unfamiliar pattern stops being a preference once you multiply it by four and a half million people.
The inventory was the deliverable. The redesign was just what it made obvious.
figma · sketch · adobe creative suite · interface inventory · diary studies · longitudinal research · usability testing · a/b testing · cohort analysis · design systems