How to design an onboarding flow

Decide what the user should know in the first ten seconds

The first screen is not a summary of your app. It is a promise about what the app will do for this person, in their words. Write that promise in one sentence before you design anything: keep track of your reading, share photos with your family, stop losing track of your expenses. If the sentence could describe a competitor, it is not specific enough.

A promise is different from a feature list, and the difference shows in the design. A feature list asks the reader to evaluate your product. A promise asks them to imagine a situation they are already in. The first screen should contain one sentence of promise, one piece of supporting evidence, and one obvious next step.

The empty state guide covers the same instinct in a different place: say what is going to happen, then offer the action. Onboarding is that pattern applied to the first ten seconds of a relationship.

• One promise, written in the user's words
• One piece of evidence, not a list of features
• One obvious next step on the screen
• Nothing that requires reading to understand

Note: If your app does something for people in a specific situation, name that situation. A specific first screen converts better than a general one, because a general one describes a category rather than a need.

Keep the flow to three screens

Three screens is the working limit, and it is a limit worth defending. Each screen should carry one idea, and each idea should be worth a swipe. Beyond three, the flow stops being a welcome and starts being a tutorial, and most people are not there yet.

The palette has the components for the two jobs this creates. A Progress component shows how much is left, and a Stepper component shows a count, such as step 2 of 3. Together they tell a reader that the flow is short and that it is moving, which is what stops a first screen from feeling like a trap.

The template gallery gives you a starting structure. There are 54 app templates across 8 categories, and the auth category includes Onboarding, Onboarding Flow, Splash Screen, Login and Sign Up frames you can rework rather than start from an empty frame. The gallery is searchable and can be filtered by mobile or web.

• Three screens, one idea each
• Progress shows how much is left
• Stepper shows which step you are on
• Rework an auth template rather than starting blank

Note: A mobile frame starts at 390×844, so a three-screen flow is a small job. Adding a fourth screen is rarely a capacity problem, it is a content problem.

Show the product before you ask for an account

The order matters more than the content. A user asked to sign up before they have seen anything is being asked for a promise with nothing behind it, and the drop-off at that point is where most onboarding losses happen.

So put the product first. The Image component is the tool for this: show a real screen, a real photo, or a simple illustration of the outcome the person came for. A Stat card and the Empty state component from the reusable library are also useful here, because they show the shape of what the app will hold before there is any data in it.

Then, once the person has seen one real thing, ask for the account. That screen can be short, because the work of the flow was already done by the thing they saw. A login screen designed well is a calm place to ask, not the first impression of the product.

• One screen of the real product before the account form
• Image shows the outcome, not a logo
• Stat card or Empty state shows the shape of the data
• The account request comes after, and stays short

Note: A demo mode, where the person can press around without signing up, often beats a longer explanation. It is a decision to make early, because it doubles the number of screens to design.

Make skipping a real option

If skipping is offered, it has to be offered honestly. A Skip button in the same weight and position as the other options, or a quiet text link in a corner, tells the reader that the flow is optional. A skip that is hidden in a menu, or styled to look like a mistake, is a trap and it costs trust.

A skip also needs a destination. Skipping should land somewhere useful, such as the empty home screen, and that screen has to work on its own, with a hint of what to do next. Otherwise skipping feels like being dumped, and the person may not come back.

Decide which of the two you mean. If the flow is a walkthrough, the skip is generous. If the flow is a setup step the person genuinely needs, for example choosing a workspace, then there is no skip, and the screen has to explain why it matters.

• Skip in the same visual weight as the other options
• A skip lands somewhere that works on its own
• No skip when the step is genuinely required
• A required step says why it is required

Note: Measure it rather than guessing. Build both versions, watch which one people continue from, and let the numbers settle the argument.

Cut any screen the user cannot act on

A screen where nothing can be pressed is a screen that wastes the only attention you have. Onboarding has three, and every one of them needs a way forward: a button, a swipable image, or a step the person can complete. If a screen has no action, cut it or merge it with the next one.

Look for the usual offenders. A screen that only introduces a brand, a screen that shows a feature the person has not asked for, and a screen that says the product is powered by something are the three that get cut most often. Each of them can be a line of text inside another screen.

For a flow with more steps than three, the education category of the template gallery has the structures worth borrowing: Course and Quiz and Lesson and Quiz show a multi-step path with progress, choices and a finish state. The mockup tutorial covers the mechanics of building and linking that set of frames.

• Every screen offers a way forward
• Merge a screen with no action into the next one
• Brand statements become a line of text elsewhere
• Longer paths belong in a course or setup flow

Note: A screen can be informational and still have an action, such as Got it, which closes the hint. The rule is about agency, not about content.

A checklist you can reuse

• The first screen states one promise in the user's words
• There are three screens, and each carries one idea
• Progress or Stepper shows where the person is
• The product is shown before the account request
• Skip is visible, equal in weight, and lands somewhere useful
• Every screen has an action the person can take
• The flow was walked in Present mode before review

Common mistakes to avoid

• Asking for the account first. An account form before anything has been shown asks for a promise with nothing behind it. Put the product in front first.
• Four screens that should be three. A flow of four usually means one screen carries no idea of its own. Merge it and keep the pace up.
• A hidden skip. A skip tucked in a corner or styled like an error reads as a trick. Show it with the same weight as the other options.
• A screen with no action. If nothing on the screen can be pressed, the person is stuck. Give it an action or fold it into the next screen.
• Listing features, not promises. Listing features asks the reader to evaluate you. One promise about their situation asks them to imagine it.

Frequently asked questions

How many onboarding screens are enough?

Three is the working limit for a first run. Each screen should carry one idea, and Progress or Stepper tells the reader how much is left. If your flow needs more than that, it is probably a setup flow the product genuinely needs rather than a welcome, and the two deserve different designs.

Should onboarding ask for an account?

Not on the first screen. Show one real thing first, so the request for an account comes after the person has seen what they came for. A well designed <a href="/blog/design-a-login-screen">login screen</a> is a calm place to ask, and it is much easier to complete once the promise has been made.

How do I show the product in a mockup?

Use the Image component to place a representative screen, photo or illustration on the first frame, and the Stat card or Empty state components from the reusable library to show the shape of the data the person will see. The design foundations guide on empty states covers how to say what will appear and offer one action.

Can I test two versions of the same onboarding?

Yes, and it is worth doing. Build the two versions in separate frames or separate workspace tabs, and compare what people continue from. Canvasola keeps 20 versions of history, and App Builder work is stored inside the .canv project file, so the two versions can be exported and sent for review as PNG or JSON.

This guide is part of the app builder guides collection. For the wider product tour, read the complete Canvasola guide, and keep the keyboard shortcut cheat sheet open while you work.