Unified onboarding
Designing a scalable onboarding system for enterprise partners
Sole designer
2024 – ongoing
Pay Admin (Web) + Mobile
— The problem
One foundation for two products
Branch has two products: Branch Wallet and Branch Direct. Historically, they had two separate onboarding systems, and workers had to choose a payout method before they understood the difference between them. The architecture treated payout type as identity, which meant a verification failure was a full rejection. There was no recovery, no fallback, and no path forward for a worker who got stuck.
For a product serving white-label partners like Uber and Instacart, and integration partners like QuikTrip and Henry Ford, that wasn't sustainable. (Integration partners needed SSO verification because Branch didn't have their worker rosters.)
Unified Onboarding consolidated the two systems into one shared foundation: a single onboarding flow with product flexibility inside, and no hard KYC dead-ends. The product became a safety net instead of a gate.
— My role
Two years, sole designer
I was the sole designer on UO for two years, owning the system end-to-end as it expanded across new partners, authentication patterns, and user scenarios. I built and maintained the master flow as a living source of truth, designed new authentication-integrated patterns for enterprise partners, and advocated for failure states and edge cases the original briefs didn't account for.
— What I designed
The master flow as living infrastructure
UO knowledge was scattered across tickets, Confluence pages, and individual designer brains. Engineers cross-referenced multiple sources to understand a single flow. CS couldn't troubleshoot worker issues without escalating. New team members had no single doc to onboard from.
I built and maintained the UO master file in Figma as a working source of truth, organized into three pages: an overview of how to use the file, a logic and specs page covering org settings and conditional rules, and a flows page with screen-by-screen walkthroughs for each account type (Direct, Essential Wallet, Wallet, Premier). The file updates with every UO ticket that ships, so new decision points, screens, and org settings flow into it as the product evolves.
The work surfaced gaps in existing documentation along the way. Worker Lookup requires email or phone, not both. Direct-only orgs are valid, despite Confluence stating otherwise. The Stripe Keycloak setting needed its own entry. Each correction made the file more accurate than the documentation it replaced.
The master file turned UO from tribal knowledge into a documented system. Engineers and QA reference it daily. New designers onboard from it. The flow page is now the single artifact the team points to when asked "how does UO work?"
Embedded onboarding for the Stripe partnership
When Branch struck its partnership with Stripe to replace Marqeta as Branch's card issuer and become the exclusive wallet provider for Stripe Connect customers, UO needed to scale into an embedded experience. It had to live inside the partner's platform UI and authenticate workers through Keycloak rather than Branch's standard passcode.
I owned the full Stripe variant of UO end to end: the embedded onboarding flow, the username and password creation screen that replaced passcode setup, post-onboarding, and the returning user login screen. The challenge wasn't designing each screen in isolation. It was figuring out how an entirely different authentication model could slot into a flow built around passcodes, without breaking the patterns workers already recognized.
The key decision came out of working through the flow with engineering. The duplicate user check needed to happen after username and password creation, not before, to handle returning users correctly. The reframe shifted the design from "abandoned user re-entry" to "returning user authentication," because the trigger is org config, not user state.
The flow launched with Favor as the design partner and is in active use across the Stripe Connect ecosystem.
SSO journey map for integration partners
SSO was elevated to P1 with integration partners QuikTrip and Henry Ford requiring it. These weren't white-labels. They were partners who needed SSO verification because Branch didn't have their worker rosters, and no prior SSO design documentation existed.
I led the journey map over five iterations, working through how SSO could slot into the existing UO flow without disrupting steps that already worked. The map covers the happy path, the SSO failure path, and the returning worker path across both wallet and direct accounts. I flagged two open questions for engineering on OTP sequencing that needed answers before build.
Dynamic landing page
UO's landing page needed to adapt to each org's enabled features (Wallet, Direct, EWA, Tips, Financial Wellness). A static page couldn't serve a partner with Wallet + EWA the same way it served a Direct-only org. I built the logic and copy for a flexible landing page that adapts per org configuration.
The work spanned three layers: the slot rules for which value props show in what order, the copy library covering every use case (with variants where one product needed different framing depending on the org's setup), and a combination matrix documenting all 13 valid configurations. I wrote logic notes for engineering covering slot behavior, priority order, and org setting references.
Enterprise user skip flow
Returning workers who'd started onboarding before but never finished were hitting a generic error during user creation, with no path forward. The system caught the duplicate downstream, which meant the user already felt stuck before the system could help.
I reframed the brief. The problem wasn't the error, it was the lack of resolution. The user needed a way through, not a better error message. I added a decision point upstream of phone and email verification that checks for the existing record and routes the worker directly into the right next step. If their phone was already verified, they went straight to passcode. If not, OTP came first.
I also designed two error variants for cases where detection itself fails, and partnered with engineering to validate the detection mechanism before committing to the design.
— Impact
What changed
Enabled onboarding for Stripe Connect's customer base as Branch's exclusive wallet partner
Unlocked enterprise SSO for integration partners who couldn't onboard workers before
Eliminated a blocking error class for returning enterprise workers, removing a known dropout point
Established a single source of truth that reduced design-engineering handoff friction across the team
— Reflection
What I learned
Onboarding is the highest-leverage moment in any financial product. Every dropout is a worker who didn't get paid through Branch, and a partner relationship that absorbs the friction. Designing for the failure case (returning workers, SSO errors, mid-flow scope changes) is what makes the happy path actually reliable.
The bigger lesson: a system designed around what someone has to choose first will reject the people you most want to keep. UO worked because it stopped asking workers to declare their identity upfront and started giving them a path through.