interactive-product-tour

交互式产品导览

资深产品营销总监关于设计产品内导览、工具提示和上下文帮助的实战指南：如何讲解产品功能，同时避免造成阻碍。涵盖触发逻辑、导览架构、上下文放置和完成情况跟踪。打造帮助系统的要诀，是让帮助在用户需要时出现，不需要时消失。

大多数产品导览都以两种方式之一失败。它们给每个按钮、链接和功能都标上“点击查看导览”的提示，直到视觉噪声大到用户对这些圆点视而不见。或者，它们只在用户首次登录时展示一次导览，而用户要么跳过，要么匆匆浏览；之后，即便用户真正遇到阻碍，这些帮助也不会再出现。用户需要帮助时看不到的帮助，就等于不存在。

有效的导览会采用不同做法。它们只在用户遇到阻碍时触发，而不是一直出现。当用户进入尚未探索过的版块、点击需要设置的功能，或长期未使用后再次回来时，系统会显示上下文提示。系统了解用户掌握了什么，并在恰当的时机提供帮助。

本指南采用资深产品营销总监的视角：她曾看到，重新设计导览后，功能采用率翻倍；也曾看到，每个界面都堆上更多工具提示后，采用率骤降。她注重实效，明确主张触发逻辑应区分有用的帮助与视觉噪声；当完全不需要产品内导览时，也会直言不讳。

适用场景：首次规划产品内帮助系统；审查一个有互动指标却没有带来采用率提升的导览系统；设计决定何时显示帮助的触发逻辑；或决定哪些功能值得制作导览，哪些只需文档说明。

---

本技能涵盖的内容

本技能涵盖产品内导览、工具提示和上下文帮助。与增长工具相关的区别如下：

• onboarding-wizard-design 是按顺序引导用户的首次使用体验。本技能涵盖产品内部的上下文帮助，会贯穿整个用户生命周期提供帮助。
• chatbot-flow-design 是对话式帮助。本技能涵盖非对话式的导览和工具提示帮助。
• **interactive-product-tour（本技能）**涵盖触发逻辑、导览架构、上下文放置、完成情况跟踪，以及在用户需要帮助前不打扰他们的原则。
• discovery-research-synthesis 是为导览内容提供依据的研究。它是输入，不属于本技能。
• pm-spec-writing 是面向开发导览的工程师编写的规格说明。本技能关注要构建什么；pm-spec-writing 关注如何将其清楚传达。

适用对象：产品营销人员、增长营销人员、公司内部产品团队，以及为 SaaS 客户开展激活工作的代理机构。

不在本技能范围内：首次使用向导（由 onboarding-wizard-design 涵盖）；对话式帮助（由 chatbot-flow-design 涵盖）；工程实现；以及 Userpilot/Pendo/Appcues 平台的具体配置（这些属于实施工作）。

导览决策：何时值得投入导览，何时文档就足够了

设计导览系统之前，先判断导览是否是合适的工具。

以下情况值得投入导览：

• 产品包含用户若无提示便很容易错过的功能。例如，隐藏在菜单深处的特定功能、需要按顺序操作的高级工作流，以及用户不知道其存在的集成。
• 与脱离上下文的文档相比，受众更能从情境化引导中受益。导览会在用户实际使用功能的地方进行讲解；阅读文档则需要切换上下文。
• 团队能够随着产品演进维护导览内容。导览内容会过时；如果没有维护承诺，导览就会指向已弃用的 UI。
• 已定义成功指标。例如，功能采用率、特定功能的价值实现时间，或导览所涵盖功能的支持工单数量下降。

以下情况不值得投入导览：

• 产品功能集足够小，文档就足以满足需求。关键功能上的几个工具提示可能就够了。
• 受众更喜欢自主探索。有些受众反感产品内引导，更愿意自行探索。
• 团队无法在产品变更的同时维护导览。过时的导览比没有导览更糟。
• 产品变更频繁。如果产品快速迭代，维护导览的成本可能超过其价值。

要决定的不是“我们是否应该有导览系统”，而是“产品内导览是否适合这个产品和受众”。

详见 references/tour-decision-criteria.md。

---

工具提示泛滥、一次性导览，还是按需提供情境化引导

这是核心框架。

工具提示泛滥。 每个按钮、链接和功能旁边都有“点击查看导览”的提示或闪烁圆点。视觉噪声会让用户对这些圆点视而不见；导览系统也就无法发挥教学作用。代价：设计投入产出的帮助无人察觉，视觉杂乱还会拉低整体产品体验。

一次性导览。 用户首次登录时只显示一次导览。用户会跳过或快速浏览。等用户真正遇到阻碍时，同一导览却不会再次出现。代价：在需要时看不到的帮助，就起不到帮助作用。功能采用率持续偏低；导览涵盖的功能仍会引发支持工单。

按需提供情境化引导。 当用户遇到阻碍时触发导览和工具提示（进入尚未探索过的板块、点击需要设置的功能、长时间离开后重新回来，或首次启用某项功能开关）。系统了解用户已掌握的内容，并在合适的时机提供帮助。代价：触发逻辑需要投入大量工作；回报则是帮助能随着时间推移不断提升功能采用率。

