How to design an onboarding flow
Structure a wizard, decide what to ask upfront versus what to defer, write clear step copy, and give users a satisfying completion moment — all using the Sitka onboarding pattern.
Objective
By the end of this guide you will be able to design a focused onboarding wizard that collects only what is necessary, gives users clear orientation at every step, and ends with a completion moment that sets up the first session.
Decide what belongs in onboarding
Onboarding has a single job: get the user to their first moment of value as quickly as possible. Every question or step you add delays that moment. Before building a step, ask: can we get this information after the user is already in the product?
Ask in onboarding
- ✓Information without which the product cannot function (account credentials, locale, required legal consent)
- ✓Personalisation that changes what the user sees on their very first session
Defer to settings
- →Preferences that have a sensible default (notification frequency, colour theme)
- →Information that can be inferred or populated progressively (team size, billing details)
Aim for three steps or fewer. Research consistently shows completion rates fall sharply after step four. If you have five or more steps, look for fields to remove entirely.
Structure each step clearly
Every step in the wizard needs the same four elements. Skipping any one of them increases drop-off.
Write the step copy
Onboarding copy has to earn its place at every line. Users are impatient and task-focused here more than anywhere else in the product.
Before
Tell us a bit about yourself so we can personalise your experience
After
What's your role?
Remove all preamble. Get to the question.
Before
Almost there! Just a few more details and you'll be ready to go.
After
Set your notification preferences
Motivational filler wastes time. Name the task.
Before
By clicking Continue you agree to our Terms of Service and Privacy Policy
After
I agree to the Terms of Service and Privacy Policy
Make the user the subject of the consent, not the button.
Before
Next
After
Create workspace
Name what happens when the user taps Continue.
Handle skipping and going back
Users need to feel in control. Both a back affordance and an optional skip should be present whenever they are valid actions.
| Action | Placement | When to show |
|---|---|---|
| Back | Top-left or inline secondary button | Always, from step 2 onwards. Never disable it. |
| Skip | Text link, below primary CTA | Only on optional steps. Don't show it on required steps — it implies required steps are also skippable. |
| Exit / Save & exit | Top-right or overflow menu | Long or complex flows where the user may need to pause and return. |
Never block the Back button to prevent users from changing their answers. If a previous step's answer affects later steps, update the later steps to reflect the change — don't trap the user.
Design the completion moment
The final screen is a transition, not a dead end. It should confirm success, set expectations for what comes next, and move the user into the product with clear first-session guidance.
Confirm success
Use a clear visual signal (checkmark, illustration) and a short headline that names what was created. "Your workspace is ready." not "Onboarding complete."
Set next-session expectations
One sentence about what happens next: "You'll get an email when your team accepts your invite." This prevents users from returning confused.
Bridge to first action
The CTA should be the most valuable first action in the product, not the dashboard. "Invite your team", "Create your first project", "Connect your data source".
See the Onboarding pattern for the interactive reference implementation, including the StepIndicator component and completion screen layout.