The Essence of Software.Chapter.05.概念目的

目的在生活的方方面面都很重要，因为它们帮助我们设定方向，向他人解释自己，并在合作中达成共识。设计在这方面与其他任何活动都没有什么不同：如果你不知道为什么首先需要它，你就无法很好地设计任何东西。

对于概念来说，目的同样是必不可少的。对于设计师而言，目的是证明设计和实现该概念所付出努力的合理性。对于用户而言，它告诉了你为什么可能需要它——如果你不知道某个东西是用来做什么的，就很难理解你将如何使用它。

在你认为这是显而易见的事情而不予理会之前，请考虑一下：软件设计师很少去阐明除整个产品的目的之外的其他目的。我在这里提出了一个更激进的想法：仅仅知道你为什么要设计一个产品是不够的。你需要为你设计中的每一个元素提供一个理由（why），为每一个概念提供一个目的。

为概念寻找目的是一项艰苦的工作，但它所带来的回报是丰厚的：它让你对自己试图解决的问题有更深刻的见解，并迫使你专注于重要的事情。在这一章中，我们将看到找出概念的目的可以有多么微妙，以及未能制定或传达一个明确的目的是如何产生糟糕的后果的。尤其是在软件领域，凭借其产生无限复杂性的能力，人们很容易陷入细节中而迷失大局。思考目的有助于你抽身而退，重新找回方向感。

一旦你有了目的，你就可以问你的概念是否实现了它。正如我们将看到的，这并不总是直截了当的，因为目的不仅仅是对预期行为的简单描述。它是对一种需求的阐述，而这种需求可能会因用户和使用环境的不同而发生变化。不匹配（Misfits），即形式（forms）未能适应其环境（context）——或者在我们的例子中，概念未能实现其目的——通常是不可预测的，因为无论是在设计时还是在设计后，需求和使用环境都无法被完全预测，更不用说被简化为精确的逻辑陈述了。

概念并不能消除这个问题；它们的价值在于通过提升目的的作用，并通过提供一种结构来组织通过设计和使用经验积累的知识，为你提供了一个减轻这个问题的框架。在这一章中，我将展示从目的角度思考的一些好处；稍后，在第9章中，我将重新审视目的和概念之间的关系，并完善其中一些想法。

目的：清晰的第一步

为了易于使用，一个概念必须有一个清晰的目的。而且这个目的不能是设计师的秘密；它必须与用户共享。

当我升级到最新版本的 Apple Mail 时，我注意到了一个新的 VIP 按钮，并查找了它。以下是苹果的帮助指南所说的：

通过将重要的人设为 VIP，你可以轻松追踪来自他们的电子邮件。来自 VIP 的收件箱中的任何消息（即使是作为对话的一部分发送的）都会显示在 VIP 邮箱中……

仅仅两句话，他们就向我解释了 vip 概念的目的（追踪来自对我很重要的人的电子邮件），以及该概念的大部分操作原理（似乎我可以将某人设为 VIP，然后，随后，来自他们的消息将出现在一个特殊的邮箱中）。

相比之下，我想了解 Google Docs 中的节（section）是什么，所以我在在线帮助中查找了“section”这个词。第一件令人不安的事情是，没有出现关于 section 概念的文章。最接近的是一篇题为“使用链接、书签、分节符或分页符”的文章。我浏览了那篇文章，发现了这个：

如果你想在文档中打断想法或将图像与文本分开，你可以在 Google Docs 中添加分节符或分页符。

就解释目的而言，仅此而已。我可能会猜到节可以用来打断想法，所以这对我也没帮助。提到图像让我有点紧张，因为它似乎在暗示，如果不使用节，我就不能让图像与文本“分开”。简而言之，这让我对节是用来做什么的依然一无所知。

事实证明，section 的目的是允许你的文档的不同部分具有不同的页边距、页眉和页脚，并拥有具有自己页码的页面子序列。你可以在不使用任何节的情况下将图像与文本分开；节让你能够做的是，独立于图像周围文本的页边距来更改图像的页边距。

目的的标准

为概念定义令人信服的目的是很困难的。因为目的是关于人类环境中的人类需求，它们不能以逻辑或数学的方式进行评估，而必须始终是非正式且粗略的。尽管如此，这里有一些可以提供帮助的标准：

