Impeccable Onboard：设计让用户快速触达价值的首次使用流程、空状态与激活路径

导读

本篇讲解 Impeccable 设计技能体系中 onboard 命令所承载的核心方法论：如何为产品设计 onboarding（首次使用引导）、空状态与激活路径，把新用户最快带到“aha moment”（第一次觉得产品值得用的时刻）。在 Impeccable 的定位中，onboard 是“Refine（精修）”类命令之一，面向注册流程、欢迎屏、空状态、功能发现等界面设计工作。读完本文，你将掌握一套从需求评估、体验设计到实现模式与质量验证的完整 onboarding 设计流程，可直接用于你自己的产品、落地页或组件库设计任务。

一、onboard 在 Impeccable 中的定位

Impeccable 是一套让 AI 辅助设计工具具备更高设计能力的设计语言与技能包。在它的命令矩阵中，onboard 被归类为 Refine 类型命令，描述为：

Design onboarding flows, first-run experiences, and empty states that guide new users to value. Covers welcome screens, account setup, progressive disclosure, contextual tooltips, feature announcements, and activation moments.

（设计 onboarding 流程、首次使用体验与空状态，引导新用户抵达价值点；覆盖欢迎屏、账户设置、渐进式披露、场景化 tooltip、功能公告与激活时刻。）

当用户表达“onboarding、首次用户、空状态、激活、快速上手、新用户流程、aha 时刻”等意图时，应当触发该命令并加载 skill/reference/onboard.md（.kiro 等各宿主目录下的副本内容一致，例如 .kiro/skills/impeccable/reference/onboard.md）。该文件的完整方法论定义见 skill/SKILL.src.md 的命令表与 skill/scripts/command-metadata.json 中的机器可读元数据。

从源码结构看，Impeccable 会把界面按“访客成功的样子”划分成 Persuade / Operate / Read / Experience 等模式，而 onboarding 与空状态往往横跨这些模式出现，因此 onboard 方法论的适用对象既包括纯新手的产品内引导，也包括 Operate 型工具界面的空态设计。

二、核心理念：onboarding 的任务不是教学，而是尽快交付首次价值

原文开门见山给出全文最关键的一句话：

Get users to first value as fast as possible. Onboarding's job is not to teach the product. Its job is to get people to the moment that proves the product is worth their time.

翻译过来就是：onboarding 的职责不是教会用户全部产品功能，而是用最快的速度把用户带到“这个产品值得我花时间”的那个证明时刻。 由此导出一条 CRITICAL 红线：

Onboarding should get users to value as quickly as possible, not teach everything possible.

这条原则贯穿后面所有小节：欢迎屏要克制、核心概念只讲 1-3 个、功能特性放到用户真正需要的时刻再教（Context Over Ceremony）、能跳过就绝不强制。任何“把用户摁在引导里把所有功能都讲一遍”的设计都是需要警惕的反模式。

三、评估 Onboarding 需求（Assess Onboarding Needs）

动笔之前先回答三组问题，明确“用户需要学什么、为什么要学”：

1. 识别挑战（Identify the challenge）

• 用户试图完成什么？（What are users trying to accomplish?）
• 当前体验中什么令人困惑或不清晰？
• 用户在哪个环节卡住或流失？
• 我们希望用户抵达的 “aha moment” 是什么？

2. 理解用户（Understand the users）

• 经验水平如何？（新手 / 高级用户 / 混合群体）
• 动机是什么？（兴奋地主动探索，还是被工作要求被动使用）
• 愿意投入多少时间？（5 分钟还是 30 分钟？）
• 他们知道哪些替代方案？（从竞品迁移过来，还是对这个品类完全陌生？）

3. 定义成功（Define success）

• 用户要获得成功，最少需要学会什么？
• 我们希望用户采取的关键动作是什么？（创建第一个项目？发出第一条邀请？）
• 如何判断 onboarding 生效了？（完成率？触达价值的时间？）

在 Impeccable 的工程语境中，这些评估最终要落到可测量的界面上：command-metadata.json 中 onboard 的能力面覆盖 “welcome screens, account setup, progressive disclosure, contextual tooltips, feature announcements, and activation moments”，对应的验证指标则见第七节的完成率、跳过率与 time-to-value 等观测项。

四、Onboarding 设计的五大核心原则

4.1 Show, Don't Tell（展示而非说教）

