章节 28

选项越多，用户越容易放弃

为什么增加功能会让产品更难用

你给了用户更多，却让产品变得更差。这就是功能陷阱。

团队不断增加能力，因为更多选项看起来就像更多价值。然后用户打开产品，不得不一路选择、扫视、比较，反复怀疑自己的决定，而这个产品本来应该替他们省时间。

人们买下了过多的复杂性

Debora Viana Thompson、Rebecca Hamilton 和 Roland Rust在 2005 年给这个模式起了名字：功能疲劳。拥有产品之前，额外功能让它显得能力强大。拥有之后，同样的功能却变成了必须逐一选择、设法处理的东西。

Barry Schwartz从另一个角度探讨了同一个问题。更多选择往往带来更多后悔和回避，而不是更多满足。更早之前，William Hick就用更简单的方式衡量了这种成本：选项越多，决定越慢。

这里的问题，不是一般意义上的费力。而是当用户面对过多路径、功能、设置或操作时，选择本身成了负担。

这份负担会出现两次。第一次在购买决策里，功能更全的产品看起来更稳妥，因为似乎能覆盖更多情况。第二次在使用中，同样的丰富却变成了菜单负担、设置负担和疑虑。帮产品在对比中获胜的东西，等用户真正进来后，可能让实际工作变慢。

2019 年，Pendo分析了 615 款软件产品，发现 80% 的功能很少被用到，或者从未被用到。这个数字很重要，因为没用上的功能不只是待在代码库里。它们会出现在菜单、设置、新手引导、导航和对比页面中。

每多一个这样的功能，用户就得多扫一眼，或者多作一个决定。团队就在这里骗了自己。他们以为只要核心任务还能完成，没人用的功能就无伤大雅。它们并非无害。它们不断要求用户从噪声中筛选信号。我见过这样的设置页：人们只想改一件事，迎面却撞上十五件。

而且，还没有人使用这些功能，它们就已经改变了产品给人的感觉。拥挤的工具栏在说：这会很费力。塞满的设置页在说：你得先理解整个系统，才能信任它。即使用户忽略了一半控件，他们仍得穿过这一片杂乱来理解产品。

Jira最初是缺陷追踪工具。然后它不断长大。自定义字段。权限层级。问题类型。自动化规则。更多工作流状态。更多模块。更多插件。规模上来以后，很多团队最终需要管理员，才能让它维持在还能理解的状态。

我仍然记得我们在 Degreed 换用 Jira 时的情景。让我难受的不是某一个糟糕功能，而是堆积：导航、选项、操作、设置，到处都是选择。我还没做自己来这里要做的事，就已经觉得沉重。我和团队开始能不用就不用。

复杂不总是坏事。问题在于，主要任务早已明确，产品却仍然不断把决定丢给用户。Linear的一部分吸引力，来自往相反方向走：更少需要用户自行配置的选项、更多默认设置、更少要求。

Jira 是个好例子，因为痛苦不只在于费力。而在于它一直让用户决定一些他们根本不是为此而来的事。

这不意味着每个专业工具都应该像消费产品那样简单。有些产品确实需要深度。问题始于产品默认把专家级的选择交给所有人，包括那些只想做一件普通的事、然后离开的人。

这个区别很重要。深度不是敌人。过早出现的深度才是。如果工具随着用户一起成长，额外功能就会等到用户有了相应的使用经验和需求时再出现。如果工具第一天就把整棵决策树倒出来，那就是让用户为自己暂时不需要的能力付出代价。

这也是默认设置在这里如此重要的原因之一。好的默认设置，让产品替用户作出简单的决定。坏的默认设置把全部负担丢回用户手里，还把它叫作灵活性。

做一次选项审查。数一数一个界面实际要求多少决定：导航项、次要操作、筛选器、标签页、模式、嵌套设置，以及那些可以配置却很少需要配置的东西。然后问：对大多数用户来说，在大多数时候，每一项是否都有助于主要任务？

如果没有，就删掉。如果不能删，因为高级用户确实需要，就先把它移出主要路径，直到用户真的需要它。

渐进式披露在这里才真正发挥价值。一个显而易见的默认选项。更少的起始选项。等用户要求，或熟悉到需要时，再给额外控制。这不是把产品做傻了。而是把复杂性往后放，等它对应到真实需求，而不是一开始就倒给所有人。

用一个这样打造的产品，你很快就能感到区别。主要路径往前走。高级路径在旁边等。通常，这才是正确的顺序。先少要求一点。等用户有理由在意时，再多要求。

你每增加一个选项，就多了一个用户可能慢下来、犹豫或退出的时刻。