菜单
Use when evaluating first-run experience, progressive disclosure, onboarding tutorials, and how new users learn to use the product.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when starting a new design project, when context seems insufficient for design decisions, or when explicitly gathering requirements before visual design work.
Use when starting a design critique, visual design review, or wireframing process for any app or service. Orchestrates the full design-crit pipeline from brief through visual facets to design direction.
Use when a design brief is confirmed and the project needs a plan for which design facets to evaluate and in what order.
Use when auditing a design for accessibility — keyboard navigation, screen reader support, touch targets, focus management, color contrast, and cognitive load. Typically runs as the last facet to audit accumulated decisions.
Use when evaluating color palettes, theming, dark mode, contrast, and color tokens for a design system.
Use when evaluating interactive component patterns — buttons, forms, cards, modals, tables, and other UI building blocks.
基于 SOC 职业分类
| name | crit-onboarding-flows |
| description | Use when evaluating first-run experience, progressive disclosure, onboarding tutorials, and how new users learn to use the product. |
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).
Read these files before generating anything:
.design-crit/state.json -- current facet state, round number, all prior locked decisions.design-crit/brief.md -- project brief (core loop, target users, complexity, differentiator)../../reference/crit-loop.md -- shared crit loop mechanics../../reference/design-principles.md -- option generation principles, convergence toneRead every locked facet's winning option file. Onboarding touches the entire product. Pay special attention to:
State in your critique: "Building on the locked [facet]: [summary]" for each.
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.
From the brief, identify:
The most important metric for onboarding: how fast does the user reach the core 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:
For every step in the path, apply the deferral test:
| Step | Required Before Value? | Can Defer? | If Deferred... |
|---|---|---|---|
| Email verification | Maybe -- depends on security model | Yes: allow limited access unverified | Prompt after first value moment |
| Profile setup | No | Yes: use defaults, prompt later | Show setup CTA in profile area |
| Workspace config | Maybe | Partial: use smart defaults | Surface config when user hits a limitation |
| Invite team | No | Yes | Prompt after user has content to share |
| First project | Yes -- this IS the core value | No | This is the goal, not the blocker |
Every step that can be deferred SHOULD be deferred. Front-load only what is essential for the core experience.
| Product Type | Acceptable Steps to Value | Notes |
|---|---|---|
| Consumer app | 1-3 | Must be near-instant. Social proof, sample content, or magic link login. |
| SaaS tool | 3-5 | Account + one setup step + core action. Template or wizard helps. |
| Enterprise software | 5-10 | More tolerance, but each step must feel productive. |
| Developer tool | 1-2 | Developers expect zero hand-holding. Quick start, then docs. |
If the path exceeds the target for this product type, flag it in the critique.
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.
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:
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.
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.
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."
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:
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.
Generate onboarding flow wireframes with annotated step sequences.
Each option file (option-{x}.html) must contain:
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:
For each step in the flow, render a wireframe-level screen design:
Show what is visible at each user maturity stage:
| Feature / UI Element | First Session | After 3 Sessions | After 10 Sessions |
|---|---|---|---|
| Core action button | Highlighted with tooltip | Normal | Normal |
| Advanced settings | Hidden | "Discover" prompt | Visible |
| Keyboard shortcuts | Not shown | Tooltip on hover | Cheat sheet available |
| Team features | "Invite team" CTA | Sidebar section | Full team management |
For mobile apps or permission-requiring features, document:
| Permission | When Requested | Primer Message | Denial Fallback |
|---|---|---|---|
| Notifications | After first content created | "Get updates when..." | Banner with Settings link |
| Camera | When user taps photo upload | "Add photos to..." | File picker fallback |
| Location | When user opens map feature | "Find nearby..." | Manual location entry |
Score each option against these questions in your critique.
Generate 2-3 options that make different bets about onboarding philosophy.
Axes of variation:
Name each option by its onboarding philosophy:
Refine survivors based on feedback. Common refinements:
Reference these patterns when explaining options.
| Pattern | When It Works | Watch Out For |
|---|---|---|
| Tooltip walkthrough | Complex UI with many features, first-time only | Users dismiss without reading; more than 5 steps and completion drops sharply |
| Wizard/stepped flow | Products requiring setup (config, integrations, team) | Feels slow for repeat signups; needs skip option; each step must deliver visible value |
| Empty state onboarding | Simple products with one core action, content-creation apps | Does not work if the empty state does not communicate what to create; requires strong CTA copy |
| Sample/demo content | Products where empty state is not representative of value | Users confuse sample data with their own; must be clearly labeled and deletable |
| Video walkthrough | Products with complex workflows, visual/creative tools | Users skip videos; not accessible without captions; goes stale when UI changes |
| Contextual coach marks | Products where features are discovered over time | Can feel random; hard to ensure coverage; users may never trigger some marks |
| Checklist onboarding | Products with multiple setup steps, SaaS tools | Gamification can feel manipulative; checklist items must be genuinely useful, not busywork |
| Blank canvas + quick actions | Developer tools, creative apps, power user tools | New users freeze at blank canvas; need at least a prompt or template to start |
When generating compare.html, follow crit-loop.md with these additions:
The locked screen inventory defines which surfaces exist. Onboarding adds first-use variants of those screens (welcome overlays, empty states with guidance, tooltip layers) but does not add new screens to the inventory. If the onboarding requires a screen that does not exist, flag it: "This onboarding approach needs a welcome screen not in the inventory. Add it?"
Empty state designs from the edge states facet are onboarding surfaces. The first-use empty state IS the onboarding for that screen. Read the locked empty state approach and build on it. Do not redesign empty states -- layer onboarding onto them.
The locked onboarding must work with whatever navigation model is chosen later. Design onboarding to be navigation-agnostic where possible. If the onboarding depends on a specific navigation pattern (e.g., "sidebar is visible during tutorial"), note this as a constraint for the navigation facet.
All onboarding copy (welcome messages, tooltip text, permission primers, CTA labels) will be refined when the content voice facet runs. For now, write functional copy that communicates the intent clearly. Mark it as draft: the voice facet will tune the tone.
The accessibility audit will evaluate: keyboard navigation through onboarding flows, screen reader announcements for tooltips and coach marks, focus management during wizard steps, and whether the onboarding is completable without a mouse.
When the user locks an onboarding option:
state.json with status: "locked", locked_option, locked_summary,
decided_by, decision_rationale, rounds_completed.locked_summary must capture: onboarding philosophy (guided/exploratory/content-first),
step count to first value, deferral strategy (which steps are deferred), and key patterns
used (tooltips, wizard, templates, sample content).