有说服力的（Cogent）。 目的必须是对可理解需求的有说服力的表达，而不仅仅是对用户可能拥有的某些愿望或她可能想要执行的任务的模糊暗示。Google Docs 中解释 section 概念目的时使用的短语——“打断想法”和“将图像与文本分开”——只给了我们一个用户试图做什么的模糊概念。相比之下，“允许不同页面有不同的页边距”就非常清晰。

以需求为中心（Need-focused）。 目的必须表达用户的需求，而不仅仅是重申一个重要性不明确的行为。以浏览器提供的 bookmark（书签） 概念为例。说书签的目的是“标记一个页面”或“保存一个最喜欢的页面”是没有帮助的：这些只是在回避你为什么想要做这些事情的问题。相反，目的可能是“为了方便以后重新访问页面”，或者可能是“与另一个用户分享页面”。如果最初一个目的不够精确，不要担心；如果你的表述立即引发了疑问（“以后重新访问”可以是在不同的设备上吗？），这是取得进展的好兆头！

具体的（Specific）。 目的必须足够具体，以至于与手头概念的设计相关。你可以说任何概念的目的都是“让用户开心”或“让用户更有效地工作”，这些表达确实是有说服力的（因为我们完全知道它们是什么意思）并且是以需求为中心的。但显然，这些目的不会成为概念设计的有用基础，因为它们不够具体，无法区分一个概念和另一个概念。

可评估的（Evaluable）。 目的应该提供一个衡量概念的标尺。你应该能够采用操作原理并轻松评估它是否实现了目的。对于 trash（废纸篓） 概念，“允许撤销删除”的目的显然是由文件被删除然后从废纸篓中恢复的场景所支持的。相比之下，“防止意外删除文件”的目的就不会很有帮助，因为我们需要关于用户行为的额外信息，特别是用户是否不仅可能意外删除文件，还可能意外清空废纸篓。

目的解决设计难题

有时，你正在进行的设计会提供多个看似同样合理的选项，而且似乎没有合理的依据来选择其中一个。在许多情况下，这种困境是因为没有深入理解目的而导致的。一旦理解了目的，哪个选项是正确的就变得清晰了。

以 call forwarding（呼叫转移） 为例，这是一种电话概念，它允许将呼叫一条线路的电话自动转移到另一条线路。假设我们有三个拥有电话线路 A、B 和 C 的用户（图 5.1）。现在想象一下我们的第一个用户将她的线路转移到 B，这样呼叫 A 的电话现在就被重定向到 B。如果第二个用户现在转移到 C，这样呼叫 B 的电话就去了 C，会怎么样？如果有一个电话打给 A，它是应该转移到 B（基于第一个用户的转移请求），还是应该转移到 C（基于两个用户的请求）？

解决这个困境的方法是认识到呼叫转移有两个不同的目的。第一个，可能被称为委派（delegate），是允许一个人将他们的电话委派给其他人。在这种情况下，如果 A 的所有者委派给了 B，而 B 委派给了 C，那么显然打给 A 的电话应该通过两步转移到 C。另一个，跟随我（follow me），是允许一个人在不同地点工作时转移电话。在这种情况下，如果 A 的所有者已经移动到了 B 的位置，而 B 的所有者现在在 C 的位置，打给 A 的电话显然应该只转移到 B。

阐明这两个不同的目的揭示了这里有两个不同的概念：delegate forwarding（委派转移） 和 follow-me forwarding（跟随转移），每个概念都有自己的目的。它们的行为在其他方面也可能有所不同。例如，delegate forwarding 概念可能支持一种选项：电话首先在 A 响起，只有在无人接听时才转移到 B。

没有目的的概念：水龙头与编辑器缓冲区

一个概念可能完全没有令人信服的目的。这让人对其效用产生了一些怀疑，但人们即使在令人怀疑的概念中也能发现价值。poke（戳一戳） 概念是 Facebook 最早的概念之一，但从来没有人真正知道它是用来做什么的。

