企业官网建设流程全解析

impeccable 之 onboard 设计指南：如何打造直达"顿悟时刻"的首次使用体验、空状态与激活路径

【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable

本文是 impeccable 技能体系中 onboard 参考文档 的深度解读与实战展开。onboard 对应/impeccable onboard [target]命令，属于 impeccable 的 Refine（精修）范畴，用于设计首次使用流程（first-run flows）、空状态（empty states）与激活路径（activation paths）。读完本文，你将掌握一套可直接执行的引导式设计方法论：如何评估新用户真正需要学会什么、如何设计欢迎屏与空状态、如何用渐进披露把复杂功能"按需投喂"给用户，以及如何用可量化的指标验证引导是否真的把用户带到了价值点。

impeccable 是"让 AI 设计助手更懂设计"的设计语言，其 SKILL.md 把命令划分为 Build / Evaluate / Refine / Enhance / Fix / Iterate 几类，onboard与polish、distill、harden同属 Refine。命令元数据 对 onboard 的触发条件描述得很清楚：当用户提到 onboarding、首次使用者、空状态、激活、上手流程、新用户流程或"顿悟时刻（aha moment）"时，应加载本文对应参考文档并按其执行。

一条总纲：onboard 的职责不是"教产品"，而是把人送到价值面前

原文档开门见山给出了一条可能颠覆直觉的判断：

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.

（onboard 的职责不是教用户使用产品，而是把用户带到那个能证明产品值得他们花时间的瞬间。）

这条总纲贯穿全文所有决策：每一次引导内容取舍、每一个空状态文案、每一步向导长度，最终都服务于"更快抵达首个价值"这一目标。文档还明确标注了执行前需要向用户确认的额外上下文（Additional context needed）：你希望用户达到的"顿悟时刻"是什么，以及用户自身的经验水平。这两点是 onboard 一切工作的输入前提——没有定义价值时刻，引导就会退化成功能说明书。

在 impeccable 的产品语境里，"顿悟时刻"也出现在 onboard 命令元数据 中，被表述为 "activation moments"（激活时刻）。这意味着它不止是一个 UX 术语，更是 onboard 命令要交付的可设计对象。

第一步：评估引导需求（Assess Onboarding Needs）

动手设计之前，先回答三组问题，避免凭直觉堆功能教学。

1. 识别挑战（Identify the challenge）

• 用户想完成什么？
• 当前体验中哪些地方令人困惑或表述不清？
• 用户在哪里卡住、在哪里流失？
• 我们想让用户抵达的"顿悟时刻"是什么？

2. 理解用户（Understand the users）

• 他们的经验水平如何？（新手、高级用户、还是混合人群？）
• 他们的动机是什么？（兴奋地探索？还是工作需要被迫使用？）
• 他们愿意投入多少时间？（5 分钟还是 30 分钟？）
• 他们知道哪些同类替代品？（从竞品迁移而来？还是第一次接触这个品类？）

3. 定义成功（Define success）

• 用户最少需要学会什么才能成功？
• 我们最想让用户执行的第一个关键动作是什么？（创建第一个项目？发出第一次邀请？）
• 如何判断引导生效了？（完成率？抵达价值的时间？）

原文档用一句 CRITICAL 级警示收束本节：引导应当在尽可能快的时间内让用户获得价值，而不是尽可能多地教授所有功能。这也是后续"教 20% 能带来 80% 价值"原则的逻辑起点。

第二步：五条核心原则（Onboarding Principles）

在评估之后、具体设计之前，先把五条原则内化为决策准则。这些原则互相约束，共同防止引导变成打扰。

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

• 用可运行的示例证明价值，而不是用文字描述价值；
• 在引导中提供真实可用的功能，不要造一个与真实产品脱节的"教学模式"；
• 使用渐进披露（progressive disclosure），一次只教一件事。

Make It Optional（尽可能可选）

• 允许有经验的用户直接跳过引导；
• 不要阻挡用户进入产品；
• 提供"跳过（Skip）"或"我自己探索"选项。

Time to Value（时间到价值）

• 尽快把用户带到"顿悟时刻"；
• 把最重要的概念前置；
• 只教带来 80% 价值的 20% 内容；
• 把高级功能留给"情境化发现"（contextual discovery）——即用户真正用到它们时再出现。

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

• 在用户需要某个功能的那一刻去教它，而不是一上来全部铺开；
• 空状态本身就是引导机会；
• 在用户使用到的位置投放 tooltip 和提示。

