Skip to main content

Onboarding Patterns

Onboarding shapes the crucial first impressions of your product. Good onboarding helps users understand value quickly; bad onboarding creates confusion and abandonment. This document covers patterns for effective first-run experiences.

Last updated: May 2024

Principles of effective onboarding

Show value before requiring effort

Users should experience why your product is useful before being asked to invest time (account creation, configuration, learning).

Teach through doing

Interactive exploration beats passive instruction. Let users try things rather than reading about them.

Progressive disclosure

Reveal complexity gradually. Don't explain everything upfront—introduce features as they become relevant.

Make it skippable

Some users want to explore on their own. Let them skip tutorials and onboarding flows (but make it easy to return).

First-run experience patterns

Product tour

Description: Guided walkthrough highlighting key features, typically with highlights and callouts.

When to use:

  • Complex interfaces where key features might be missed
  • When specific actions lead to "aha moments"
  • New feature introduction for existing users

Best practices:

  • Keep it short (3-5 steps maximum)
  • Focus on highest-value features, not comprehensiveness
  • Allow skip and exit at any point
  • Don't block access to the product
  • Show real interface, not separate screens

Accessibility requirements:

  • Focus management for each step
  • Keyboard navigation throughout
  • Screen reader announcements for each step
  • Allow completion via keyboard
Tour fatigue

Users often dismiss tours immediately. Don't invest heavily in elaborate tours—they may not be seen. Consider whether doing is better than touring.

Setup wizard

Description: Multi-step flow that configures the product for the user's needs.

When to use:

  • When initial configuration is necessary
  • When personalization significantly improves experience
  • When users have distinct use cases requiring different setups

Best practices:

  • Minimize steps—each step risks abandonment
  • Show progress (step 2 of 4)
  • Allow back navigation
  • Explain why each step matters
  • Save progress so users can return
  • Allow skipping non-essential steps

Examples:

  • Selecting workspace theme/preferences
  • Connecting integrations
  • Choosing role or use case
  • Importing existing data

Sample content / Template starts

Description: Pre-populate the product with example content users can explore and modify.

When to use:

  • When an empty product is confusing
  • When examples demonstrate value better than explanation
  • Creative tools, project management, productivity apps

Best practices:

  • Make sample content obviously sample (don't let users confuse it with their real data)
  • Make it easy to clear and start fresh
  • Samples should demonstrate product capabilities
  • Variety of samples can address different use cases

Inline tips and hints

Description: Contextual tips that appear near relevant features as users encounter them.

When to use:

  • As a lighter alternative to full tours
  • For explaining features when first used
  • For introducing new features to existing users

Best practices:

  • Appear only once (don't pester)
  • Dismissible immediately
  • Brief—one sentence if possible
  • Positioned near the feature they explain
  • Don't cover the thing being explained

Checklist approach

Description: List of tasks that guide users through key setup and first actions.

When to use:

  • When several independent actions contribute to getting started
  • When users benefit from clear next steps
  • When gamification/progress can motivate

Best practices:

  • Keep list short (5-7 items max)
  • Order by importance and logical sequence
  • Show completion progress
  • Allow items to be skipped
  • Celebrate completion appropriately
  • Consider hiding after completion

Empty state design

Empty states are part of onboarding—they're what users see before they have content.

What empty states should do

  1. Explain what belongs here: What will this space contain once populated?
  2. Guide the first action: Clear call-to-action for creating/adding
  3. Reduce intimidation: Make starting feel easy, not overwhelming
  4. Set appropriate expectations: What should users expect as they use this feature?

Empty state components

  • Illustration or icon: Visual interest, emotional tone
  • Headline: What this area is for
  • Description: Brief context or benefit
  • Primary action: Clear button/link to start
  • Secondary options: Alternative paths (import, templates, help)

Empty state variations

First-time empty: User has never used this feature

  • Emphasize getting started
  • May include educational content

Cleared empty: User had content but removed it all

  • Acknowledge the state
  • Provide quick action to add more

Search/filter empty: No results match criteria

  • Explain why (no matches)
  • Suggest how to get results (broaden search)

Error empty: Content couldn't load

  • Explain the problem
  • Offer retry or troubleshooting
Testing empty states

Test onboarding with people who've never seen your product. Your existing knowledge blinds you to confusion. Watch real first-time users struggle, and fix what they struggle with.

Progressive disclosure

Levels of disclosure

Level 1: Essential features visible immediately. Core actions obvious.

Level 2: Secondary features discoverable through exploration. Menus, settings, advanced options.

Level 3: Power features available but hidden. Keyboard shortcuts, advanced settings, customization.

Disclosure patterns

Expandable sections: "Advanced options" that expand on click Hover/focus reveals: Additional controls appearing on interaction Mode switches: Simple → Advanced mode toggles Just-in-time education: Teaching features when first relevant

Timing disclosure

Reveal features when:

  • User has demonstrated need (repeated workaround behavior)
  • Context makes feature relevant (editing an item reveals edit controls)
  • User explicitly requests (clicking "More options")

Don't reveal:

  • Everything at once
  • Before users can understand
  • In ways that disrupt current tasks

Measuring onboarding success

Key metrics

Activation rate: Percentage completing key first actions Time to value: How long until users experience core benefit Drop-off points: Where users abandon during onboarding Feature adoption: Whether users discover and use key features Return rate: Whether users come back after first session

Qualitative signals

  • User confusion during sessions
  • Support requests from new users
  • Feedback about "figuring out" the product
  • Workarounds indicating missed features
How long should onboarding be?

As short as possible while achieving its goals. Users are impatient during onboarding—they came to use the product, not learn about it. Cut ruthlessly.

Should I require account creation before onboarding?

If possible, no. Let users experience value first. Account creation is a barrier—place it after users are convinced the product is worth the effort.

How do I onboard users to new features?

Similar patterns: announcements, inline tips, changelogs. But be more subtle—existing users didn't ask for education. One-time, dismissible, contextual hints work well.

What if users skip onboarding?

Make sure the product is usable without it. Provide ways to access onboarding content later (help menu, documentation). Don't punish skippers—respect their choice.

Should onboarding be mandatory?

Rarely. Mandatory onboarding frustrates users who want to explore. If certain setup is truly required, make it short and purposeful.