Reframed onboarding as a trust-building sequence, reducing ambiguity between compliance, account setup, and the user's first successful action.
Onboarding looked fine on a funnel chart — most users who started the flow eventually finished it. But that number was hiding the real story: people were completing onboarding without ever feeling like they understood what they'd just agreed to. Support tickets in the first week of an account's life were dominated by one theme — "why is my account restricted?" — even though every restriction was, technically, disclosed somewhere in the flow.
The actual cost wasn't drop-off. It was a slow leak of trust in the first week, right when a new user's tolerance for friction is lowest and their willingness to churn is highest. Compliance, account setup, and the user's first meaningful action were being designed as three separate steps owned by three separate teams, with no one responsible for whether the sequence made sense as a story.
I reframed onboarding as a trust-building sequence rather than a completion funnel. The question stopped being "how do we get people through this faster" and became "at each step, does the user understand why we're asking, and what happens next." That reframe changed what we measured — instead of just completion rate, we tracked first-week support contact rate and time-to-first-successful-action as the real signals of whether onboarding had worked.
I rejected two easier paths early on. One was simply shortening the flow — fewer fields, fewer screens — which would have improved completion metrics without addressing the actual confusion. The other was adding more explanatory copy at each step, which tends to bury the one sentence that matters under paragraphs nobody reads.
Instead, the flow was restructured around three principles:
1. Sequence compliance and setup by what the user needs to know when. Verification requirements that affected what the user could do immediately were surfaced before account setup; ones that only mattered later were deferred and re-surfaced at the moment they became relevant, instead of front-loaded.
2. Keep deliberate friction where risk actually lived, and remove it everywhere else. Identity verification stayed strict. Everything downstream of it — account configuration, preference setup — was simplified aggressively, since that's where friction was only costing us goodwill without buying us any real risk reduction.
3. Make restriction states legible in the moment, not discoverable later. If an account would be temporarily limited pending a check, the user saw that plainly at the point of setup, framed as a status with a clear resolution path — not as a support ticket waiting to happen.
First-week support contact rate around account restrictions dropped meaningfully, and time-to-first-successful-action shortened, even though the compliance requirements themselves didn't change — only their sequencing and legibility did. The bigger shift was internal: onboarding stopped being three teams' separate handoffs and became one owned sequence, which made the next round of changes much faster to reason about and ship.
What I'd revisit: the restriction-state messaging still leans on generic language in a few edge cases. Given more time, I'd tailor that copy per restriction type rather than using one template for all of them.
Onboarding state was modeled as a single source of truth shared across three previously siloed systems: identity verification, account provisioning, and the compliance rules engine. Rather than each team's system independently deciding what the user should see next, a shared "onboarding state" object tracked exactly which checks had passed, which were pending, and which restrictions were currently active — and every screen in the flow read from that same object.
This meant a restriction surfaced by the compliance engine at 2am could immediately change what account setup showed the user, without a manual handoff between teams. The trade-off was real: it required the three teams to agree on one shared schema for onboarding state, which took longer to negotiate upfront than building three independent flows would have — but it's what made the restriction-state messaging in "Key decisions" above possible at all.