Respect User Intelligence（尊重用户智商）

• 不要居高临下、过度解释；
• 保持简洁清晰；
• 相信用户能自己搞懂标准模式。

这五条原则与 impeccable 体系中其他参考文件互为印证。例如 operate.md（面向 Operate 模式的纵深文件）对产品 UI 空状态给出同一条建议："Empty states that teach the interface, not 'nothing here'（空状态应该教用户认识界面，而不是只说'这里什么都没有'）"，clarify.md 也要求空状态区分"首次使用、无结果、有筛选、无权限、失败"等不同成因并给出下一步动作。onboard 的空状态方法论正是这些规则的集中实现。

第三步：按场景设计引导体验（Design Onboarding Experiences）

原文档将引导体验拆成五个典型场景，每个场景都有各自的适用条件与设计清单。

场景 A：初次产品引导（Initial Product Onboarding）

面向第一次进入产品的用户，通常包含四件套：

欢迎屏（Welcome Screen）

• 清晰的价值主张（这个产品是什么？）；
• 用户将学到/完成什么；
• 时间预估（对投入时间坦诚）；
• 可跳过选项（供有经验用户使用）。

账号设置（Account Setup）

• 只收集最少必要信息（更多信息留到以后）；
• 解释为什么索要每一项信息；
• 尽可能给出智能默认值；
• 合适时提供社交登录。

核心概念引入（Core Concept Introduction）

• 只引入 1～3 个核心概念（而不是全部）；
• 用简单的语言和例子；
• 尽量可交互（让用户做，而不只是读）；
• 提供进度指示（如"第 1 步，共 3 步"）。

首次成功（First Success）

• 引导用户完成一件真实的事；
• 提供预填充的示例或模板；
• 庆祝完成（但别用力过猛）；
• 给出清晰的下一步。

场景 B：功能发现与采用（Feature Discovery & Adoption）

新产品引导做完后，老功能的推广和新功能的发现靠以下四类机制：

空状态（Empty States）——这是 onboard 的主战场，原文档专门给了独立小节，见下文第四步。核心做法：不要用空白页面敷衍，而要说明"这里将出现什么 + 为什么有价值 + 明确的创建入口 + 示例或模板"。原文档给了可直接套用的文案模板：

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

情境化 Tooltip（Contextual Tooltips）

• 在相关时刻出现（用户第一次看到该功能时）；
• 直接指向相关 UI 元素；
• 简短说明 + 收益；
• 可关闭（带"不再显示 Don't show again"选项）；
• 可选"了解更多 Learn more"链接。

功能公告（Feature Announcements）

• 新功能发布时高亮它；
• 展示"新在哪里 + 为什么重要"；
• 让用户能立即试用；
• 可关闭。

渐进式引导（Progressive Onboarding）

• 在用户遇到功能时才教授它；
• 用徽标或指示器标记新/未使用功能；
• 逐渐解锁复杂度（不要一开始就把所有选项铺开）。

场景 C：引导式导览与走查（Guided Tours & Walkthroughs）

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

设计要点

• 用聚光灯（spotlight）点亮特定 UI 元素（将页面其余部分变暗）；
• 每段导览步数保持短小（最多 3～7 步）；
• 允许用户自由点击穿梭于导览步骤；
• 提供"跳过导览 Skip tour"选项；
• 可重放（放入帮助菜单）。

最佳实践

• 交互优于被动（让用户点击真实按钮）；
• 聚焦工作流而非功能点（是"创建一个项目"，不是"这是项目按钮"）；
• 提供样例数据，让动作真的能执行。

场景 D：交互式教程（Interactive Tutorials）

适用场景：用户需要动手练习；概念复杂或不熟悉；风险较高（先在安全环境练习更稳妥）。

设计要点

• 提供带样例数据的沙箱环境；
• 给出明确目标（如"创建一张按区域展示销售额的图表"）；
• 逐步指导；
• 校验（确认用户做对了）；
• 毕业时刻（"你准备好了！"）。

场景 E：文档与帮助（Documentation & Help）

产品内帮助

• 在整个界面提供情境化帮助链接；
• 快捷键参考；
• 可搜索的帮助中心；
• 面向复杂流程的视频教程。

帮助模式

• 复杂功能旁放?图标；
• Tooltip 里放 "Learn more" 链接；
• 显示快捷键提示（如在搜索框上展示⌘K）。

第四步：空状态设计方法论（Empty State Design）

空状态是引导密度最高的载体——用户第一次看到某个界面时，看到的大概率就是空状态。原文档要求每一个空状态都必须包含五个要素：