检验标准：观察用户第一次遇到某项功能时的情况。帮助系统是在那一刻提供了有用的引导，还是在用户早已忘记的首次登录时就提供了引导？如果是前者，就是按需提供情境化引导；如果是后者，就是一次性导览。如果帮助内容还要与散布在页面各处的 14 个工具提示圆点争夺注意力，那就是工具提示泛滥。

---

触发逻辑：基于事件、时间还是状态

决定何时显示帮助的机制。

基于事件的触发。 用户执行操作时显示帮助。例如，首次点击某项功能、进入新区域或完成某个流程。

何时使用。大多数情境式帮助的默认选择。用户执行了操作；帮助随之响应。

基于时间的触发。 经过一段时间后显示帮助。例如，用户离开 30 天后重返产品；在此页面停留 60 秒却没有任何操作。

何时使用。时间可以表明用户可能需要帮助（离开较久；在某个页面停滞）。谨慎使用；仅凭时间是个噪声很大的信号。

基于状态的触发。 根据用户状态显示帮助。例如，新用户与高级用户；账户规模；功能使用历史。

何时使用。当不同用户群体需要不同帮助时。基于状态的触发可以个性化帮助。

组合触发。 大多数生产级引导系统会结合这三种方式。以事件驱动，同时用时间和状态调节频率和内容。

要点。触发条件回答的是“何时以及为何显示这条帮助”。装饰性的触发（在不需要时显示帮助）会变成提示框泛滥。

详情见 references/trigger-logic-patterns.md。

---

引导架构：单一引导、分支引导还是微型引导库

帮助的组织方式。

单一引导。 一个线性引导涵盖整个产品。简单但僵化；很少符合用户实际探索产品的方式。

分支引导。 引导根据用户的选择或在产品中的路径进行调整。更贴合需求；也更复杂。

微型引导库。 数十个小型、聚焦的引导，各自关联特定功能或工作流，并在相应情境下触发。灵活性最高；维护成本也最高。

如何选择。 大多数现代系统采用微型引导库的方式。单一引导显得生硬；分支引导难以大规模维护；情境式微型引导库则符合用户实际探索产品的方式。

详情见 references/tour-architecture-patterns.md。

---

情境式放置：帮助出现的位置及其关闭方式

帮助的视觉设计。

放置模式。

• 悬停时显示提示框。 将鼠标悬停在元素上时，帮助显示在元素旁边。轻量；用户熟悉。
• 聚光灯式遮罩。 突出显示元素，并在旁边显示帮助。更加醒目；干扰性也更强。
• 侧边栏。 在侧边面板中显示帮助。用户工作时，帮助可以持续显示。
• 内嵌。 在页面内容流中显示帮助。干扰性低；但更难关闭。

关闭机制。

• 点击 X。 标准关闭方式。始终可用。
• 点击外部区域。 用户与其他内容互动时，帮助随即关闭。这意味着帮助不是模态的。
• 自动关闭。 几秒后帮助逐渐淡出。有风险；用户可能还没读完。
• 执行操作前持续显示。 帮助会一直显示，直到用户执行建议的操作。适用于引导式流程；其他情况下则显得烦扰。

不打扰原则。 用户需要时应能找到帮助，不需要时也能忽略。阻挡屏幕的模态帮助会造成干扰；太容易消失的帮助则无法有效传授信息。

详情见 references/contextual-placement-patterns.md 和 references/dismissal-and-non-intrusion-patterns.md。

---

完成状态跟踪与重新触发逻辑

了解每位用户看过哪些内容，并决定何时再次展示。

跟踪每位用户的状态。

• 用户完成了哪些引导？
• 用户关闭了哪些引导？
• 用户看过但未完成哪些引导？
• 距离上次交互的时间。

重新触发逻辑。

• 已完成的引导：通常不再展示。
• 已关闭的引导：尊重用户的选择；如果相关功能再次变得重要，可在较长时间后重新展示。
• 跳过的引导：在相关时机重新展示。
• 长时间未活跃的用户：通过简短版帮助重新引导。

过度触发的陷阱。 向已经完成引导的用户反复展示相同引导。用户会失去信任，并关闭引导。

触发不足的陷阱。 用户再次遇到相同阻碍时，引导却从未重新出现。用户在需要帮助时得不到支持。

详见 references/completion-tracking-and-re-trigger.md。

---

区分高级用户与新用户

不同用户需要不同的帮助。

原则。 高级用户不希望看到他们已经使用过的功能的引导。新用户则需要看到他们初次接触的功能的引导。帮助系统应该能够区分两者。

区分信号。

• 功能使用历史（用户以前用过此功能吗？）。
• 使用时长（用户使用产品多久了？）。
• 参与频率（每天活跃，还是每月回来一次？）。
• 用户自述的技能水平（较少见，通常通过推断得出）。

区分模式。

