你的界面让人疲惫

一句话总结：认知负荷的累积速度，比团队预想的更快。每一个多余的标签、决定和不必要的步骤，都在占用工作记忆。到某个时刻，用户会因为觉得太费力而停止使用你的产品。

明明没有什么明显坏掉的地方，人们还是放弃了。认知负荷在产品里就是这个样子。一个标签要读第二遍。一个多余的步骤。一个控件让用户不得不猜一下。单独看，哪个都不像致命问题，合在一起却让人精疲力竭。等他们走到真正重要的部分时，已经累了。

任务本身已经占用了部分额度

多年来，设计师反复提起数字七。George Miller给了他们这个说法的由头，而设计界把它变成了规则。后来，Nelson Cowan重新审视这个问题，认为同时能记在脑中的真实数量更接近四个组块。这很重要，因为许多界面在任务还没开始前，就已经把这些位置占掉了。

John Sweller作出了这里最重要的区分。有些努力属于任务本身。有些努力帮助用户学习。还有一些是界面无缘无故加上去的额外负担：含糊的措辞、糟糕的层级，或一个因为没人愿意删除而留下来的步骤。这就是额外征收的税。

Steve Krug把实际问题说得很好：“每一个问号都会增加我们的认知负担，让注意力偏离手头的任务”（译自英语）。这里的重点就在于此。问题不只是选项太多。那些小小的不确定，会积累成一股持续的阻力。

Fred Paas、Alexander Renkl 和 John Sweller把同一个想法推进了一步：并非所有负荷都一样。有些有助于学习，有些只是消耗容量。设计师说任务本来就应该很难时，忽略的就是这个区别。困难应该来自任务，而不是你的措辞、结构，或懒得多想的默认设置。

TurboTax 减掉了额外的工作

TurboTax是个有用的例子，因为要完成的任务本身就很让人头疼。报税很难。设计不能让税法变简单。但 TurboTax 减少了任务周围的额外工作。一个界面只问一个问题。能去掉术语的地方就用平实的英语。整个流程有一条清晰的路径。

这个例子的价值就在这里。它没有消除问题本身的难度。它消除的是包在问题外面的界面所带来的难度。竞争产品常常要求人们同时记住更多东西，在不同部分之间来回跳转，或解读那些本来根本不该需要他们解读的术语。

有一点要分清。Intuit 在其他方面的行为，并不意味着这个设计观点不成立。这里的教训范围更窄：如果任务本来已经很重，界面就没有资格再加码。

好的精简就是这样。它不是假装任务简单，而是拒绝在任务周围添加额外压力：一个简洁的问题，一个明确的下一步，让人们在做本来就害怕做的事时，少记住一件东西。

这个区别很重要，因为设计师常常拿领域的复杂性，为负担沉重的界面辩护。医疗很复杂。金融很复杂。企业对企业（B2B）的运营很复杂。但这不能成为借口，让用户去解读你的内部用语、记住隐藏的依赖关系，或猜测点击之后会发生什么。

问题不只是选择

即使一个界面只有三个按钮，只要措辞含糊、层级混乱、操作路径要求用户同时记住太多东西，它仍然可以让人精疲力竭。所以设计师容易漏掉这个问题。他们在寻找显著的失败。而他们做出来的东西，往往只是让人很累。

我见过产品流失用户，不是因为决定很难，而是因为界面一直要求用户再多做一点小小的解读。

做一次负荷审查

打开人们最常用的界面，数一数他们在采取行动前得记住多少东西。不只是选项。还有要理解的意思、术语、步骤、依赖关系，以及那些用户得停下来琢磨你到底什么意思的小瞬间。然后问一个问题：这些努力是在帮助他们完成任务，还是仅仅因为界面为了方便你而让他们费力？

如果是后者，就删掉。

如果不能删，就往后放。很多让人疲惫的界面，并不是因为始终包含太多东西而超载，而是因为太早呈现了太多东西。先放最必要的内容，额外细节等到用户确实需要时再出现。一个已经累了的用户，不该为了做一件有用的事，先完成所有筛选整理。

渐进式披露在这里才真正发挥价值。它不是模式库里的一个术语，而是一种方法，让你别在主要任务还没清楚之前，就把用户的注意力花光。问题很简单：这个人现在要采取行动，需要什么？什么可以等三十秒？

如果一开始就用光了所有注意力，后面的流程就只能靠那点残余来运转。

用户并不总是因为被卡住才退出。很多人退出，是因为你让整个过程太累人，用户实在不想再继续。