1. 这里将出现什么（What Will Be Here）：如"你的最近项目将出现在这里"；
2. 它为什么重要（Why It Matters）：如"项目帮助你组织工作并与团队协作"；
3. 如何开始（How to Get Started）：如"[创建项目] 或 [从模板导入]"；
4. 视觉趣味（Visual Interest）：配插图或图标，而不是纯文本的空白页；
5. 情境化帮助（Contextual Help）：如"需要帮助开始吗？[观看 2 分钟教程]"。

空状态的五种类型

空状态并非只有一种形态，原文档按成因区分了五类，每类的处理策略不同：

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

这五分类恰好与 impeccable 的 clarify.md 对空状态的要求一一对应，也呼应 critique.md 把"强制不可跳过的教程"列为反面模式的做法（critique 的检查项包括 "Can onboarding be skipped entirely?"、"Forced tutorials or unskippable onboarding"）。如果项目使用了 impeccable 的 DESIGN.md，其设计系统清单中还定义了.ks-empty+.ks-empty-icon这类空状态区块原语，落地时可直接复用 kit 原语，保证空状态与其他状态视觉一致。

实现模式（Implementation Patterns）

设计定案后进入实现层，原文档给出可直接参考的技术选型与存储约定。

技术选型

• Tooltip 库：Tippy.js、Popper.js；
• 导览库：Intro.js、Shepherd.js、React Joyride；
• 模态框模式：焦点陷阱（focus trap）、遮罩层（backdrop）、ESC 关闭；
• 进度追踪：用 LocalStorage 记录"已见"状态；
• 分析：追踪完成率与流失点（drop-off points）。

存储模式——记住用户已看过的引导，避免重复打扰：

// 记录用户已完成的引导步骤 localStorage.setItem('onboarding-completed', 'true'); localStorage.setItem('feature-tooltip-seen-reports', 'true');

原文档用 IMPORTANT 级警示强调：不要向同一个用户展示相同的引导两次（这很烦人），要记录完成状态并尊重用户的选择（关闭/跳过）。

NEVER 清单——以下行为是硬性红线，任何一条都意味着引导设计失败：

• 强迫用户先走完冗长引导才能使用产品；
• 用显而易见的解释侮辱用户智商；
• 反复展示同一个 tooltip（不尊重关闭选择）；
• 导览期间封锁全部 UI（应允许用户自由探索）；
• 造一个与真实产品脱节的独立"教学模式"；
• 一上来就灌输过量信息（要用渐进披露！）；
• 隐藏"跳过"或让跳过很难找到；
• 忘记回归用户（不要对老用户再次展示初次引导）。

验证引导质量（Verify Onboarding Quality）

引导是否真正有效，最终要靠真实用户的测量，而不是设计师的自我感觉。原文档给出六个可量化维度：

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

在 impeccable 的命令流里，这一步还有明确的"交接协议"：原文档规定，当用户快速抵达顿悟时刻且没有流失时，把工作移交给/impeccable polish做最后的收尾打磨。这与 impeccable 的整体工作方式一致——SKILL.md 要求"在有界轮次中验证而非死循环"，polish.md 则负责对完整路径做状态、层级、交互与视觉的一致性收尾（例如它要求覆盖 loading、empty、error、success、disabled 等全部状态），确保 onboard 设计的引导路径在真实界面里不是"孤立的几屏"，而是首达、过渡、空态与恢复路径彼此连通。

在 impeccable 工作流中执行 onboard

将本文的方法放回 impeccable 的执行上下文：当用户提出"新用户引导""空状态不好看""用户不知道怎么上手"等诉求时，技能会加载 onboard 参考文档 作为执行手册（其余 skill 副本见 plugin 镜像 与 skill 镜像），随后按下列顺序落地：

1. 向用户确认"顿悟时刻"与经验水平这两个必要输入（文档头部标注的 Additional context）；
2. 完成上文的"评估需求 → 应用五原则 → 按场景设计 → 打磨空状态 → 落实实现模式"全流程；
3. 用六项指标验证引导质量；
4. 达标后交接给polish做跨路径收尾。

整套方法不依赖任何特定框架或技术栈——Tooltip、导览、空状态与进度记录都是跨 React、Vue、Svelte 或原生界面通用的模式，你只需按上文实现模式中的选型与 LocalStorage 约定落地即可。它的价值核心始终是那句总纲：把用户尽快带到能证明产品值得他们时间的那个瞬间。

【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable