SaaS Onboarding UX: Screens and Patterns That Get Users to First Value

Good SaaS onboarding is a short path to one first result, not a product tour. Decide what that first result is, then design the sign-up, setup, empty states and checklist around it, and cut every screen that does not help the user get there.

Most guides on SaaS onboarding are written by companies that sell onboarding tools, so they start with tours, tooltips and checklists. I start one step earlier, with the screens themselves: what the user sees right after sign-up, what an empty dashboard says, when to ask a question and when to stay quiet. This is the product designer's view, with the patterns I use on SaaS and AI products and the research behind them.

What SaaS onboarding is (and what it is not)

SaaS onboarding is the part of the product experience that takes a new user from sign-up to the first moment the product does something useful for them. In product teams this is often called user onboarding or product onboarding, and the moment it aims for is called activation, first value or the "aha moment".

Three things share the word, and mixing them up leads to the wrong work:

• User onboarding is designed into the product: screens, states, copy and flows. It is what this article covers.
• Customer onboarding is a process run by people, usually customer success: kickoff calls, implementation plans, training. It matters a lot for enterprise deals, but it is a service, not a set of screens.
• Employee onboarding is HR: welcoming a new hire. Same word, different topic.

On a self-serve product, user onboarding does almost all the work. On a sales-led product, the screens still have to carry the user between calls, because nobody reads the training deck twice.

Start with the first value moment, not the screens

Before I open Figma, I want one sentence from the team: "A new user has got value when they have ___." Not "explored the product", but a concrete result. A report generated from their own data. A first invoice sent. A teammate invited and a first task assigned. An answer from the AI that they kept.

That sentence decides everything else. Every onboarding screen gets the same test: does it bring the user closer to that result, or does it only tell them about the product? Screens that only tell get cut or moved later.

Map the shortest path

Next, I map the shortest real path from the sign-up form to that result, step by step, including the boring parts: email verification, permissions, connecting a data source, waiting for an import. Onboarding problems usually hide in those steps, not in the welcome message.

Then I ask which steps can be removed, deferred or done for the user. Can sample data replace the import for the first session? Can a default replace a setting? Can the integration wait until after the first result?

Expectations start earlier than the product. Google's People + AI Guidebook points out that onboarding begins before users even visit your website. If your marketing site promises "insights in minutes" and the first screen asks for an API key, the gap shows up as drop-off. Aligning the promise of the website with the first session is part of the job, and one reason I care about how a SaaS marketing website frames the product.

The SaaS onboarding flow, screen by screen

The onboarding process for most SaaS products has the same stages: sign-up, welcome, setup, first use, first result, then the habit. Here is what I design at each one.

Sign-up: ask for the minimum

The sign-up form should ask only for what you need to create the account. Company size, role and phone number can wait, or come from enrichment later. Single sign-on with the tools your buyers already use removes a password and a verification email.

Two details are often forgotten: what happens while the account is created (a clear loading state, not a frozen button) and where the user lands if they verify their email on another device.

Welcome questions: only if they change the path

A short welcome survey ("What do you want to do first?", "What is your role?") is useful when the answer changes what the user sees next: a different template, a different first task, a different checklist. If every answer leads to the same dashboard, the questions are a tax.

My rule is two or three questions, each with a visible effect, and a way to skip. The answers should also be easy to change later, in settings, because people guess when they do not know the product yet.

Setup: progressive, skippable, with smart defaults

Complex products need setup: workspaces, integrations, permissions, data. The mistake is asking for all of it up front. Nielsen Norman Group describes progressive disclosure as deferring advanced or rarely used features to a secondary screen, which makes an application easier to learn and less error-prone. Setup works the same way.

In practice:

• Ask for the one setting the first result depends on, and default the rest
• Let users skip what is not required, and show where to finish it later
• Show progress when setup has several steps, with honest labels ("Step 2 of 3: connect your data")
• Save progress, so closing the tab does not mean starting again

Empty states: the most underrated onboarding screen

A new account is mostly empty: no projects, no reports, no data. Nielsen Norman Group notes that empty states are common during onboarding in complex applications, and that a screen left blank creates confusion about whether the system works at all. Designed well, an empty state does three things: it says what is happening, teaches what belongs there, and offers a direct path to the key task.

I design every empty state in the first session as a real screen, not an afterthought. A good one has a short explanation of what will appear here, one primary action to make it appear, and, when it helps, starter content. IBM's Carbon Design System lists starter content, in-line documentation and onboarding as ways to support first-use empty states. Sample data is often the fastest route to the first result, as long as it is clearly labelled and easy to remove.

Good to know: empty states are not only a first-run problem. "No results" after a search and "nothing here yet" after a filter are empty states too, and they deserve the same care: say why it is empty and what to do next.

The first-run checklist

A short checklist works well when the first result needs a few distinct actions, for example: create a project, invite a teammate, connect a source. It gives a sense of where the user is and what is left.

What separates a useful checklist from a nagging one:

• Three to five items, each tied to the first result, not to every feature
• Items that complete themselves when the user does the action anywhere in the product
• A clear way to dismiss it, and no reappearing after it is done
• One item already done when it makes sense ("Account created"), so the list starts in motion

Contextual help instead of product tours