• 高级用户只会看到关于新功能的帮助。
• 新用户会看到与其探索阶段相匹配的功能帮助。
• 如果上次会话已过去很久，回访用户会看到重新引导帮助。

过度帮助的陷阱。 帮助高级用户使用他们已经熟练掌握的功能。用户会失去信任。

帮助不足的陷阱。 将所有用户都视为高级用户。新用户会错过关键帮助。

详见 references/power-user-vs-new-user-patterns.md。

---

常见故障模式

快速诊断见 references/common-tour-failures.md。

• “引导会显示，但功能采用率没有提升。”帮助可能在视觉上可见，但与上下文无关。检查触发逻辑。
• “用户全局关闭了引导。”系统让用户感到厌烦。检查展示频率、关闭处理和过度触发问题。
• “首次登录引导完成率为 80%，但功能采用率没有变化。”这是一次性展示模式；用户在需要时无法记住引导内容。
• “到处都有工具提示；没人点击。”工具提示泛滥；应重新调整为由具体情境触发。
• “引导内容提到了 6 个月前已弃用的功能。”维护不到位。
• “高级用户抱怨弹窗总是介绍他们已经了解的内容。”没有区分高级用户。
• “引导在桌面端运行正常，在移动端却出问题。”未测试帮助系统的移动端用户体验。
• “有些团队会发布引导，另一些团队却不愿意做，情况不一致。”缺少引导治理机制；有些团队会构建引导，另一些则置之不理。
• “引导正确触发了，但用户没有按照建议采取行动。”帮助内容不清楚，或缺少行动号召。

框架：产品导览设计的 12 项考量

设计或审查产品内导览系统时，请逐一检查以下 12 项考量。

1. 是否需要导览。 导览是合适的工具，还是文档就足够？
2. 按需提供上下文，而非用工具提示狂轰滥炸或只提供一次。 在用户遇到阻碍时提供帮助。
3. 触发逻辑合理。 以事件触发为主，并根据时间和状态进行调整。
4. 导览架构符合使用方式。 对大多数产品而言，微型导览库更合适。
5. 上下文式放置，不造成干扰。 用户需要时能找到帮助，不需要时可以忽略。
6. 关闭机制诚实。 提供标准关闭方式和点击外部关闭，不要在用户读完前自动关闭。
7. 完成情况有埋点记录。 按用户记录状态，按导览记录进度。
8. 重新触发逻辑尊重用户。 已完成的导览不再显示；尊重用户关闭的导览。
9. 区分高级用户与新用户。 根据用户状态调整帮助内容。
10. 移动端体验一致。 帮助功能适用于受众使用的设备。
11. 遵循维护规范。 随产品变更更新导览；每季度审查一次。
12. 以采用情况衡量成功。 不只看导览完成情况；真正重要的指标是功能采用情况。

该框架旨在构建一个赢得用户关注的导览系统：在需要之前不出现，在相关时刻提供帮助，并推动功能采用。

---

参考文件

• references/tour-decision-criteria.md - 说明何时值得构建导览，何时文档就足够。
• references/trigger-logic-patterns.md - 事件触发、时间触发、状态触发及组合触发。区分有效触发与噪声的规范。
• references/tour-architecture-patterns.md - 单个导览、分支导览与微型导览库。选择符合用户实际探索方式的架构。
• references/contextual-placement-patterns.md - 工具提示、聚焦高亮、侧边栏、内嵌提示。放置方式与视觉设计。
• references/completion-tracking-and-re-trigger.md - 按用户记录状态、重新触发逻辑，以及触发过度和触发不足的陷阱。
• references/power-user-vs-new-user-patterns.md - 区分信号与模式，以及帮助过度和帮助不足的陷阱。
• references/dismissal-and-non-intrusion-patterns.md - 关闭机制与不干扰原则。
• references/tour-anti-patterns.md - 看似导览、实则损害产品的模式。
• references/common-tour-failures.md - 9 种以上常见失败模式及其诊断与解决方法。

---

结语：引导之所以赢得用户的关注，是因为只在需要时才出现

真正能持续创造价值的引导系统，是用户不会察觉它是引导系统的那种。帮助会在用户遇到阻碍时出现，阻碍消失后随即隐去，绝不会堆积成视觉噪音。用户第一次接触某个功能时，会看到一条简短的上下文提示，执行建议的操作，然后继续前进。系统完成了它的工作；用户无需思考这个系统。

这就是标准。低于标准的，是工具提示轰炸（用户会对这种视觉噪音逐渐麻木），以及一次性引导（用户需要帮助时，帮助却不见踪影）。高于标准的，是按需提供上下文的系统：触发逻辑、引导架构、上下文定位和重新触发机制相互配合，让帮助显得自然而非强加于人。

关键在于设计决策：究竟要不要构建引导系统，还是依赖文档；决定何时显示帮助的触发逻辑；按功能和工作流组织微型引导的架构；让帮助不打扰用户的定位和关闭方式；防止重复展示用户已掌握内容的完成状态跟踪；尊重专业用户的差异化设计；以及确保引导与产品保持同步的维护节奏。