Best onboarding blocks 2026: 9 verified sections

Onboarding takes a new person to their first useful result; it is not a tour. The catalogue counts 9 blocks from 3 registries, measured on 1 November 2026, and seven come from a single publisher: a sample of one design school, not of a market.

The failures start when the flow meets real life. The user fills two steps, reloads and lands back on the first; the browser back button leaves the flow instead of returning to the previous step; “Skip” saves nothing, so the tour reappears at the next login. These are state and URL defects, not drawing defects, and no preview shows them.

Why a refresh breaks everything

A single-file block keeps the steps in memory: an index, maybe a useState. As long as the user stays on the page it works; the moment they reload, the index resets to zero. Surviving a refresh needs three things a block cannot have by definition: a URL that changes on every step, state stored on the server, and a rule for resuming at the right point. Without those, the wizard is a demo.

Seven rows out of nine, one author

Ephraimduncan signs seven blocks with explicit names, workspace setup, steps with progress, accordion, activity feed, timeline, all single-file; flx contributes a welcome dialog, 1st-pouf a page. In total 9 files, 7 npm dependencies and 20 registry dependencies: the weight is low, the variety is one hand’s, and two of the seven are variants of the same progression idea.

The table, sorted by files

With one file per block the numeric column orders nothing: the name matters, because it names the kind of flow. “Workspace setup” asks for data and needs a form; “accordion” and “timeline” are content to read; “welcome” is a first-visit dialog. Three different problems requiring three different decisions about state.

The tests that expose an onboarding

Fill the second step, reload and see where you land. Then press back and check whether you leave the flow or return to the previous step. Then skip and reload: if the tour comes back, “Skip” saved nothing. Finally walk the steps with a screen reader: the step change must be announced, and the progress indicator must say where you are, not just colour a bar.

• A URL reflecting the step, so the back button works.
• State stored on the server and resumed at login, not only in memory.
• The progress indicator carries text and aria-current on the active step.
• Every step can be skipped, or the whole flow closed without losing the account.

curl "https://ui.eneawork.it/api/blocks/category/onboarding?limit=10"

The limit: presentation, not persistence

None of these blocks contains the logic a real onboarding needs: they are screens. A single-file block cannot also hold step persistence, resuming at login and the calculation of what to show someone who already finished. The category is derived from the title too, so a wizard called “Setup” lands elsewhere and a welcome dialog joins here without being a multi-step path.

Decision rule

Up to three steps, all skippable, a dialog is fine: it interrupts once and needs no URL. Beyond three, or when a step collects data that must survive a refresh, you need a dedicated route with server state and the step in the URL. The alternative is skipping the wizard: a checklist in the dashboard with three items to complete reaches the same result without blocking the user, and products that must show value early use it. A block pays off when it brings a progress drawing you do not want to rebuild, not when it is meant to manage state for you.

The blocks live under /blocks/category/onboarding, the inventory under /blocks, and “Onboarding Steps with Progress” has its page here. For multi-step form state read state in multi-step forms, for the shadcn implementation the shadcn multi-step form, and for copying against composing copy-paste versus headless.