How to Design a SaaS Onboarding Flow With Journey Splits
For Junior product designers building onboarding flows · Based on Kole Jain 28-Day Design Eye Method
// TL;DR
If you're a junior product designer asked to build an onboarding flow for a SaaS product with both solo users and team managers, the Kole Jain 28-Day Design Eye Method's UX framework gives you a concrete structure. You map shared entry screens first, make a documented block-or-continue decision on email verification, then design the journey split at the team-size question — routing team managers to an invite screen while individuals bypass it. Every screen decision is articulated in terms of the user's journey, not visual style, and every entry point includes an escape hatch.
How do I structure a SaaS onboarding flow?
Start by separating UX from UI. In this method, UX (product design) is the thought process — how you structure a user's journey across screens and decision points — while UI is flavor. Onboarding is fundamentally a UX problem: every decision should be about the user's journey, not spacing or typography. Solve the flow logic first; style it later.
Map the shared entry screens that every user passes through: name and email entry, email verification, and workspace creation with a team-size question. These are the common path before any branching happens.
Where should the user journey split?
At the team-size question. This is the critical branch point in a B2B SaaS flow that serves both solo users and team managers. Users who identify as part of a team proceed to an 'Invite team members' screen; users who identify as individuals bypass that screen entirely. You must design both post-split screens.
The discipline here is asking, at every screen: does this user need to be here? A solo user forced through an invite-members screen experiences friction with no payoff. Recognizing where the journey splits — and designing each branch deliberately — is what separates a considered flow from a linear one that ignores its own users.
What is an escape hatch and where do I put it?
An escape hatch is a UX element that gives users who arrive somewhere unintentionally a clear, low-friction path to an alternative. Always design for users who land somewhere by mistake. The classic example: on your name-and-email signup screen, include an 'Already have an account? Log in' link. Every entry point should provide a way out or an alternative.
Missing escape hatches is a common junior mistake because you design for the ideal path and forget that real users arrive from ads, shared links, and back buttons. Auditing every screen for an escape hatch hardens your flow against real-world entry chaos.
How do I handle the email verification screen?
Make a deliberate, documented decision: do you block progress until the email is verified, or allow continuation with a gentle reminder? There's no universally correct answer — blocking guarantees verified accounts but adds friction; allowing continuation reduces drop-off but risks unverified users. The method's requirement is that you document your reasoning.
This documentation habit matters beyond onboarding. Articulating why a screen behaves the way it does — in terms of the user's journey and business risk — is the product-design thinking that gets you taken seriously in reviews and interviews.
How do I know my flow is actually good?
Walk each path end to end and confirm three things. First, every screen earns its place — no user is forced through a step irrelevant to them (like the solo-user invite bypass). Second, every entry point has an escape hatch. Third, every non-obvious decision, like block-or-continue, has documented reasoning. If all three hold, your flow is structurally sound and ready for the UI flavor pass.
Only after the journey logic is locked should you apply visual flavor — color, corner radius, imagery — because conflating UI and UX at this stage causes you to solve the wrong problem.
Next step: Sketch your onboarding flow's shared screens, then explicitly mark the team-size split and design both branches. Add an escape hatch to your signup screen and write one sentence documenting your email-verification decision.
// FREQUENTLY ASKED QUESTIONS
Why should I map UX before applying any visual style?
Because UI and UX are distinct problems, and conflating them makes you solve the wrong one. UX onboarding is about journey structure and decision logic — where users branch, what screens they need, where escape hatches go. Styling comes after the flow logic is locked, so your visual decisions serve a proven journey rather than a guessed one.
How do I decide whether to block or allow progress on email verification?
There's no single right answer — the method requires you to consciously choose and document your reasoning. Blocking guarantees verified accounts but adds friction; allowing continuation with a reminder reduces drop-off but risks unverified users. Weigh your product's risk tolerance against conversion goals, then write down why you chose your approach.
What happens to solo users at the team-size split?
They bypass the 'Invite team members' screen entirely. Only users who identify as part of a team proceed to invite others. Forcing solo users through an irrelevant invite step adds friction with no payoff, so the journey must branch and each post-split screen must be designed deliberately for its specific user.
Do I need an escape hatch on every screen?
Every entry point should provide one, because real users arrive from ads, shared links, and back buttons — not just the ideal path. The clearest example is an 'Already have an account? Log in' link on signup. Audit each screen for users who might have landed there unintentionally and give them a clear alternative route.