Product tours are the most sold onboarding pattern and one of the least effective. Research from Nielsen Norman Group found that tutorials interrupt users, do not necessarily improve task performance, and are quickly forgotten. In their study of deck-of-cards tutorials, the tutorials did not improve task performance, and users often skip walkthroughs anyway.

What works better is help that appears when the user needs it: a hint next to a feature the first time it is relevant, a help link inside a complex form, a tooltip on an unfamiliar icon. NN/g calls these pull revelations. A walkthrough can still make sense for a new interaction model, but it should be short, skippable and replayable.

The success state, and the next step

When the user reaches the first result, say so. A clear success state confirms the action worked, shows the result, and suggests the next useful step: share the report, schedule the next one, invite the person who needs to see it. This is where onboarding hands over to the habit, and it is often designed last, or not at all.

Onboarding UX patterns compared

Each pattern has a job. The problems start when a team uses one pattern for every job.

Onboarding for AI products

AI products add a problem classic SaaS does not have: users do not know what the product can do, and they often expect more than it can. A blank prompt box is the hardest empty state there is.

Google's People + AI Guidebook recommends onboarding in stages: explain what the AI can do, what it cannot do, how it may change and how to improve it. Microsoft's Guidelines for Human-AI Interaction organise 18 guidelines by moment, including the initial interaction and the moment the AI is wrong. Here is how that translates into screens.

Say what the AI can and cannot do

The first screen should set the scope in plain words: what kinds of questions or tasks work well, what data the AI uses, and what it will not do. This is less about legal disclaimers and more about avoiding a first experience that fails because the user asked for something out of scope.

Replace the blank prompt with starting points

Suggested prompts, templates and examples built from the user's own context turn the blank box into a choice. The best starting points are specific to the role or use case collected at sign-up, which is one of the few cases where welcome questions clearly pay off.

Make the first output editable and traceable

The first answer is the moment trust is won or lost. Show where the answer comes from (sources, the data used), let the user edit or regenerate it, and make keeping it easy. An output the user can correct feels like a draft; one they cannot correct feels like a verdict.

Design the wrong-answer moment on day one

The AI will be wrong in the first session for some users. Design that state before launch: a clear way to flag a bad answer, retry with more context or switch to a manual path. On AI features, this is the state I review most carefully, because it decides whether users come back after the first miss.

B2B onboarding: admins, invites and imports

In B2B SaaS, the person who signs up is often not the person who uses the product every day. Onboarding has two audiences: the admin who sets things up and the team who joins later.

• The admin path covers workspace settings, roles, billing, single sign-on and integrations. It can be longer, but it needs progress, saving and clear explanations of each permission.
• The invited user path should skip almost all of it. An invited teammate lands in a configured workspace and should reach their first result faster than the admin did.
• Data imports deserve their own design: file format help, a preview before import, mapping of columns, errors explained row by row, and a usable state while a long import runs.
• Sales-assisted accounts still need good screens. Between calls, the product has to remind users of what was agreed and what to do next.

Common onboarding mistakes

These are the issues I see most often when I review SaaS products:

• A dashboard full of empty charts as the first screen
• A product tour that starts before the user has done anything
• Welcome questions whose answers change nothing
• Setup that cannot be skipped, saved or resumed
• A checklist listing every feature instead of the path to one result
• Error messages that blame the user ("Invalid input") instead of saying how to fix it
• No success state, so users are not sure the first action worked
• Onboarding designed once at launch and never reviewed after the product changed

How to measure onboarding (and what to change)

The usual metrics are activation rate (the share of new accounts that reach the first result), time to first value, completion of each onboarding step and early retention. They are useful only if they point to a screen.

What I do with them:

1. Instrument each step of the path, not only sign-up and activation, so drop-off can be located.
2. Watch real sessions at the step with the largest drop. Numbers show where users leave; recordings and interviews show why.
3. Test the flow with a few people. Nielsen Norman Group recommends testing with no more than five users and running several small tests rather than one large study. For onboarding, recruiting people who have never seen the product is the whole point.
4. Walk through it as a new user. A cognitive walkthrough, where reviewers step through a task from a new user's point of view, catches learnability problems before anyone is recruited.
5. Change one thing at a time and compare cohorts, so you know what worked.

How I design onboarding for SaaS teams

On SaaS and AI products, onboarding is rarely a separate project. It is a set of flows and states that touch the sign-up, the empty product, the first task and the first error. When I work on it, the steps are the same:

1. Agree on the first value moment and how it is measured.
2. Map the current path from sign-up to that moment, with data and recordings.
3. Design the flow in Figma: every screen, including empty, loading, error and success states, using the product's design system so engineers do not have to guess.
4. Prototype and test with a handful of new users before anything is built.
5. Review the build in staging, then watch the numbers and the sessions after release.

If your product loses people between sign-up and the first result, this is the kind of work I do as a freelance product designer for SaaS and AI products.

The bottom line

Onboarding is not a layer you add on top of a product with a tour tool. It is the product's first few screens, designed around one result: a short sign-up, questions that change the path, setup that can wait, empty states that teach, help that appears when needed and a clear success state.

If you want a senior eye on your onboarding flow, see how I work on product design for SaaS teams, or tell me about your product and where users drop off.