metedata/design-crit/crit-onboarding-flows

Onboarding Flows Crit

Reference: Read ../../reference/crit-loop.md for compare view, feedback round-trip, convergence, and locking mechanics.

You are a designer critiquing how new users learn this product. Onboarding is the bridge between "I signed up" and "I get value." Every screen, tooltip, permission request, and sample content either accelerates or blocks that journey. Most products fail here -- they either dump everything on the user at once or provide so little guidance that users churn before discovering the core value.

Onboarding sits in the structural lens. It depends on screen-inventory (the surfaces the user will navigate) and edge-states (first-use empty states are onboarding surfaces). It feeds into nearly every downstream facet: navigation (users must learn wayfinding), layout (first-run variants of screens), component design (tooltips, coaches, wizards), content voice (onboarding copy tone), and accessibility (onboarding must be keyboard and screen-reader accessible).

1. Load Context

Read these files before generating anything:

1. .design-crit/state.json -- current facet state, round number, all prior locked decisions
2. .design-crit/brief.md -- project brief (core loop, target users, complexity, differentiator)
3. ../../reference/crit-loop.md -- shared crit loop mechanics
4. ../../reference/design-principles.md -- option generation principles, convergence tone

Prior Locked Decisions

Read every locked facet's winning option file. Onboarding touches the entire product. Pay special attention to:

• Screen inventory -- which screens exist, what the happy path flow looks like, how many

screens the user must traverse to reach core value

• Edge states -- first-use empty states are the primary onboarding surfaces. Read what

empty state approach was locked (instructional, illustrated, starter content, progressive disclosure)

State in your critique: "Building on the locked [facet]: [summary]" for each.

Detect Existing Feedback

Check for feedback-round-{N}.json in .design-crit/facets/onboarding-flows/. If found and unprocessed, read it and continue the crit loop from that round.

Extract Brief Signals

From the brief, identify:

• Core loop -- what is the primary action the user must learn? This is the onboarding

destination. Everything in the onboarding flow exists to get the user to this action.

• Target users -- technical sophistication, familiarity with similar products, motivation

level. A developer onboarding to a CLI tool is different from a consumer onboarding to a social app.

• Learning curve -- how many concepts must the user learn before they can do the core

task? Products with high concept count need progressive disclosure. Products with simple core loops need minimal onboarding.

• Platform -- mobile apps have system permission requests (camera, notifications, location)

that must be sequenced. Web apps have fewer permission barriers.

• Differentiator -- what makes this product unique? Onboarding should highlight the

differentiator, not generic features.

2. Time-to-Value Analysis

The most important metric for onboarding: how fast does the user reach the core value?

Map the Path to First Value

Starting from account creation (or first visit), count every screen, form field, and decision the user must complete before they experience the core loop.

[Sign up] -> [Email verify] -> [Profile setup] -> [Workspace config] -> [Invite team] ->
[First project] -> [CORE VALUE]

Each arrow is a potential drop-off. Count the steps. For each step, ask:

• Is this step required BEFORE the core value, or can it be deferred?
• Can this step be simplified (pre-fill, default, skip)?
• Does this step teach something essential, or is it administrative?

The Deferral Test

For every step in the path, apply the deferral test:

Every step that can be deferred SHOULD be deferred. Front-load only what is essential for the core experience.

Time-to-Value Targets

If the path exceeds the target for this product type, flag it in the critique.

3. Onboarding Pattern Vocabulary

Account Setup

The first gate. Keep it minimal.

Progressive profiling -- collect only what is needed now. Ask for name and email at signup. Ask for role and company during the first session. Ask for preferences after the user has context. Never front-load a 10-field form.

Smart defaults -- pre-fill every field you can. Detect timezone from browser. Default to the most common options. Show defaults as editable, not blank fields.

Social/SSO login -- reduce signup friction to one click. Google, GitHub, Apple depending on audience. Show password signup as secondary, not primary.

Welcome and Orientation

The first thing the user sees after signup.

Welcome screen -- a single screen that sets expectations. "Here's what you can do." Keep it to 3 bullet points max. Include a primary CTA to start the core task.

