SaaS Onboarding Flow Examples: Real Journeys Walked Step by Step

SaaS onboarding flow examples show the exact screens a new user sees between creating an account and getting their first real result in a product. Most flows follow the same backbone: sign up, confirm the account, answer a few setup questions, land in the product, and get nudged toward one key action. The useful part is the details: which questions get asked, what the first empty screen looks like, and how much the product does for the user versus asking them to do it.

This guide walks through those details step by step, compares the common patterns, and shows how to turn real examples into better decisions for your own flow.

What is a SaaS onboarding flow?

A SaaS onboarding flow is the sequence of screens and messages that takes a new user from "I just signed up" to "I see why this product is useful." It usually starts right after the signup form and ends when the user completes a first meaningful action, such as creating a project, inviting a teammate, connecting data or publishing something.

It helps to separate onboarding into two layers:

• Account onboarding: the setup screens. Email confirmation, profile details, workspace name, role or team size questions.
• Product onboarding: the guidance inside the app. Empty states, checklists, tooltips, sample data and product tours.

When designers talk about an onboarding flow, they often mean only the first layer. In practice, users experience both as one journey, and the handoff between them is where many flows feel clumsy. A user answers five setup questions and then lands on a blank dashboard with no sign that their answers mattered.

The common steps most onboarding flows share

Onboarding flows vary a lot in tone and length, but most of them are built from the same parts. Here is the typical order:

1. Signup. Email and password, or a single sign-on button. Some products ask only for an email here and collect the rest later.
2. Account confirmation. A "check your inbox" screen, a magic link or a code. Some products let users in first and ask for confirmation later.
3. Profile and workspace setup. Name, company name, workspace URL, sometimes a profile photo.
4. Welcome survey. Questions about role, team size, goals or how the user heard about the product.
5. Invite teammates. Common in collaboration tools, often with a visible "skip" option.
6. First run in the product. An empty state, a template picker, sample data or a guided first task.
7. Ongoing guidance. A checklist, tooltips, or a short product tour that points to key features.
8. Follow-up. Welcome emails, in-app messages and, for trials, reminders about the trial end.

Not every product uses every step. A simple tool may jump from signup straight to step 6. A complex B2B product may add steps like connecting an integration or booking a call. The value of looking at many real flows is seeing which steps a product chose to keep, cut or delay.

Onboarding flow examples walked screen by screen

Below are three common shapes of onboarding flow, walked through the way you would see them when capturing a real journey. Use them as a lens: when you look at any product's onboarding, you will usually recognize one of these shapes.

Example 1: The short path to a first result

This shape is common in tools where a user can get value alone, such as note-taking, form builders or simple design tools.

• Screen 1, signup: one field for email or a single sign-on button.
• Screen 2, one question: "What will you use this for?" with three or four large options.
• Screen 3, template picker: templates filtered by the answer from screen 2.
• Screen 4, the editor: the chosen template is already open, with a small hint pointing to the first thing to change.

What to notice: the welcome question is used right away. The user sees the effect of their answer one screen later, which makes the question feel worth answering. There is no blank page at any point.

Example 2: The team workspace setup

This shape shows up in collaboration products like project management, chat or shared documentation tools.

• Screen 1, signup: email, then a code sent to the inbox.
• Screen 2, workspace name: often pre-filled from the email domain.
• Screen 3, role and team size: two or three quick questions.
• Screen 4, invite teammates: a field for several emails, plus a copyable invite link and a "skip for now" link.
• Screen 5, first project: a prompt to name a project or pick a starter template.
• Screen 6, the app: a checklist in a side panel with tasks like "create a task" and "invite a teammate".

What to notice: the invite step sits early because the product is more useful with others in it. The skip link matters. When it is hidden or tiny, users who are just exploring tend to feel pushed.

Example 3: The data-first setup

This shape fits analytics, finance, marketing and developer tools, where the product is empty until it is connected to something.

• Screen 1, signup and company details.
• Screen 2, choose a data source: a grid of integration logos.
• Screen 3, connect: an authorization step or a code snippet to install.
• Screen 4, waiting state: a screen that explains what happens while data arrives, sometimes with a "view demo data" option.
• Screen 5, first dashboard.

What to notice: the waiting state is the risky moment. Good versions give the user something to explore, such as sample data or a demo workspace, so they are not staring at a spinner. Many of these flows also let users invite a developer to finish the technical step, which is a smart detail when the person signing up is not the one who can install code.

Welcome surveys and personalization: what real products ask

The welcome survey is the step where onboarding flows differ most. Some products ask one question. Others ask six. The questions usually fall into a few groups:

• Role: designer, engineer, marketer, founder, student.
• Use case or goal: "What do you want to do first?"
• Team size or company size: often used for sales routing as well as personalization.
• Experience level: "Have you used a tool like this before?"
• Attribution: "How did you hear about us?"

The best rule of thumb: every question should change something the user sees, or at least clearly help the product serve them. A role question that leads to tailored templates earns its place. An attribution question helps the company but not the user, so it is often placed last or made optional.

Things to look for when you study real surveys:

• How many questions appear on one screen versus spread across several screens.
• Whether answers are buttons, dropdowns or free text.
• Whether there is a progress indicator.
• Whether the user can skip.
• Whether the next screens actually reflect the answers.

We collected the questions real products ask, and how they phrase them, in Welcome Survey Examples: Questions SaaS Apps Ask During Onboarding.

Empty states, checklists and product tours compared

Once the user lands in the product, there are three main ways to guide them. Most products mix them, but each has a different job.

Empty states

An empty state is what a screen shows before the user has created anything. A good one explains what will appear here and offers one clear action, like "Create your first project" or "Import from a file." Some products skip the empty state entirely by loading sample content.

• Good for: products where the first action is obvious.
• Watch out for: blank screens with only a small "+" button and no explanation.

Checklists

A checklist lists a few setup tasks and shows progress as they get done. It usually sits in a side panel, a corner widget or a dedicated "Get started" page.

• Good for: products with several setup steps that do not need to happen in one sitting.
• Watch out for: long lists where half the tasks are not useful yet, and checklists that cannot be dismissed.

For a closer look at how products structure these lists, see Onboarding Checklist Examples: How SaaS Products Guide New Users.

Product tours

A product tour is a series of tooltips or modals that point at parts of the interface. Tours are easy to add, which is why they are everywhere, and also easy to click through without reading.

• Good for: showing one or two features that are not obvious from the interface.
• Watch out for: tours longer than a few steps, and tours that start before the user has done anything.

Quick comparison

| Pattern | What it does best | Common mistake | |---|---|---| | Empty state | Prompts the first action in context | Leaving the screen blank | | Checklist | Shows progress across several tasks | Too many tasks, no way to close it | | Product tour | Points out non-obvious features | Too long, shown too early |

A useful pattern in many flows: a helpful empty state for the first action, then a short checklist for the rest of setup, and tooltips only when a user reaches a feature for the first time.

How onboarding changes between desktop and mobile

The same product often runs a noticeably different onboarding on a phone. When you compare captured flows side by side, a few differences come up again and again:

• Fewer questions. Mobile surveys are often cut down or split into one question per screen.
• Single sign-on comes first. Typing a password on a phone is slow, so social or device sign-in buttons get more space.
• Notification permission. Mobile apps add a step asking to allow notifications. Good flows explain why before the system prompt appears.
• Tours become swipe cards. Instead of tooltips, many apps show a few full-screen cards at the start.
• Some setup is deferred. Tasks like connecting integrations or inviting a team may be pushed to desktop, sometimes with a "finish setup on your computer" message.
• Bottom sheets replace modals. Prompts slide up from the bottom so they are easy to reach with a thumb.

If your product is used on both, design the two flows together rather than shrinking the desktop one. Decide which steps truly need to happen on mobile and which can wait.

How to use these examples when designing your own flow

Looking at examples is only useful if it leads to better decisions. Here is a simple way to work with them:

1. Define the first meaningful action. Write down the one thing a new user must do to see value. Everything in the flow should move toward it.
2. Collect flows from similar products. Look at products with a similar user and a similar first action, not just famous names.
3. Map each flow step by step. Note every screen, question and prompt, and how many screens it takes to reach the first meaningful action.
4. Mark what each step is for. Does it help the user, the company, or both? Steps that only help the company are candidates to delay or cut.
5. Check the handoffs. Do survey answers change what the user sees? Does the empty state connect to the checklist?
6. Compare desktop and mobile. See what other products drop or move on mobile.
7. Draft your flow, then test it. Prototype it, watch a few real people go through it, and adjust.

Avoid copying a flow whole. A pattern that works for a team chat tool may be wrong for a solo analytics product. Borrow the reasoning, not just the screens.

Browse the free flow library

Reading about onboarding helps, but seeing the real screens in order is faster. Webflowarchive is a searchable library of real website user flows, including signup, onboarding, pricing and upgrade journeys, captured step by step on desktop and mobile, with notes on what happens on each screen.

Pick a few products close to yours, walk their onboarding screen by screen, and bring those references into your next design review. Browse the free flow library and start your next onboarding flow from proven examples instead of a blank page.