Onboarding is the only flow where the product asks for effort before it has given anything. Every screen you add is a place to leave, which is why the design question is never "how do we make the tour nicer" but "how few steps can this be, and can any of them happen later".
The components below are the four shapes onboarding takes, and the rules that decide whether each one converts or leaks.
The multi-step form
The workhorse: split a long form into stages so it does not read as a wall. Multistep Form by Arihant jain and Multistep Form by Jatin Yadav are the two shapes, and Registration Stepper by Ravi Katiyar is the sign-up-specific one.
Four rules keep it honest. Show the total up front, because "step 2 of 3" is a promise and a bare "next" is not. Validate per step rather than at the end, so nobody reaches step four to be told step one was wrong. Persist between steps, since a refresh that empties the form is the most expensive bug in this pattern. And let people go back without losing what they typed.
The one to be strict about: never split a form that fits on one screen. Three fields across three steps is three times the friction for the same data.
The onboarding dialog
Onboarding Dialog by Patrick Xin is the introduction that appears after the first sign-in, and Onboard Card by amanshakya307 is the inline version.
It carries every dialog obligation - focus in, focus trapped, Escape closes, focus returns, covered in the dialog guide - plus one of its own: it must be skippable. A modal that cannot be dismissed before the reader has seen the product is a wall, and the skip link needs to be visible rather than hidden in a corner.
The checklist
The pattern with the best evidence behind it: a short list of setup tasks the reader completes at their own pace, visible on the dashboard. Onboarding Checklist by Ravi Katiyar is the shape.
It works because it inverts the trade. Nothing blocks, the reader sees the product first, and each item is a small win with visible progress. Three rules: keep it under about five items, tick the ones already done rather than asking again, and let it be dismissed permanently once it is finished, because a completed checklist that stays on the dashboard becomes furniture.
The collect-later form
Onboarding Form by Ravi Katiyar is the profile-completion shape. The design decision it represents is the important one: almost everything you want to know can be asked after the reader has seen value, and asking before is how a sign-up becomes an abandonment.
The stepper's accessibility contract
A step indicator is a list with a current item, and that is the whole markup: an ordered list, with the current step carrying aria-current="step". A row of numbered circles built from divs communicates nothing.
Three more that get missed. Moving to the next step has to move focus to the new step's first field or its heading, or a keyboard user is stranded at the bottom of the page. Errors need announcing in a live region, not just outlining in red. And the step's heading should change the page title in a single-page flow, because a screen reader user gets no other signal that the screen changed.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| shadcn/ui | Dialog, Progress and the form primitives underneath | No stepper, no checklist |
| React Hook Form | Per-step validation and state across stages | Not a visual layer |
| Driver.js / product tour tools | Spotlight tours over an existing interface | Tours are the least-liked onboarding shape for a reason |
| 21st | Steppers, checklists, dialogs and multi-step forms | Quality varies by author, so preview before you take it |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue. The 21st MCP covers the same ground without leaving the editor: ask Claude, Cursor or Codex for an onboarding flow, get the previews inline, and let the agent write the file.
Browse onboarding components →
Frequently asked
- When should a form be split into steps?
- Only when it does not fit on one screen. Three fields across three steps is three times the friction for the same data. When you do split it, show the total up front, validate per step so nobody reaches step four to learn step one was wrong, persist between steps, and let people go back without losing what they typed.
- What is the best onboarding pattern?
- A checklist on the dashboard, for most products. It blocks nothing, the reader sees the product first, and each item is a small win with visible progress. Keep it under about five items, tick the ones already done rather than asking again, and let it be dismissed permanently once complete or it becomes furniture.
- How do you make a stepper accessible?
- It is a list with a current item: an ordered list with aria-current="step" on the active one. Moving to the next step must move focus to that step's first field or heading, errors need announcing in a live region rather than only turning red, and in a single-page flow the page title should change with the step.
- Should an onboarding dialog be skippable?
- Yes, and visibly. It carries every dialog obligation about focus and Escape, plus one of its own: a modal that cannot be dismissed before the reader has seen the product is a wall. Put the skip control where it can be found rather than hiding it in a corner.