概念之所以没有目的，通常不是因为真正的用户需求，而是因为以那种方式构建它更容易。一个物理类比说明了这一点。比较两种常见的混合水龙头（图 5.2）。在这两种水龙头中，都有一根单一的出水管来混合热水和冷水。

在较旧的类型中（左侧），这根管子由两个独立的水龙头供水，分别标有“热”和“冷”。作为概念来看，这两个水龙头没有令人信服的目的。它们做什么很清楚；打开热水龙头会增加混入的热水量。但用户想要设置的是从管子里流出的水的温度和流量，而这些控制装置与这些需求没有简单的关系。如果你想提高温度，你可以打开热水龙头，但这样流量就会增加，然后你需要关小冷水龙头。同样，如果你只想增加流量，你需要同时打开两个水龙头，仔细调整它们以重新建立所需的温度。在这两种情况下，通常需要进行一系列的多次调整。

在较新的设计中（右侧），有一个具有两个独立控制装置的单一水龙头：旋转它调节温度，上下移动它调节流量。因此，这些控制装置具有与用户需求相匹配的明确目的。

转向一个软件的例子：熟悉的 editor buffer（编辑器缓冲区） 概念曾经满足过一种需求，但它不再是一个令人信服的需求。曾经，磁盘速度很慢，制作一个快速的文本编辑器的唯一方法是让用户在内存中的缓冲区里编辑文本，并定期将缓冲区保存到文件中。但这个缓冲区对用户来说没有明显的用处，实际上这也让非技术用户感到困惑：如果应用程序崩溃，或者在保存到文件之前关闭，缓冲区中的文本很容易丢失。

这大概就是苹果（在 2011 年的 OS X Lion 中）改变其所有应用程序行为的原因：更改从一开始就会被写入磁盘，而“保存”到文件只需要为文件命名。换句话说，无目的的 editor buffer 概念被消除了。随着缓冲区的消失，save-as（另存为） 操作（将缓冲区的内容保存到给定名称的新文件中）不再有意义；用户现在被期望复制该文件并对其重命名（图 5.3）。

在所有这些例子中，无目的的概念都是将底层机制暴露给用户所导致的。使用缓冲区来实现文本编辑器并没有什么错。相反，通过首先将编辑应用到保留在内存中的缓冲区，并在后台将它们写出到磁盘上的文件，编辑器可能能够提供好得多的性能。错误在于将这些复杂性强加给用户。

简而言之，概念与内部机制不同，它们总是面向用户的，并且必须具有不仅对程序员而且对用户都有意义的目的。

目的不明确的概念：Twitter 的 Favorite（收藏/喜欢）

如果一个概念的目的对用户来说不清楚，它很可能会被以设计师并未意图的方式使用。Twitter 的 favorite 概念提供了这个问题的引人注目的例子。

2017 年 5 月，为《赫芬顿邮报》撰稿的政治分析师安迪·奥斯特罗伊（Andy Ostroy）在一条推文中拿总统与他妻子的关系开玩笑（图 5.4）。她对此的反应是点击了这条推文的心形图标，显然（也大概是无意中）向 Twitter 公众发出了她喜欢这条推文的信号。不用说，当她意识到发生了什么事时，她撤回了她的赞同。

这里的争议点是 Twitter 的 favorite 概念。Twitter 实际上在 2015 年更改了该概念的视觉设计，用一颗心取代了星星图标。显然他们认为这能解决用户对该概念的困惑，但显然这对这位特定的用户没有帮助。真正的问题在于对 favorite 概念本身的根本目的存在困惑。

许多用户似乎认为 favorite 提供了一种保存推文以供自己参考的方法。这是一个合理的假设，因为“favorite（收藏夹）”这个词通常应用于具有完全相同目的的概念。然而事实证明，favorite 概念的实际目的是记录你对一条推文的赞许供他人查看——这更常见的是被称为 like（喜欢/点赞） 或 upvote（赞同） 概念的目的。

Twitter 在 2018 年解决了这个问题，重新命名了 favorite 概念，将其称为 like，这个名字适当地符合了它的目的（图 5.5）。为了解决允许用户标记推文以便（私下）保存供将来参考的另一个目的，他们引入了一个名为 bookmark（书签） 的新概念，该概念（令人困惑地）可以通过推文的“分享”图标进行访问（大概是基于将推文加入书签就是与自己分享的理由？）。

利用令人困惑的概念：保姆骗局

目的被误解的概念很可能会被滥用。available funds（可用资金） 概念的初衷是好的，但已经成为诈骗者的肥肉。当存入支票时，支票价值的一部分会出现在存款人的账户中，并立即可供提取。在美国，这是由国会在 1987 年通过的一项法案所强制规定的，该法案旨在防止银行延迟处理存款。

不幸的是，许多人将这个概念与 cleared check（已结清支票） 的概念混淆，看到余额增加，就认为支票已经被不可撤销地验证过了。犯罪分子无情地利用了这种混淆。在一个被称为“保姆骗局”的版本中，一个新雇用的家庭帮工期待得到一笔用于搬家费用的初始付款（比如 1,000 美元），结果收到了一张金额大得多（比如 5,000 美元）的支票并将其存入。然后雇主发信息要求将多余的钱电汇回去。在使用可用资金把钱寄回之后，支票被退票（跳票）了。存款被撤回，有效地提取了之前可用的资金，让这个可怜的员工出现了 4,000 美元的赤字。

这个概念真的有这么难吗？关于图像大小的故事

有时，一个单一的具有不明确目的的概念可能会引起一连串的困惑。以 image size（图像大小） 的概念和相关的“分辨率（resolution）”想法为例。即使是赞助摄影比赛的组织——你以为他们会理解这些东西——有时也会弄错，并规定图像必须有最低的分辨率。

问题在于，图像的分辨率并不能告诉你关于其质量的任何信息，除非你也知道它的大小。每英寸 360 像素的分辨率可能看起来令人印象深刻，但如果图像只有邮票那么大，那不足以获得一张清晰的明信片大小的打印照片。

为了理解这一点，你需要了解两个概念。第一个是我将称之为 pixel array（像素阵列） 的概念，这是一个无处不在（但曾经很激进）的想法，即图片可以表示为彩色像素的二维阵列。它的目的是进行图像编辑，其操作包括调整（比如对比度或亮度），这会改变像素的值，以及重采样（一个复杂得多的操作），这会改变像素的数量，通常是为了降低质量（通过用一个像素替换几个像素）或提高质量（通过插值增加额外的像素使图像在更大尺寸下打印得更好）。

你需要理解的第二个概念是 image size。它的目的很简单，就是允许将物理大小与图像相关联，但也很奇怪，因为我们往往不认为数字图像具有物理大小。图像大小决定了图像打印时的默认尺寸，以及在被导入桌面排版应用程序（如 Adobe InDesign）时在页面上的大小。然而，在所有这些应用程序中，图像通常可以被手动缩放，因此这使得 image size 成为一个目的站不住脚的概念。

最后，图像分辨率本身并不是一个概念，而是假设图像以其给定的图像大小打印时对打印质量的一种衡量。因此，如果 pixel array 是 1,000 像素见方，而 image size 是 10 英寸见方，那么分辨率就是 100 像素/英寸。

如果你还没有被这搞糊涂，看看 Photoshop 中用于修改图像大小、尺寸和分辨率的对话框（图 5.6）。在左上方，你可以看到各种参数并确认它们之间的关系：在 20 英寸宽度和 6000 像素的情况下，分辨率是每英寸 300 像素。一个锁和垂直条的符号指示了哪些参数是相互约束的。当选择*重新采样（Resample）*时（左侧的默认选项），分辨率翻倍会使像素尺寸翻倍；当未选择时（右侧），它反而会将图像宽度和高度减半。

即使对于专家来说，这些控制装置也很复杂且容易出错。image size 概念连同其值得怀疑的目的，似乎是所有这种复杂性的根源。

谁的目的？我的还是你的？

如果你试图理解一个概念的目的，一个好的开始问题是：它到底服务于谁的目的？

在社交媒体应用中，许多概念声称是为了用户的利益，但实际上旨在通过扩展社交图谱、增加使用量或销售更多广告来增加公司的利润。

例如，notification（通知） 概念声称要为用户提供及时的更新以让他们了解情况。但它的目的通常反而是增加“用户参与度”。在 Facebook 的例子中，一个明显的线索是，虽然提供了大量选项来控制哪些事件会产生通知，但目前没有选项可以完全关闭通知。

同样，tag（标记） 概念似乎服务于一个直接的目的：使寻找关于特定人物的帖子变得更容易。请注意，当 Facebook 提示你在照片中标记某人时，它有意地既没有解释标记的目的，也没有解释标记的后果（图 5.7）。同样，如果你细心的话，你就会发现其中暗示了它的真正目的。默认情况下，标记帖子不仅使其对进行标记的人的朋友可见（正如你合理预期的那样），而且还对被标记人的所有朋友可见。这巧妙地鼓励了两组朋友之间的联系，从而在社交图谱中增加了连接。

信用卡的“芯片和密码（Chip and PIN）”安全机制涉及两个目的显然不同的概念。chip（芯片） 概念似乎旨在减少假卡带来的欺诈（因为制作一张内部带有芯片的卡比制作一张带有磁条的卡要难）；而 pin（密码） 概念大概是为了减少被盗卡带来的欺诈（因为小偷不知道密码）。

然而事实证明，底层协议极易被破解，并且容易受到中间人攻击。银行不愿意修复（甚至不承认）此类问题表明，chip 概念的目的可能从来都不是为了消除欺诈，而是——通过给人一种其系统是安全的误导性印象——将任何欺诈的责任推给消费者和零售商，从而降低银行自身的成本。

具有欺骗性的目的

有时设计师会主动歪曲概念的目的，隐藏一个更阴险的目的：

• 所有问答网站都有一个 user（用户） 的概念，其目的据推测是为了阻止垃圾信息和低质量的答案。但许多网站限制了访问权限，这样，如果不先登录，就不可能发新帖，更不可能查看现有的问题和答案。在解释这一点时，Quora（图 5.8）说：“我为什么需要登录？Quora 是一个知识共享社区，取决于每个人在知道某些事情时都能参与进来。”这种掩饰隐藏了不太可能吸引用户的目的，例如收集关于他们的数据，创造更具粘性的体验，或投放更聚焦的广告。
• push poll（诱导性民意调查） 将自己伪装成一个标准的民意调查，其目的是通过汇总回答来得出一些有用的信息。但实际上，它的目的是通过问你一些经过精心设计的旨在改变你观点的暗示性问题，来争取你（通常是为了政治利益）。
• direct flight（直飞航班） 的概念是由航空公司发明的，以应对早期倾向于单一航班号航线的预订系统。通过跨航段保持相同的航班号，“直飞航班”使航空公司能够使那些航程更加突出，从而更有可能被购买。但是误解了这个目的的可怜的消费者可能没有意识到，直飞航班并不一定是不经停的。如今，大多数航班聚合网站已经放弃了这个令人困惑的概念，而那些使用它的网站至少为毫无戒心的客户添加了解释（图 5.9），并承诺不需要换飞机，这是最初的概念所没有保证的。

不匹配（Misfits）：当目的未被实现时

设计的本质是为给定的*环境（context）创造形式（form）*的挑战。期望的结果是形式和环境之间的完美“契合（fit）”，就像幼儿木制拼图板上的一块积木紧紧地贴合在它的孔里一样。

遵循这个类比，软件设计的目的描述了孔的形状。问题在于这个形状很复杂而且未被完全了解，因此无法被全面或准确地描述。归根结底，了解孔形状的唯一方法是设计一块拼图片，尝试将其插入，并发现不匹配（misfits）：拼图片不完全合适的地方。

因为孔的确切形状是不可知的，所以测试是必不可少的。在你把它放到现实世界中尝试之前，你根本不可能完全预测一个设计的有效性。但与此同时，由于形状的复杂性——以及任何给定的测试只揭示了它的一些方面——测试不可能是万能药。

你永远无法完全预测设计的所有潜在不匹配，但你至少可以建立在过去发现不匹配的经验之上。因此，虽然全面列举需求是不可能的，但列举负面需求——要避免的不匹配——是可行的。

概念通过两种方式减轻了不匹配的风险。首先，通过将设计分解为各个概念，实现整个设计契合度的挑战被简化为一组更易于管理的子问题。

其次，概念体现了反复出现的需求，并提供了跨环境的共性。在一种环境中了解到的关于某个概念的不匹配通常也适用于另一种环境。例如，reservation（预订） 概念的一个不匹配是有人可能会霸占多个名额而并不打算全部使用。如果你正在构建一个包含预订的系统，那么在设计时被提醒有这个潜在的障碍会很有帮助，并考虑通常用于减轻这个问题的各种功能，比如对缺席的惩罚以及防止预订重叠（例如，同一天晚上在不同餐厅订桌）。

在接下来的几节中，我们将研究一些提供信息的（informative）不匹配案例。我选择的例子说明了可能出现的各种不匹配，并提出了预防这些不匹配的不同策略。

糟糕设计导致的致命不匹配

2001 年 12 月，在阿富汗的一名美国士兵请求对塔利班的一个前哨基地进行空袭，他使用的是一种叫做 PLGR（Precision Lightweight GPS Receiver，精确轻型 GPS 接收器，发音为 “plugger”）的设备来生成目标的坐标。当他试图进行计算时，设备的电池没电了，所以他更换了电池。当他重新启动设备时，看起来计算出的坐标似乎仍然可用。

他没有意识到的是，该设备被设计为在重启时默认使用其自身的 GPS 位置。因此，这个倒霉的用户呼叫了一次针对自己位置的打击，一枚 2000 磅重、卫星制导的炸弹没有落在塔利班的前哨，而是落在了美军阵地上，导致 3 名士兵死亡，20 人受伤。

在这个案例中，如果设备设计师考虑了 battery（电池） 概念和 target（目标） 概念之间的交互，这个不匹配本来是可以预测到的。对设计进行任何一些直接的修改都可能避免灾难；在后来版本的设备中被选择和实现的一种修改是在这种场景下显示警告信息。（替换设备，被称为 “DAGR”，在图 5.10 中显示了新的警告信息。）

环境变化带来的不匹配

随着大流行的到来，人们开始通过诸如 Zoom、Google Hangouts 和 Microsoft Teams 等通信应用在线进行所有的幻灯片演示。一个令人烦恼的不匹配出现了。当你播放演示文稿时，幻灯片演示应用程序会切换到全屏模式。通信应用的面板要么消失了——让你在进行演讲时令人不安地不知道自己是否还有观众——要么挡住了幻灯片，让你很难看到自己正在展示什么。

苹果对这个不匹配的优雅解决方案是在其幻灯片演示应用 Keynote 中增加 slideshow（幻灯片放映） 概念的一个“在窗口中播放”模式，在这个模式下，幻灯片出现在一个不再占据整个屏幕的常规窗口中。

这个例子展示了当使用环境发生演变时，不匹配是如何出现的。类似的不匹配出现在我之前（在第 4 章中）提到的苹果 trash（废纸篓） 概念中的问题里——如果没有永久删除从计算机主驱动器删除的所有文件，就无法恢复 U 盘上的空间。在四十年前设计废纸篓时，个人电脑没有外部驱动器（更不用说微型的 U 盘了）。

一个古老的不匹配回归了

在电子表格中，从一系列连续单元格计算其结果的公式可以使用 range（范围） 概念来表达。例如，你可以不写 B1 + B2 + B3 这样来定义三个单元格的求和，而是写类似于 SUM(B1:B3) 的形式（图 5.11）。

range 的目的不是为了在你输入公式时节省打字，也不是为了在查看时让公式更简洁——这两者都可以在不引入新概念的情况下（在语言层面上）实现。相反，它的目的是允许公式适应系列中单元格的添加和删除。如果你在第 1 行和第 2 行之间添加一行，为了在系列中包含一个新单元格，明确版本的公式必须手动更改为读作 B1 + B2 + B3 + B4，但范围公式将自动调整为 SUM(B1:B4)。因此，range 的操作原理可以表述为：

如果你创建了一个依赖于一个范围的公式，然后通过在范围内添加一行或一列来更新电子表格，公式会自动调整以包含新的行或列。

问题在于“在范围内”是如何定义的。你可能会认为这个范围是由两个标记限定的：一个在范围内的第一个单元格之前，一个在最后一个单元格之后。因此，“在”范围内添加内容，可能包括在范围内最后一行下方（在该最后一行和标记之间）添加一行，或者在第一行上方添加一行。

苹果的电子表格应用 Numbers 为一般的添加行提供了两个独立的操作，一个是针对当前行下方的，一个是针对上方的（以及对应添加列的操作）。这些操作绑定在键盘快捷键上，所以扩展一个范围应该是快速且容易的。

选择范围的最后一行并在它下方添加一行，应该将新行包含在范围内，但是选择范围下方的一行并在它上方添加一行，应该将新行排除在范围之外。这听起来可能很复杂，但实际上非常直观：如果你选择的是范围内的某一行，那么无论你执行什么操作，无论是在上方还是下方添加一行，新行都应该在范围内。但如果你从范围外开始，新行也应该在范围外。

这实际上恰好就是 Numbers 曾经的表现方式（在 2009 版本中）。目前的版本对范围的第一行和最后一行采取了不同的处理方式。如果你在第一行上方或最后一行下方添加一行，它都不会在范围内，无论你选择的是哪一行以及你执行的是哪种添加行的操作（在上方添加或在下方添加）。

在实践中，这种不匹配是一个极大的烦恼。我有一个电子表格，在里面我跟踪我咨询项目的账单（图 5.12）。表格的每一行对应一个可计费的工作周期，还有一个汇总行，给出花费的总时间。每次我完成一项工作，我就会在表格上添加一行。在旧版的 Numbers 中，我只需选择代表我完成的最后一个周期的行，发出 add row below（在下方添加行） 命令，然后在新的行中填写字段。

在新版 Numbers 中，这不再有效。我只能在范围内的倒数第二行前面添加新行，然后向上拖动最后一行，把它放在新行之前。或者我可以在最后一个条目之后添加一个虚假的空行，并将其包含在公式中（见图 5.12 中表示公式作用域的阴影区域）。这碰巧能行得通，但这仅仅是因为汇总时间段的公式碰巧将伪行中的空单元格视为零。顺便说一下，Microsoft Excel 存在完全相同的缺陷（并且缺乏在当前行上方或下方添加行的独立操作）。

这个不匹配的谜团不在于苹果为什么做错了，甚至也不在于它本可以做些什么来捕捉到它（仔细考虑一下操作原理可能会揭示它）。更令人惊讶的是，苹果的设计师知道了正确的设计，然后显然又把它给忘了。也许如果苹果的设计师在概念目录中记录了他们的见解，他们最好的想法就能更容易地在版本更迭中保留下来。

经验教训与实践

本章的一些经验教训：

• 概念设计从问一个简单的问题开始，对于每个提出的概念：它是用来做什么的？回答它可能很难，但会带来红利。
• 对于用户来说，了解概念的目的是使用它的先决条件。许多手册和帮助功能解释了行为的细节，但没有解释目的，这会带来不愉快的后果，尤其是对新手而言。
• 一个概念的目的应该是有说服力的、以需求为中心的、具体的并且是可评估的。比喻很少有助于解释概念是用来做什么的。
• 一个没有目的的概念是值得怀疑的。当这种情况发生时，通常是因为该概念根本就不是一个概念，而是一个内部机制的残余，本不应该暴露给用户。
• 对概念目的的混淆会导致滥用，并可能被利用来诱骗用户参与他们会后悔的行为。
• 阻止概念实现其目的的不匹配是很难预测的，因为使用环境随着时间的推移而演变。概念通过提供记录经验的结构来提供帮助。

以及一些你现在就可以应用的实践：

• 如果你在使用一个概念时遇到困难，首先寻找证据来证明你可能误解了该概念的目的。
• 当你向某人解释一个概念时，无论在什么环境下，都要从目的开始。
• 当你提议向你正在工作的产品添加一个概念时，首先制定一个令人信服的目的，并检查它是否与你的用户产生共鸣。
• 当你的团队开始开发一个概念时，甚至在你们进行任何用户界面草图绘制之前，写下一个简要的概念描述，并确保所有的设计师和工程师都在目的和操作原理上保持一致。