Product tour / tooltip walkthrough -- sequential tooltips pointing at key UI elements. Use when the UI is complex and the user needs a spatial map.

Design rules for tooltip tours:

• Maximum 5 steps. Beyond 5, users dismiss and forget.
• Each tooltip must be dismissible AND skippable (skip all remaining).
• Tooltips should point at real, interactive UI -- not screenshots or diagrams.
• Trigger the action, not just explain it. "Click here to create your first project" with

the create button highlighted, not "This button creates projects."

• Persist progress. If the user closes the tab mid-tour, resume where they left off.

Contextual discovery -- no upfront tour. Instead, surface guidance where the user needs it, when they need it. A tooltip appears the first time the user visits a screen. A callout appears when the user encounters a feature for the first time.

Progressive Disclosure

Teach the product in layers. Do not show advanced features to beginners.

Feature gating by usage -- basic features visible by default. Advanced features revealed after the user has used the basics. "You've created 5 projects. Did you know you can create templates?"

Collapsible complexity -- show the simple interface first with an "Advanced options" expandable section. The user learns the simple version first and graduates to the full interface on their own.

Level-based revelation -- explicit "beginner / intermediate / advanced" modes that the user can toggle, or that automatically unlock based on usage patterns.

Permission Requests

On mobile (and increasingly on web), permissions must be requested at runtime.

Timing principle: Request permissions at the moment of relevance, not at first launch. Do not ask for notification permissions before the user has content that generates notifications. Do not ask for camera access until the user taps "take photo."

Pre-permission primer -- before the system dialog appears, show your own screen explaining WHY you need this permission and WHAT the user gets. "We'd like to send you notifications when your team mentions you. Allow notifications?" THEN trigger the system dialog. Users are more likely to accept after understanding the benefit.

Denial handling -- if the user denies a permission, do not immediately re-ask. Show a degraded experience with a persistent but non-intrusive option to enable later: "Notifications are off. Enable them in Settings to get updates."

Sample / Demo Content

Pre-populated content that shows the user what a "full" product looks like.

When to use: Products where the empty state does not communicate the value proposition. A project management tool with no projects looks like an empty spreadsheet. A project management tool with a sample project shows the user what they are building toward.

Design rules:

• Label sample content clearly: "[Sample] Getting Started Project" or a banner "This is

sample data. Delete it anytime."

• Make sample content editable and deletable -- the user learns by modifying it.
• Use realistic content that matches the product's domain. A CRM sample should have plausible

contact names, not "Test User 1."

• Do not count sample content toward usage limits or storage.

Empty State as Onboarding

The locked edge states facet defined empty state designs. Here, leverage those empty states as the primary onboarding mechanism.

Content is the teacher -- instead of explaining the product, prompt the user to create their first piece of content. "No notes yet. Write your first note." The act of creating teaches the product better than any tour.

Template picker -- instead of a blank canvas, offer 3-5 templates that pre-populate the first item. "Start from: Blank / Meeting Notes / Project Brief / Weekly Plan." Templates reduce blank-canvas anxiety and teach by example.

4. Artifact Type

Generate onboarding flow wireframes with annotated step sequences.

Each option file (option-{x}.html) must contain:

Flow Diagram

A visual sequence showing every screen the user sees from signup through first core value moment:

[Signup] -> [Welcome] -> [Setup Step 1] -> [Core Action] -> [First Value]

Render as connected boxes with labeled transitions. For each step, annotate:

• Step number and estimated time to complete
• Whether this step is required or deferrable
• What the user learns at this step

Screen Wireframes

For each step in the flow, render a wireframe-level screen design:

• Signup screen -- form fields, social login options, CTA
• Welcome/orientation -- content, illustrations (placeholder), CTA
• Setup steps -- form fields with smart defaults shown, skip options
• Permission primers -- explanation + benefit statement + accept/decline
• First-use screen -- the core screen with onboarding overlay (tooltip, callout, or

empty state CTA)

• First value moment -- what the user sees after completing their first core action

Progressive Disclosure Map

Show what is visible at each user maturity stage:

Permission Request Sequence

For mobile apps or permission-requiring features, document:

5. Evaluation Criteria