The Essence of Software.Chapter.09.概念专一性

本章将解释一个简单的原则，这个原则在揭示设计问题方面具有出人意料的深远影响。事实上，它太简单了，以至于你可能会想忽略它，但我希望接下来的例子能让你相信它的价值。

这个规则是说，在软件产品的设计中，概念和目的应该是一一对应的。也就是说，对于每个概念，应该恰好有一个促成它的目的；对于产品的每个目的，应该恰好有一个实现它的概念。

你可能对“一个概念至少应该有一个目的”并不感到惊讶：如果没有目的，概念还有什么意义？或者对于产品而言已被认定为重要的目的，应该有一个概念来实现它。同样，每个目的应该最多由一个概念来实现以避免冗余，这也绝对是合理的：为什么要浪费精力呢？

更激进的建议是，一个概念应该最多实现一个目的。然而，专一性原则的这一方面最终被证明是概念设计中最有用的见解之一，并且将是本章我们关注的重点。

没有目的的概念

没有目的的概念是个奇怪的怪物，但我们在之前（第5章）看到过例子：大部分情况下，例如编辑器缓冲区，这是由于向用户暴露了内部机制。因此，本节本身也没有什么目的，因为我已经相当详细地讨论过这个话题了。

没有概念的目的

对设计的批评可能会揭示出一个没有对应概念去实现的本质目的。由于所有软件产品都会随时间演进，总会出现新需求——但这并不是这类设计缺陷所指的。相反，它指的是那些从一开始就显然缺失并且缺失得令人发指的概念。

如果一个概念明显缺失，为什么设计师不立即添加它呢？一个原因是它提出了一个不易解决的挑战。例如，大多数电子邮件客户端都缺乏联系人（correspondent）的概念，该概念的目的本应是识别电子邮件的发送者和接收者。在像Gmail这样的封闭电子邮件系统的范围内，这很容易做到，但要在更广泛的范围内提供这一概念，将需要一个通用的身份验证基础设施。

如果有了这个概念，电子邮件的发送者字段就不能被伪造，垃圾邮件也会更容易控制。它还会带来一个更平凡但亟需的好处。在Apple Mail中，你无法可靠地搜索来自特定发送者的邮件。搜索栏误导性地提供了按“人（people）”搜索的选项，但结果证明那只不过是在邮件的“发件人”和“收件人”字段中匹配字符串。

大多数人都使用过不止一个电子邮件地址，因此搜索他们会显示出多个不同的“人”。而且，有些人在不同的电子邮件帐户中以不同的格式书写自己的名字，因此你可能需要搜索不同的字符串才能找到来自同一个人的所有电子邮件。在图9.1中，你可以看到使用我妻子的名字进行的搜索甚至带出了我自己的电子邮件地址（可能是因为有人向我的电子邮件地址发送了邮件，但在“收件人”字段中写了我们两个人的名字）。

下面是一些关于没有概念的目的的更多例子：

备份中的删除警告。 大多数备份实用程序的服务条款（以及它们备份（backup）概念的行为）中都有一个令人不安的漏洞。在一段时间（例如30天）过后，从被备份的机器上删除的文件也会从备份本身中被删除。这项策略的理由很明确：它防止客户将备份服务作为无限的云存储使用。

然而，具有讽刺意味的是，人们需要备份的主要原因之一正是他们会意外删除文件。如果备份工具能提供一个概念来跟踪删除操作并在发生时发出警告，那将非常有帮助且令人安心，这样你就可以在为时已晚（文件在您注意到之前已从备份中清除）之前，确定这些删除是否是有意的。这个概念的设计并不简单，还需要考虑重命名的情况。

缺失的样式概念。 有时，一个概念在一类应用程序中经常被使用，但在另一类中却不可用，尽管它在那里也会非常有用。样式（style）的概念在文字处理器和桌面排版工具中无处不在，但直到最近才被引入到Apple的幻灯片演示应用程序Keynote中；而Microsoft PowerPoint中仍然缺失这个概念。如果没有样式，想要保持一致的格式并不容易，特别是对于像公式、代码和引用这些通常在排版上有所区分的文本。

残留的模板概念。 偶尔，一个概念被包含在设计中，但它的形式非常有限，以至于未能实现其通常的目的。大多数建站应用程序都包含模板（template）（有时称为主题（theme））的概念，其目的是将视觉设计与内容解耦。这让你能够专注于网站的内容，并单独选择一个决定布局、颜色、字体等的模板。这种解耦的关键在于，你不需要从一开始就绑定到一个模板上；你可以从任何看起来合理的模板开始，放入一些内容，然后尝试其他的模板，看看你的内容在这些模板下的效果如何。

这个概念曾在Squarespace中实现，但在2020年初发布的7.1版本中却莫名其妙地受到了阻碍，当时他们取消了切换模板的功能。这让用户陷入了困境，因为新版本带来了几项改进（最显著的是跨所有模板的统一数据模型，人们可能以为这会使得模板切换更容易实现）。

随着技术的激增，人们很容易认为所有真正的问题都已经解决了。令人欣慰的是，这些孤立的目的表明，一些最基本的需求尚未得到满足，即使在最熟悉的背景下，仍然有重要的设计工作要做。

冗余的概念

当已经存在另一个旨在服务相同目的的概念时，一个概念就是冗余的。这种情况可能会发生，因为设计师最初看到了两个截然不同的目的，但它们最终被证明是一个单一的、更普遍的目的的变体。

Gmail 的分类。 Gmail 引入了分类（category）的概念，其声称的目的是支持对传入电子邮件的自动分类（图9.2）。新概念不再是将用户收件箱中的所有邮件在一个列表中显示，而是提供了分类划分：“主要（primary）”（针对来自个人联系人的电子邮件）、“社交（social）”（针对与社交媒体帐户关联的邮件）、“促销（promotions）”（针对推销）、“更新（updates）”（针对通知、账单、收据等）以及“论坛（forums）”（针对与群组和邮件列表关联的邮件）。

你可能认为这个新概念只会受到热烈欢迎。毕竟，它提供了强大的新过滤功能，承诺整理收件箱并让用户获得更多控制权。然而，这个新概念却遭遇了一连串负面文章和博客帖子的抨击。很长一段时间里，在Google上搜索“Gmail categories”，在搜索结果上方的第一个问题就是“我该如何摆脱分类？”

我相信，这种消极情绪的原因在于分类概念是冗余的。几篇批评性的博客帖子指出，Gmail 的标签（label）概念已经满足了相同的目的：邮件分类。此外，该概念已经包含了在没有用户干预的情况下附加的“系统标签”（如已发送（sent）），完全可以轻松地容纳一种新的分类算法。

那么，为什么Google不简单地将新分类实现为系统标签呢？如果他们这样做了，用户就不必去理解分类这一新概念，也不必去理解那些用来区分分类和标签的看似随意的限制——例如，只有分类才能被分配给选项卡，或者只有标签才能用于对收件箱外部的邮件进行分类。

Zoom 广播。 在 Zoom 视频会议应用程序中，你可以将通话的参与者移至“分组讨论室”。通话的主持人可以使用广播（broadcast）概念向所有参与者发送消息。

为什么需要这个概念？Zoom已经有了一个聊天（chat）的概念，允许参与者在整个通话过程中交换文本消息。聊天菜单允许参与者选择将消息发送给特定参与者还是“所有人（everyone）”。令人困惑的是，在分组讨论室中，“所有人”具有不同的含义，仅指房间内的人；没有选项向其他房间的参与者发送消息。此外，一旦参与者被转移到分组讨论室，主持人就无法向参与者发送消息；参与者也不能对其他房间的参与者讲话。因此，聊天概念不允许主持人向分组参与者发送消息，这就是引入广播概念的地方。

更好的设计可能会完全废除广播，并扩展聊天概念，以便可以跨分组讨论室发送聊天消息。就像 Gmail 的分类和标签一样，聊天和广播消息虽然实现了相同的目的，却奇怪地无法比较：广播消息在屏幕上闪烁，而聊天消息则出现在滚动的消息日志中；广播可以跨越分组讨论室，但消息不能；消息保存在消息日志中，但广播会消失。对用户来说最令人沮丧的是，广播消息只出现几秒钟，它们包含的任何链接都不可点击，其内容也无法复制粘贴。

理想情况下，聊天概念应该提供这两个概念的功能。在分组讨论室内，聊天菜单允许将消息定向发送给房间内的所有人或整个会话中的所有人；它支持向所有参与者单独发送消息，即使他们在不同的房间内；特别是，主持人将能够向分组讨论室中的所有人发送消息，即使他/她不属于任何一个房间。

Apple Mail 中的搜索和规则。 Apple Mail 有一个搜索框，允许你输入消息的各种属性（例如正文中出现的文本，或者发送者或接收者的姓名），然后相应地过滤显示的消息（图9.3）。还有一个用于创建过滤传入邮件规则的对话框，该对话框允许你选择满足特定条件（例如“收件人”字段是否提及了你的名字）的邮件。

这两个特征的基础是一个共同的目的，我们可能称之为 邮件过滤，它让你定义邮件的子集，一种情况用于显示，另一种情况则用于应用某些操作（如移动到文件夹）。然而，这一单一的共同目的实际上在两个截然不同的概念——规则（rule）和过滤器（filter）——中被实现了两次，每次都提供了略微不同的功能。规则能而过滤器不能指定不精确的匹配（例如，包含而不是等于）；规则能而过滤器不能检查抄送（cc）字段；过滤器能而规则不能指定邮件已签名；等等。相比之下，Gmail 在单一概念中统一了规则和过滤器。

在所有这些情况下，消除冗余不仅可以节省开发人员的工作，还可以为用户提供更简单、更强大的工具。

过载的概念

现在来到最有趣的准则：一个概念最多应该有一个目的。一个概念无法很好地服务于两个目的。目的指导着概念设计的方方面面。如果你有两个不同的目的，它们必然会朝着不同的方向拉扯，概念设计将不得不在偏向其中一个时做出妥协。更有可能的是，设计最终将无法完全满足任何一个目的，因为它在这里被拉向一个方向，在那里又被拉向另一个方向。

服务于两个目的的概念是过载的（overloaded）。在接下来的几节中，我将给出过载的例子，按其原因分为四种类型：

• 错误收敛（False convergence）：当一个概念被设计用于两个不同的功能时，而这两个功能被（错误地）假定为同一目的的两个方面时发生。
• 否认的目的（Denied purposes）：尽管用户有这方面的期望，但被设计师忽略的目的。
• 涌现的目的（Emergent purposes）：为旧概念赋予的新目的，通常由用户自己发明。
• 搭便车（Piggybacking）：当对现有概念进行调整或扩展以适应新目的时发生。

每一类过载都有其补救措施：

• 避免错误收敛的方法是努力准确地阐明单一目的，并检查该概念的不同动机是否真正反映了相同的目的。
• 避免否认目的的方法是认真对待用户的意见和经验，特别是那些技术水平较低、在技术采用方面较不情愿的用户。
• 涌现的目的最难避免，因为没人能预测设计会以何种方式影响其使用环境并产生新的用途。不过，只要在涌现的目的出现时识别出它们，就能应对它们，比如通过添加新概念来适应新目的。
• 最后，避免搭便车的方法是，要意识到将概念用于矛盾目的以“优化”设计的冲动，并且明白在这样的重用中所节省的精力会导致复杂性，最终要付出高昂代价。

由于错误收敛造成的过载

有时，一个概念的两个不同目的似乎非常一致，以至于设计师将它们视为一个单一的、融合的目的，直到后来才清楚这不仅是两个截然不同的目的，而且它们可能互不一致。 例如，在 Facebook 中，你可能会将朋友（friend）概念的目的描述为“允许两个用户建立一种可以互相查看对方帖子的关系”。这种表述的问题在于它隐藏了两个截然不同的目的。一个是过滤：通过推广你朋友的帖子，Facebook 省去了你在不感兴趣的人的帖子中筛选的麻烦。另一个是访问控制：通过选择你的朋友，你可以选择让谁看到你的帖子。

对于大多数用户来说，这些目的确实通常是一致的，因为人际关系往往是对称的：如果我很高兴你能看到关于我个人生活的帖子，我可能也对看到关于你个人生活的帖子感兴趣。但对于名人来说，这种对称性就被打破了。我可能想读巴拉克·奥巴马的帖子，但我怀疑他会想读我的。

认识到这一点后，在2011年，Facebook 添加了关注者（follower）概念，它仅服务于过滤目的，而不服务于访问控制目的。朋友概念仍然兼具这两个角色，但你可以通过对那些你不想看其帖子的朋友关闭“关注（following）”，从而仅将朋友用于访问控制。

由于否认目的造成的过载

像错误收敛一样，否认目的涉及一个在最初设计时就存在的第二个目的。但在这种情况下，设计师拒绝了该目的，认为它不值得在设计中得到认可。

列出然后拒绝候选目的通常是值得赞赏的。这是防止应用程序设计臃肿的一项关键策略。构建一个能解决所有可能问题的瑞士军刀式应用程序是非常诱人的，但结果通常不尽人意。“构建能运作的最简单事物（The Simplest Thing That Works）”这一敏捷开发理念，既适用于选择要解决的目的，也适用于设计实现这些目的的概念。然而有时候，省略一个目的可能是一种固执和否认的行为，以愿景的纯粹性为名而忽略了用户的需求。

Twitter 的喜欢（favorite）概念（在第5章中讨论过）就是这样的一个例子。在 Twitter 2018年引入书签（bookmark）概念之前，其用户除了将推文设为“喜欢”并公开展示这一选择之外，没有其他方法来保存推文。因此，喜欢概念被迫服务于两个不兼容的目的：表达赞同和保存推文以供以后阅读。

我通常避免谈论编程工具，因为大多数人对它们并不熟悉，但这里有一个例子，我希望能令人信服地解释清楚。程序员使用诸如 Git、Subversion 和 Mercurial 等版本控制系统来管理代码库上的团队工作，并跟踪文件的多个版本。然而在实践中，许多用户——尤其是那些不太专业的用户——也使用这些工具进行备份。

想一想就知道了。所有这些系统都允许你频繁地将你的工作从可能随时发生故障的本地机器复制到服务器，并保留每个文件随时间推移的多个版本，你可以随时恢复到这些版本。这不正是备份系统所做的事情吗？如果你已经在使用这样一个系统，为什么不用它来备份那些已经存储在仓库中的文件呢？

不幸的是，这些工具的设计者通常不同意这种观点。此处相关的概念，即提交（commit），是为不同的目的而设计的，即用于存储对应于连贯开发状态的项目快照。例如，当一个功能完成时，或者当你的工作处于足够完善的状态以受益于同行评审时，你可能会执行一次提交。

这个目的与备份目的不兼容，因为你希望尽可能频繁地备份你的文件。如果你做了一大块未完成的工作，你肯定会想要备份它，但它可能不处于连贯的状态。这就让你陷入了两难境地。如果你提交了这个工作成果，你将会歪曲它，并且（正如开发人员所说的）通过插入没有连贯含义、甚至可能无法编译的提交来“污染提交流程图（commit graph）”（图 9.4）。但如果你不提交它，它就不会被复制到云端，如果你的机器发生故障，你就有丢失它的风险。

由于涌现目的造成的过载

在设计时，一个概念可能只有一个令人信服的目的，但随着用户发现该概念的新用途，它后来可能会获得额外的目的。电子邮件中普通的旧“主题行”的故事就是一个很好的例子。

主题行（subject line）概念可以被视为一个更普遍概念的实例，比如摘要（precis），其目的是通过给出一个在原创文本旁创建或稍后添加的简短总结，来使查找、过滤和吸收长文本变得更容易。

有着这样简单的起源，人们可能不会预料到主题行后来扮演了许多辉煌的角色。Listserv（邮件列表）软件在主题行中添加了带有邮件列表名称的前缀，使收件人更容易分辨该消息不是直接发送给他们的，这显然复制了收件人（to）字段的目的（图9.5）。后来，像 Gmail 这样的电子邮件系统开始使用主题行作为启发式方法，将邮件分组为对话。

这些新涌现的目的似乎无害，但事实并非如此。一位朋友告诉了我一个案例：他部门里的某个人给几位同事发了一封邮件。他们使用了密件抄送（bcc）功能，密件抄送给了一些收件人，其中包括一个为少数部门官员设立的邮件列表的电子邮件地址。该邮件列表在主题行中如实地暴露了自己作为消息接收目标，破坏了密件抄送（bcc）概念本应提供的隐私保证。

将主题行用于对话分组是一个已知问题，因为它会虚假地将碰巧具有相同主题的邮件关联在一起。我的一个学生告诉我，他喜欢为与不同旅行相关的邮件分配不同的标签，这样他就可以通过针对相应标签进行过滤来查看与特定旅行相关的所有邮件。

不幸的是，他的旅行公司对所有确认信都使用“您即将到来的旅行”作为主题行，导致关于不同旅行的邮件属于同一个对话。而且，由于在 Gmail 中对标签进行过滤会带出与带标签的邮件在同一对话中的所有邮件——这是我在第8章中解释过的设计缺陷——他无法在使用标签仅显示一次旅行的邮件时不看到其他旅行的邮件。

由于搭便车造成的过载

过载最常见的原因是设计师看到了使用现有概念来支持新目的的机会，从而避免了对新概念的需求——进而省去了设计和实现它的麻烦。设计师可能还会想象用户会欣赏使用更少（且更丰富）的概念所带来的经济性，但这通常是虚幻的。拥有更多连贯且令人信服的概念，要好过拥有更少但复杂且令人困惑的概念。

Epson 纸张大小的非同寻常的概念。 在 Apple 的 macos 操作系统中，打印机驱动程序可以在打印对话框中提供特定于打印机的设置。Epson 照片打印机提供了许多类别的特殊设置，例如，允许你选择纸张类型，调整打印之间的干燥时间等等。

这些打印机通常为不同种类的纸张提供几种不同的进纸（feed）选项：从顶部、从背面或前面、从纸卷进纸等等。这个纸张来源（paper feed）概念是如何控制的呢？

Apple 有一个内置的纸张大小（paper size）概念，在大多数应用程序中通过页面设置菜单进行设置。纸张大小的目的是为了能够仅定义一次标准纸张大小就轻松地重用它们。除了内置的纸张大小（例如标准信纸大小）之外，你还可以定义任意尺寸的自定义大小以及边距。当你在此应用程序中选择纸张大小时，它会适当地调整页面大小（换行文本并考虑边距）。当你打印页面时，纸张大小会传递给打印机，以便它可以检查它是否与打印机中装载的纸张大小相匹配。

可悲的是，Epson 没有将纸张来源作为新概念添加，而是选择让它搭纸张大小概念的便车。当你打开页面设置菜单时，纸张大小选项的名称包含了纸张来源设置（图9.6）！

这似乎是一个小小的取巧，但它却造成了巨大的破坏：

• 当你为稍后打算在 Epson 打印机上打印的文档选择纸张大小时，你必须提交（commit）这些专门选项中的一个。你甚至宁愿不与特定打印机绑定（以便你稍后可以在打印对话框中选择使用哪台打印机），更不用说进纸选项了。
• 由于进纸选项硬连接到打印机驱动程序附带的某些标准纸张大小中，因此你无法创建新的自定义纸张大小，因为进纸选项不可作为用户自定义的设置。
• 某些应用程序使用页面设置来定义预设。Adobe Lightroom 有一个打印机预设（printer preset）的概念，可让你为给定的纸张大小定义边框和布局。例如，你可能会定义一个明信片预设来从照片创建明信片。由于预设依赖于纸张大小，因此如果你想打印到 Epson 打印机，则需要选择包含进纸选项的搭便车纸张大小之一。结果，你的打印机预设现在变成了特定于进纸的。

Fujifilm 的宽高比。 Fujifilm 相机允许你在相机中设置图像的宽高比（aspect ratio）。这个概念的目的是让你在拍摄时可以在取景器中以特定的宽高比来为最终图像构图。例如，你可以选择拍摄正方形的图像（图9.7）。

要设置宽高比，你要打开那个名字叫得有些不妙的图像大小（image size）菜单（图9.8，左）。你可以看到我选择了一个正方形（1×1）的比例，但奇怪的是，我还得选择图像分辨率——在这个例子中，是“L”表示大（large）。

另一个名为图像质量（image quality）的菜单（图9.8，中）让你选择照片记录在存储卡上的方式：仅作为 raw 文件，或作为 JPEG（普通或精细质量），或两者的组合。

假设你想要拍正方形的照片并且只把它们存为 raw 文件。如果你把图像质量切换成 raw，你会发现图像大小的设置变灰了，并被“RAW”这个词取代（图9.8，右）。这对于图像大小来说是合理的——比如我们选择的大尺寸设置——因为它们不适用于总是包含所有传感器像素的 raw 文件。但为什么我们的宽高比现在也丢失了呢？

没有什么充分的理由。宽高比概念在 raw 文件上完美运作（它优雅地将裁剪轮廓保存为可编辑的元数据），但由于它通过过载与 JPEG 尺寸绑定，所以无法单独应用于 raw 文件。在实践中，这意味着如果你只想以 raw 格式记录图像，同时你又想要自定义宽高比，你必须选择包含 JPEG 文件的 raw 文件图像质量设置，然后再删掉这些 JPEG 文件！

补救措施很简单，只需提供一个有别于图像大小概念的宽高比概念。将它们正交化，就可以让自定义宽高比独立于文件类型。菜单也会更简单：不需要为三种图像大小和三种宽高比的所有组合提供九个条目，而是两个各包含三个条目的菜单。

这看起来像是个小细节，但我怀疑这是否正是 Fujifilm 不愿意提供更多宽高比（许多用户已经请求过，甚至还有在线请愿）背后的原因。因为如果没有一个独立的宽高比概念，菜单选项会呈指数级增长，随着新比例的加入，图像大小菜单会增长到令人无法接受的程度。

目的粒度与连贯性

设计是否表现出冗余或过载，将取决于目的的表述方式。你可能会想，这难道不是一个相当主观和随意的判断吗？如果我们只是试图通过声明一个合并了以前两个不同目的的新目的，以此来解决过载问题，那会怎样？这会消除单一概念拥有两个目的的问题吗？当然不会：我们需要一些*连贯性（coherence）*的测试来揭示何时多个目的在伪装成一个目的。

理想情况下，一个目的的表述不会区分情况，这样其连贯性在措辞本身中就很明显了。例如，当我在这章前面谈到建站应用程序使用的模板概念时，我说它的目的是“将视觉设计与内容解耦”。这种表述含蓄地统一了各种活动，而没有暗示出多个目的。

但假设我把目的描述为“让你从别人设计的模板开始，从而更容易构建具有吸引力的视觉设计的网站，然后可以在不必重新开始的情况下更改模板。”这肯定是一个不优雅的目的，并且通过引用特定行动的细节，它开始类似于操作原则。但将其作为一个单一目的提出并没有错，因为各个部分都是一个单一且连贯的目的的各个方面（尽管用解耦来总结更好）。事实上，这就是我对 Squarespace 设计的批评，它把每个部分都当作其自身的一个目的。

如果一个目的被表达为多个部分，那么，我们如何知道它是否连贯呢？这里有一些准则：

• 重新表述（Reformulation）。 是否存在一种没有多个部分的令人信服的重新表述？
• 共同的利益相关者（Common stakeholders）。 每个部分的好处是否都归于相同的利益相关者？
• 共同的使命（Common mission）。 如果我们为每个部分确定一个更高层面的目的（我们可以称之为“使命”，以将其与概念的直接目的区分开来），这些部分会有相同的使命吗？
• 非冲突（Non-conflict）。 这些部分是不冲突的吗？或者我们能否想象一个用户可能想要其中一个而不想要另一个的场景？

让我们看一个例子，看看如何应用这些准则。

应用连贯性准则：Facebook 的点赞有多个目的

当你点击 Facebook 帖子下方的“赞（like）”按钮时，会显示七个表情符号，提供从爱到生气的不同情绪（图9.9）。如果我们把它当作一个概念——我们称之为点赞（like）——这个概念的目的会是什么呢？

会想到几件事。最明显的是，点击其中一个表情符号会将你的情感反应传达给帖子的作者（尽管是公开的）。这可能也是大多数 Facebook 用户在点击时的想法。

但还有更多内幕。如果你玩过 Facebook，你会发现你喜欢的东西会影响向你显示的帖子，以及它们出现的顺序。通过指出你喜欢的帖子，你正在为未来策划你的信息流，使其更有可能包含你想看的帖子。

没那么有帮助的是，Facebook 会跟踪你的点击以建立个人数据档案，该档案用于向你投放定向广告。从你帖子的内容，以及你对他人帖子的反应，Facebook 在从爱好到性取向等众多指标上对你进行分类。

总结来说，我们可能会说点赞概念的目的是“传达情感反应、策划你的动态消息（newsfeed）以及为定向广告提供跟踪数据”。将这些视为三个截然不同的部分，我们现在可以应用我们的准则。

重新表述。 “对帖子做出反应”听起来很合理，但它并不以需求为中心，因此不是一个目的（如第5章中所释）。不过我不确定我能做得更好。

共同的利益相关者。 Facebook 毫无疑问会辩称，将你的数据出售给广告商以允许他们更有效地锁定你，也能通过向你展示更多相关的广告而使你受益。但我们大多数人都会抵制这种说法，而认为广告商和 Facebook 本身才是受益者。相比之下，策划你的动态消息只是为了你自己；而传达情感是与更广泛的社区共享的好处。简而言之，似乎每个部分都有利于不同群体的利益相关者。

共同的使命。 同样，各部分的使命也存在分歧。情感反应服务于建立人际关系和社区；策划你的动态消息服务于你对更吸引人和更有信息量的内容的需求；而为广告商进行跟踪则服务于 Facebook 的底线。

非冲突。 最后，各部分也是有冲突的。当然，大多数用户都希望能策划他们的信息流，但更希望不被跟踪。发送反应也与策划信息流不太一致；你可能想向朋友发送支持的姿态，但更希望不要看到他们更多的帖子。“生气”的表情符号尤其令人困惑：你是同帖子的作者一起生气（表示支持他们的愤怒），还是你对这个帖子感到生气？似乎这两种反应都有在使用，但根据 Facebook 的说法，就策划你的信息流而言，所有的反应都有相同的效果，并表明（正如主按钮所暗示的那样）你“喜欢（like）”这个帖子，即使它让你“生气”。

总而言之，我们的复合目的被连贯性准则揭示为多个目的，因此 Facebook 的点赞概念是过载的一个例子。

拆分一个概念：Facebook 点赞应该包含多个概念

过载的补救措施是拆分概念，为每个目的创建一个新概念。在这种情况下，我们可以将点赞拆分为三个概念：反应（reaction），其目的是传达对帖子的情感反应；推荐（recommendation），其目的是让你能够策划你的信息流；以及侧写（profiling），它用于构建用于投放定向广告的广告档案。

在进行这种拆分时，最令人鼓舞的迹象是这些新概念已经存在了。而且，事实上，反应概念（没有策划的反应）出现在了诸如 Slack 和 Signal 这样的通讯应用中；推荐概念（没有反应的策划）出现在了 Netflix 中，点赞（thumbs-up）或踩（thumbs-down）会影响推荐哪些电影；而侧写概念被 Google 的 Gmail 服务用于根据你的电子邮件内容投放定向广告。

通过将这些视为三个截然不同的概念，我们现在可以探索不同程度的同步。在光谱的一端，我们可能会有一种几乎没有任何同步的自由组合。在这个版本中，用户必须为每个概念点击单独的按钮。这并非完全不合情理，因为它将赋予用户完全的控制权，但这不符合 Facebook 的利益，因为很少有人会点击侧写按钮。

在光谱的另一端，这些概念将完全同步，因此点击情感反应也对应于对帖子进行点赞以进行策划并为你的个人侧写做出贡献。这当然就是现在 Facebook 的设计方式。过载的问题已经转化为过度同步的问题。但至少在概念被分离的情况下，设计中有更清晰的指示表明概念被耦合在了一起，而且概念本身在试图于冲突的目的之间周旋时被破坏的风险也更小。

在这两个极端之间，还有其他的设​​计点。一种选择是继续隐藏侧写动作，但将反应和推荐区分开来，用一组按钮发送反应，用单独的按钮来赞成（upvoting）或反对（downvoting）帖子。

事实上，Facebook 用户曾要求提供一个“不喜欢（dislike）”按钮，而 Facebook 拒绝了该建议，理由是不喜欢会给平台引入一种消极情绪。这似乎是不真诚的，它假设了点赞概念尚未被拆分。如果拆分为推荐和反应，你就可以不喜欢一个帖子（执行recommendation.thumbs-down动作），而不会发送任何社交信号。

毫无疑问，Facebook 的设计师们已经考虑了所有这些因素以及更多。概念所带来的是一个新的框架，可以在其中分析设计并做出有原则的权衡。拆分概念之所以有价值，在很大程度上是因为它允许将一个特立独行的概念（如 Facebook 的点赞概念）分解为更连贯、更熟悉的概念——从而为易于理解的用户体验提供更好的基础，为记录和保存设计知识提供更好的结构。

经验与实践

本章的一些经验教训：

• 专一性原则指出，概念应该与目的成一对一的对应。这个简单的规则对概念设计有着深远的影响。
• 没有目的的概念很少见，但可能是由于向用户暴露了本应隐藏的机制而引起的。
• 没有概念来实现的目的，可能表明了源于设计师领域之外的约束，或者有时仅仅是令人发指的遗漏。
• 冗余，当多个概念服务于同一目的时，会使用户感到困惑并浪费资源。
• 过载，即一个单一概念有多个目的，其产生方式有几种：来自错误收敛，即设计师错误地以为多个目的实际上是一个；来自被否认的目的，即设计师有意忽略了一个目的，而用户随后为该目的编排了一个现有概念；来自涌现的目的，即概念随着时间的推移找到了新的（通常是不兼容的）目的；以及来自搭便车，即设计师试图通过将新目的附加到旧概念上来节省设计和实现的精力。
• 违反上述任何一项都会导致复杂性增加并丧失清晰度：没有目的的概念会毫无必要地弄乱界面并使用户感到困惑；缺失的概念会导致用户使用更复杂的交互来绕过这个遗漏；冗余概念会在两个本应是同一事物的概念之间引入令人困惑的区别，并迫使用户学习做同一件事的不同方法；过载的概念会从无关目的的耦合中带来意想不到的复杂性。
• 不受欢迎的功能限制也经常因此产生。冗余通常是概念出现在专门的上下文中（可能由子团队完成）的一种症状，没有得到像对应用程序核心概念那样倾注的设计关注。过载会导致限制，因为第二个目的被强行塞进了现有概念这一削足适履的“普罗克汝斯忒斯之床”。
• 连贯性准则有助于确定被表达为多个部分的目的实际上是一个目的还是几个目的。它们包括：是否可能将其重新表述为单一目的；各部分是否有共同的利益相关者；它们是否服务于共同的使命；以及它们是否彼此冲突。

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

• 当你设计一个应用程序时，尽早问问自己是否存在一个你甚至都没有考虑过的本质目的。在分析用户的反馈时，考虑一下用户遇到的任何问题是否可能是由于遗漏了一个概念。
• 对你的每个概念进行成对比较，以确保没有冗余，并进行更深入地观察以发现是否存在可以提取为它们自身公共概念的、概念间的共享功能。
• 如果一个概念变得复杂，或者对用户来说似乎工作得不够直观和灵活，它可能就是过载了。使用第5章的目的准则尽可能准确地阐明一个目的；如果你只能将其表达为多个部分，请应用本章的连贯性准则来确定这些部分是否反映了截然不同的目的。
• 当你确定一个概念过载时，尝试将其拆分为更连贯的概念，每个概念都具有更引人注目和统一的目的。留意你在其他地方见过的标准概念；由熟悉概念组成的组合比单一、特立独行的概念更灵活、更强大。