Onboarding and Empty States

A product that works perfectly for established users can be completely opaque to a new one. The first-run experience — what the user sees before they have created anything, configured anything, or understood the product’s shape — is where many users decide whether to continue or leave. Onboarding and empty states are not edge cases. They are the first interaction most users ever have.

What onboarding is

Onboarding is the set of interactions that help a new user understand what a product is, what it can do, and how to get started. It is not a tutorial imposed on all users — it is the thoughtful design of a first-run path that gets users to their first success as quickly as possible.

The goal of onboarding is a single concrete outcome: the user’s first meaningful action. For a project management tool, that is creating a project. For a writing app, writing a first document. For a communication platform, sending a first message. Everything in onboarding should be directed toward that one outcome, not toward explaining every feature.

Patterns for onboarding

Contextual onboarding reveals guidance in context, at the moment it is relevant — a tooltip on first use of a feature, a helper text explanation the first time a user encounters a complex field, a guided highlight when the user first opens a settings panel. Contextual onboarding does not interrupt the user before they need help; it surfaces help when the user’s attention is already on the relevant part of the interface.

Checklist onboarding presents a list of setup tasks that define the initial configuration state: “Connect your calendar”, “Invite a team member”, “Create your first project.” Checklists work well when the product genuinely has a setup phase with multiple independent steps. They fail when the checklist has so many items that completion feels impossible, or when the checklist tasks are not actually necessary to get value from the product.

Guided setup walks the user through a linear sequence of configuration steps before they reach the main product. Use it only when the product genuinely cannot be useful without initial setup — choosing a plan, entering account details, selecting core preferences. Do not use it to delay access to the product while explaining features the user has not yet encountered.

Blank slate onboarding skips explicit guidance and instead designs the empty interface to be self-explanatory. The first-run empty state IS the onboarding: it communicates what the product is for, and provides a clear path to starting. This is the most elegant approach when the product is simple enough that one well-written empty state can do the work.

Principles for all onboarding patterns

Skippable and resumable. Users who already understand the product — returning users, users who imported data from another tool, users who signed up via an invitation — should be able to skip onboarding entirely. Mandatory tours and forced tutorials block experienced users and communicate distrust of the user’s judgment. Design onboarding as a path users can exit at any moment, and ensure it can be revisited from settings or a help menu.

No overwhelming information upfront. Showing every feature in a pre-use tutorial means showing features the user has no context for. They will not remember, and the tour will feel like an obstacle. Reserve feature explanation for the moment the user encounters the feature, not before.

Keyboard and screen reader accessible. Onboarding flows frequently use custom UI — modals, overlays, tooltips, guided highlights — that fails accessibility testing. Spotlight overlays must not trap focus outside the overlay. Tooltips must be reachable by keyboard. Multi-step modals must manage focus correctly between steps. Test onboarding with keyboard-only navigation before shipping.

Empty states

An empty state is any context where a layout designed for content contains no content yet. Every content-bearing interface has multiple distinct empty states, each with a different cause and a different appropriate response.

First-use empty state — the user has not yet created anything. This state is temporary and opportunity-rich: the layout’s job is to communicate what should go here and give the user a clear single action to begin. The standard structure is: a simple illustration or icon (suggesting the content type), a short heading (“No projects yet”), one explanatory sentence, and a primary CTA (“Create your first project”). Keep it focused — this is not the place for a feature list.

Search with no results — the user searched for something that does not exist in the current dataset. The layout must confirm that the search was processed (display the search term clearly), explain the outcome (“No results for ‘typography’”), and offer recovery paths: suggestions for alternative terms, a link to browse by category, or an offer to search more broadly. Never show a blank grid with no context — the user needs to know why the grid is empty, not just that it is.

Filtered to zero — the user applied filters that exclude all results. Show which filters are active and provide a prominent single action to clear them. “No results match your filters” with a “Clear filters” button is the minimum. Never display an empty grid with active filters and no indication of the cause — users consistently interpret this as a system error rather than a filter conflict.

Error empty state — the content failed to load due to a network or system error. This is distinct from “no content exists” — the user should know their content exists but is temporarily unavailable. Provide the error reason, an action to retry, and a support path if retrying fails.

Distinguishing empty states from loading states

An empty state and a loading state look superficially similar — a container with no visible content — but communicate completely different things. A loading state says “content is coming.” An empty state says “there is no content.” The visual distinction must be unambiguous: a loading skeleton or spinner for loading, the empty state illustration/text pattern for absence. Showing an empty state while content is loading causes users to start creating duplicate content; showing a spinner when content genuinely doesn’t exist leaves users waiting indefinitely.

The takeaway

Design the empty states before the populated interface. If you cannot articulate what each empty state communicates and what action it offers, the layout has not been fully designed. First-run empty states are not placeholder screens to fill later — they are the product’s first impression for every new user, and the most important onboarding tool most products have.