• 用可运行的示例演示，而不是长篇描述；
• 在 onboarding 中提供真实可用的功能，而不是一个与真实产品脱节的独立“教程模式”；
• 使用渐进式披露（progressive disclosure），一次只教一件事。

4.2 Make It Optional（尽量让引导可跳过）

• 让有经验的用户可以直接跳过 onboarding；
• 不要阻断对产品的访问；
• 始终提供 “Skip” 或 “I'll explore on my own” 之类的选项。

4.3 Time to Value（时间到价值）

• 尽可能快地让用户触达 “aha moment”；
• 把最重要的概念前置；
• 教“能带来 80% 价值的 20% 内容”；
• 把高级功能留给场景化发现（contextual discovery），不要在开头全倒出来。

4.4 Context Over Ceremony（情境优先于仪式）

• 在用户真正需要某个功能时才教它，而不是一开始就全部讲授；
• 空状态本身就是 onboarding 的机会；
• tooltip 与提示应该出现在使用现场（point of use）。

4.5 Respect User Intelligence（尊重用户智商）

• 不要居高临下、不要过度解释；
• 简洁清晰；
• 默认用户能自行理解业界标准模式。

五、设计具体的 Onboarding 体验

5.1 初始产品引导（Initial Product Onboarding）

欢迎屏（Welcome Screen） 需要包含四要素：清晰的价值主张（这是什么产品）、用户将学到/完成什么、诚实的时间预估（不夸大投入成本）、可跳过选项（面向有经验用户）。

账户设置（Account Setup） 应遵循最小化原则：只收集最少必要信息，更多信息留到之后；对每一处询问解释“为什么问这个问题”；尽可能提供智能默认值；合适时提供社交登录。

核心概念引入（Core Concept Introduction）：只引入 1-3 个核心概念（不是全部）；用简单语言和示例；尽量可交互（“做”，而不是只“读”）；给出进度指示（例如 “步骤 1 / 3”）。

第一次成功（First Success）：引导用户完成一件真实的事；提供预填充的示例或模板；庆祝完成（但不过度）；给出清晰的下一个步骤。

5.2 功能发现与采纳（Feature Discovery & Adoption）

空状态（Empty States）：不要留下空白页面，而是展示：这里将出现什么（描述 + 截图/插图）、它为什么有价值、清晰的“创建第一个条目”CTA、示例或模板选项。原文给出的标准示例结构：

No projects yet
Projects help you organize your work and collaborate with your team.
[Create your first project] or [Start from template]

场景化 Tooltip：在相关时刻出现（用户第一次看到该功能时）；直接指向相关 UI 元素；简短说明 + 收益；可关闭（并提供 “Don't show again” 选项）；可选 “Learn more” 链接。

功能公告（Feature Announcements）：新功能发布时高亮它；说明“新增了什么、为什么重要”；让用户能立刻试用；可关闭。

渐进式 Onboarding：在用户真正遇到功能时再教；用角标或指示标记提示新的/未使用的功能；逐步释放复杂度（不要一上来展示全部选项）。

5.3 引导式导览（Guided Tours & Walkthroughs）

适用场景：功能繁多的复杂界面；现有产品发生重大变更；需要领域知识的行业专用工具。

设计要点：用 spotlight 高亮特定 UI 元素（调暗页面其余部分）；每段导览保持简短（最多 3-7 步）；允许用户自由点击穿行；提供 “Skip tour” 选项；可在帮助菜单中回放。

最佳实践：交互优于被动（让用户点击真实按钮）；聚焦工作流而非功能（应写“创建一个项目”，而不是“这是项目按钮”）；提供示例数据以保证操作真的能成功。

5.4 交互式教程（Interactive Tutorials）

适用场景：用户需要动手练习；概念复杂或陌生；高风险场景（在安全环境里练习更好）。

设计要点：带示例数据的沙箱环境；清晰目标（例如“创建一张按地区显示销售额的图表”）；逐步指引；校验（确认用户做对了）；“毕业时刻”（你可以了！）。

5.5 文档与帮助（Documentation & Help）

产品内帮助：界面中处处提供场景化帮助链接；快捷键速查表；可搜索的帮助中心；复杂工作流提供视频教程。

帮助模式：复杂功能旁放 ? 图标；tooltip 中放 “Learn more” 链接；快捷键提示（如在搜索框旁显示 ⌘K）。

六、空状态设计规范

每一个空状态都必须回答四个问题并提供视觉吸引力：

