← #793

为什么大多数产品引导都被用户跳过了

查看原文 HN 讨论

文章摘要

productonboarding.com 这篇文章——作者是 Frigade 联合创始人 Eric Brownrout——把一个 SaaS 圈里大家都心知肚明的事实摊开来讲：绝大多数用户在产品引导（product tour）的第一步就关掉了它。这种”漂浮气泡 + 高亮箭头 + 一步步告诉你怎么用”的引导模式，在产品经理眼里看起来贴心，在用户眼里几乎全是噪音。

文章把”为什么被跳过”归结为几个关键原因：

1. 时机错了。 用户打开一个工具是因为他当下要完成一件事，不是来听课。20 秒后要进 Zoom 会议、马上要交报销单、要赶紧看一份 PDF 的人，对任何阻碍他完成任务的弹窗都会本能反感——产品引导恰恰是在他最不耐烦的瞬间挡在路上。

2. 引导是”产品差”的遮羞布。 一个广为流传的批评是 “如果你的产品需要 tour，说明你的产品设计很糟糕”——好的 UI 应该自解释。Tour 在很多情况下是用临时性教学掩盖根本性的可用性缺陷，治标不治本。

3. 视角错位——是厂商想让你知道，不是你想知道。 产品引导往往强调的是公司想推的功能（通常是新做的、KPI 挂钩的），而不是用户真正需要先掌握的最小功能集。这制造了一种”对抗感”：用户感觉被推销，而不是被服务。

4. 信息过载，毫无上下文。 一次性灌输 5-10 个功能点，但用户没有真实场景去理解”为什么我现在需要知道这个”——缺乏 context 的指令会被立即遗忘。

文章给出的替代方案是几种“以用户节奏为准”的非侵入式引导：

• 嵌入式帮助按钮——在用户真的卡住时才出现，且永远是可选的；
• 渐进式披露（progressive disclosure）——只在用户用到时才展示对应功能；
• 可搜索的命令面板（command palette）——给”知道自己想做什么”的用户一条快速通路；
• 可选文档——用户主动找帮助时再读，而不是被强行投喂。

核心理念可以一句话概括：尊重用户的自主性，把功能本身做到不需要解释——这比花精力做更花哨的 tour 高级得多。

HN 评论精华

1. 关于”工具的本质”：评论区共识——用户打开一个工具是因为他要立刻干活，不是来上培训课。任何在”动手”和”完成”之间插入步骤的引导，都会被本能跳过。这是用户行为的物理常数，不是 UX 趋势问题。

2. “产品需要 tour 说明产品有问题”：这是 HN 设计圈的经典立场——好的产品应该自解释，UI、按钮文案、空状态提示就是教程。需要弹窗 tour 才能用的产品，本质上是设计失败。

3. 关于厂商视角 vs 用户视角：很多评论指出 tour 是给产品经理看的，不是给用户看的——它解决的是 PM 内部的焦虑（”新功能怎么让用户发现”），而不是用户的问题。用户驱动 vs 厂商驱动的鸿沟在 onboarding 上最明显。

4. 关于信息过载：有评论提到一个心理学事实——没有 context 的信息保留率几乎为零。用户在还没做过一件事之前，被告知”这里点了可以做 X”，第二天就完全忘了。学习必须发生在”我需要这个”的那一刻，不能提前。

5. 替代方案中的呼声：Command palette（Cmd+K）是评论区最被推崇的 onboarding 模式——既不打扰新手，又给老手一个发现功能的快速通路。Linear、Notion、Raycast 等产品的成功部分得益于这个模式。

6. 关于”渐进式披露”：Slack、Figma、Stripe 被反复提到为正面案例——它们在用户做特定动作时才触发情境化提示，而不是一进来就开 tour。”等到用户真的需要时再说话”是高质量 onboarding 的共同原则。

7. 关于行业病灶：还有评论尖锐指出——产品里塞 tour、popup、onboarding modal 这些”病态友好性”，本质是因为很多 SaaS 公司用激活率（activation rate）作为 OKR，PM 必须做点什么”看起来在帮用户激活”，于是 tour 就成了仪式化的 KPI 道具——没人真在乎用户是否真的学会，只在乎”完成 tour”这个数字漂亮。