要素	示例文案/做法
这里将出现什么（What Will Be Here）	“你的最近项目将出现在这里”
它为什么重要（Why It Matters）	“项目帮助你组织工作并与团队协作”
如何开始（How to Get Started）	[创建项目] 或 [从模板导入]
视觉趣味（Visual Interest）	插图或图标（而不是白屏上一行干巴巴的文字）
场景化帮助（Contextual Help）	“需要帮助快速上手？[观看 2 分钟教程]”

五种空状态类型（Empty state types），设计重心各不相同：

• 首次使用（First use）：用户从没用过该功能 —— 强调价值、提供模板；
• 用户清空（User cleared）：用户主动删光了所有内容 —— 轻触提醒、便于重建；
• 无结果（No results）：搜索或筛选没有命中 —— 建议更换查询词、清除筛选器；
• 无权限（No permissions）：无法访问 —— 解释原因、告知如何获得访问权；
• 错误状态（Error state）：加载失败 —— 说明发生了什么、提供重试选项。

七、实现模式（Implementation Patterns）

技术选型（原文列举的通用方案）：

• Tooltip 库：Tippy.js、Popper.js；
• Tour 库：Intro.js、Shepherd.js、React Joyride；
• Modal 模式：focus trap（焦点陷阱）、backdrop（遮罩）、ESC 关闭；
• 进度跟踪：用 LocalStorage 记录 “seen” 状态；
• 分析：追踪完成率、流失点。

注意：这些是原文档给出的业界通用实现选项，并非 Impeccable 仓库自带依赖；接入时请按自己项目的技术栈与许可证选择合适的库。

存储模式：用持久化键记录用户已看到的引导步骤，避免重复打扰：

// Track which onboarding steps user has seen
localStorage.setItem('onboarding-completed', 'true');
localStorage.setItem('feature-tooltip-seen-reports', 'true');

IMPORTANT：同一段 onboarding 绝不展示两遍（那会令人厌烦）。务必记录完成状态并尊重用户的关闭选择。

NEVER（绝对禁区）：

• 强迫用户在能使用产品之前先走完漫长的 onboarding；
• 用显而易见的解释把用户当小孩；
• 反复展示同一个 tooltip（尊重关闭选择）；
• 在导览期间屏蔽全部 UI（让用户能自由探索）；
• 创建与真实产品脱节的独立教程模式；
• 一上来用过量信息压垮用户（要坚持渐进式披露！）；
• 隐藏 “Skip” 按钮或把它藏得很难找；
• 忘记回访用户（不要再给他们看一遍初始引导）。

八、验证 Onboarding 质量

用真实用户测试，并观察以下指标：

• 完成时长（Time to completion）：用户能否快速走完 onboarding？
• 理解度（Comprehension）：完成后用户是否真的懂了？
• 行动（Action）：用户是否采取了期望的下一步？
• 跳过率（Skip rate）：是否太多人跳过？（可能说明它太长或没有价值）
• 完成率（Completion rate）：用户是否完成？（若偏低，就简化）
• 时间到价值（Time to value）：用户多久才获得第一次价值？

这些指标与原文档开头的“Define success”一一呼应：onboarding 是否生效，最终看的是“用户在 aha moment 来得足够快、且没有中途流失”，而不是引导本身有多华丽。

九、在 Impeccable 流程中收尾

当用户快速触达 aha moment 且没有流失后，onboarding 的专项工作即告完成。此时按 Impeccable 的工作流约定，应将产物交给 polish 命令做最终质量收尾（原文表述为 hand off to /impeccable polish）。在 Impeccable 的命令谱系中，onboard 属于 Refine 类别（见 skill/SKILL.src.md），它与 polish（上线前的最终质量检查）、harden（错误态与边界情形）、clarify（UX 文案）等命令相互衔接：onboard 负责把新用户带到价值点，而 polish 负责在发布前把引导界面本身的对齐、间距、一致性与微细节打磨到位。整体命令入口与各命令说明可在 README.md 与 skill/scripts/command-metadata.json 中查阅。

一个高质量的产品 onboarding 往往同时调用这组能力：onboard 定流程与结构，clarify 打磨空状态与按钮上的文案，harden 覆盖无权限、加载失败等边界空态，最后由 polish 完成上线前收尾。理解了这一协作方式，你就能把本文的方法论放进 Impeccable 的完整设计工作流中使用。