《设计体系》第八章 功能性设计模式的体系化

译者声明 ：

原书 Design Systems 由 Smashing Magazine 出版，作者 Alla Kholmatova。C译版《设计体系》是个人自发项目，并非官方引进版本；译者 C7210，发布于 Beforweb，仅用于知识交流，不涉及任何商业或盈利目的；译文禁止转载，禁止任何以商业或盈利为目的的传播形式。

你可以在 Smashing Magazine 购买到纸质或电子版英文原书。如果你喜欢C译版，可以通过文末的“ 喜欢作者 ”为我提供咖啡支援，随缘。

查看关于C译版《设计体系》的更多信息 。

Prev： 第七章 前期规划与实践起步

第八章 功能性设计模式的体系化

约8060字

本章介绍的实践方法将帮你了解如何从产品目标分析开始对功能性设计模式进行体系化定义。

我生活的地方有个小书店。一进门，你就会看到一排排的书封，有些上面还有手写文字 - 这是来自于真实读者的评语。即便不知道自己想要读什么，你也有可能被这些评语吸引；当你真的产生了兴趣，还可以到店内一个安静的小角落窝在沙发里边喝咖啡边读，买不买都无妨。这个书店的特质就在于"发现"与"阅读"，售卖反而成为了其次；它所蕴含的模式，包括手写评语、安静的角落、沙发和咖啡桌都体现着其整体特质。

与此相仿，我们在数字化产品当中也会通过设计模式来鼓励和引导用户执行特定的行为。想想看 Slack 是如何实现的那些沟通效率远超邮件与 IM 软件的协作方式的，又或是 Tinder 是如何通过轻扫手势来鼓励随机的、无承诺的社交关系的。或许很多产品是都围绕着相似的用户目标及需求来设计的，但它们藉由设计模式来鼓励的行为却可能存在着很大差异。因此， 当我们在思考模式与产品目标及设计意图之间的关联时，必须要考虑到特定的产品所鼓励的关键行为是怎样的 。

设计意图可以通过诸多方式体现，包括实体与环境（书店）、语音朗读等等，而不局限于可视化的操作界面。可以清晰体现关键行为的设计模式更具健壮性和持久性。

目标导向的界面清查

界面清查是体系化定义工作的起点，大致包括界面元素的汇总及分组归类等典型步骤。

概念很简单，但实际执行方式却多种多样。很多团队会聚焦于视觉一致性的角度，将元素按照类型分组，尝试发现冗余样式；而本章介绍的方法旨在对设计模式的本质进行定义，使团队对于设计模式的运用方式产生共识。

完成界面清查之后，你将得到一份清单，为你指出有哪些元素需要进行标准化重构或是值得关注；此外你还能通过草图将接下来定义具体设计模式的方式梳理清楚。

我们会从" 目标 "（行为）的维度对界面元素进行归类，而非按照元素类型（按钮、tab、下拉菜单）进行分组。

因为我们更希望 首先理解设计模式的目标及运用方式 ，而非它们是否应该拥有相同的外观。我们需要首先理解何时使用特定类型的按钮，何时应该使用链接而非按钮，何时避免使用按钮而引导用户直接与内容对象进行交互。当然，在整个过程中，我们也不会忽略一致性的改进，只是关注的重点需要明确。

界面清查的准备工作

时机

在界面清查之前，团队对于现有产品应该进行过必要的用户体验研究工作，包括内容策略、信息架构、可用性等方面，确保现有的设计当中没有本质性的缺陷或明显的可用性问题，避免设计体系相关工作被历史的或现有的重大问题影响。同理，如果你们的产品将要进行大规模的改版，那么前期的目标与方向探索工作也要先于界面清查来进行。

团队

团队初期的规模控制在4到8人会比较理想。人员构成包括设计师与前端工程师；如果有后端开发人员、内容生产者或产品经理能够参与则更加理想。如果原本规模较大的团队需要继续扩张，同样可以考虑来自不同职能部门的新鲜力量。

打印页面

识别产品 核心行为路径 所涉及到的那些关键页面，那些对于产品来说 绝对需要、无可替代 的页面；具体数量取决于不同类型的产品，通常10到12个即可，有时甚至更少。你可以使用 mock-up，或是在现有产品页面里截图。

假设你们正在为公共图书馆设计网站，其目标是扩展实体图书馆的体验，譬如通过提供在线预约功能来避免排队和资料填写等繁琐流程。与该目标最为相关的页面所涵盖到的关键行为大致包括查找特定的图书、发现新书、预约、下载相关资料等等。当然，一个图书馆网站通常还会包括其他一些内容，譬如展会或活动信息、会员体系、线上收藏等等。对于这些关键路径以外的页面，我们可以记录下来，但无需囊括到初期的页面清查工作当中。

接下来每个页面打印一式两份，其中一张贴在墙上，用于演示用户历程；另外一张用来裁剪组件并归类粘贴。在界面清查期间，我们时常需要在整体与局部之间切换视野；而两份打印稿可以帮助我们同时关注到这两方面，在思考特定模式的时候不会失去页面情境感。

当然，期间你还需要剪刀、记号笔、便利贴等工具，以及足够大的墙面与工作台。

第一步：识别关键行为

首先，我们需要从用户历程的每个阶段当中识别出最为关键的用户需求与对应的行为。对于仅由少量页面构成的小 app 来说，你可以聚焦于每个界面，包括其可能拥有的各种状态；而对于较大的产品，我们需要首先将界面按照用户历程的不同阶段进行分组。

回到公众图书馆的例子，我们可能要基于下述关键行为将页面分组：

• 发现 ：鼓励人们发现他们可能感兴趣的书籍。类比于实体书店，这部分相当于“员工推荐”或“热门新书”货架。对于没有明确阅读目标的用户，这部分内容或许可以激发他们的兴趣。

• 寻找 ：寻找特定的书籍。用户通过分类来定位特定的书籍，好像在实体书店中向店员寻求帮助。

• 愿望清单 ：帮助人们管理他们的备选书籍。在实体书店中，这相当于人们将有兴趣的书汇总在一起，稍后决定购买哪些。

如果你发现某些页面当中同时存在多种关键行为，譬如一边鼓励用户发现新书，一边引导他们下载资讯、注册订阅或是浏览近期事件等等，那么要将这些页面标注下来。即便有些页面必须同时支持多种行为，其中权重最高的那一个也必须是最为清晰和突显的，不可以混淆与其他；识别这类最为关键的行为并将其作为页面的分组依据。

选择恰当的用词

用于描述关键行为的用词很关键，甚至会影响我们的思维方式。在 FutureLearn，曾经有一段时间，我们会将“留存率”作为一项重要的产品指标，意在使越来越多的用户在开始课程之后能够继续保持学习。以此为目标进行设计并非易事，因为我们搞不清楚所谓“留存”对用户来说究竟有怎样的益处。如果我们 将“留存”的说法换成“参与”，或是将考量指标由对停留时长的关注转变为对学习效果及满意度的关注 ，那么很多设计策略或许会大为不同。

对于行为的描述方式应该 聚焦于用户的角度，而非单纯出于产品或业务目标 ；“推广”的概念仅对产品有意义，“发现”才能体现用户目标。用词的选择体现着设计策略，能间接决定着产品以怎样的方式呈现怎样的内容。

解构关键行为

我们还需要对识别出的关键行为进行解构，将它们分解为更具体的任务，用便利贴标注在打印稿的旁边。例如，对于"发现"行为来说，涉及如下任务：

• 浏览书籍列表

• 在书籍列表中进行筛选

• 控制书籍列表的呈现模式

• 查看书籍信息

• 将书放入愿望清单

• 预约借阅

你可能会发现界面里有些任务从本质上讲是具有重复性的，即便表现形式不同。例如 tab 导航或类别菜单都可以筛选功能。通过界面清查与行为解构，类似的不一致性问题会比较充分地暴露出来。

第二步：按照目标将元素归类

每次聚焦于一个特定的目标任务，将所有页面当中用于执行该任务的元素归为一类。以"查看书籍信息"为例，可能会涉及到搜索结果页、愿望清单页和推广页等等。

将相关元素从第二份打印稿当中裁剪下来，逐一贴在墙上，然后用一张便利贴标注这个分类的名称，例如"查看书籍信息"、"筛选列表"等等。这些元素都将成为我们接下来定义功能性设计模式的备选。要确保元素颗粒度的一致，譬如避免在同一个分组当中出现书籍列表与借阅按钮这样颗粒度完全不同的元素。

第三步：定义设计模式

完成了元素的归类分组之后，我们还需要考虑具体的模块化策略，例如是否需要将某些元素整合为同一个模式，还是保持单独定义会更为合理。对于不同的产品，判断标准也有所不同；这里给到两个较为通用的思路。

1.考量特定化程度

同一类元素，既可以被定义为高度特立的模式，也可以被定义为较为通用的模式。例如我们需要在图书馆网站中展示近期的活动信息与展会信息。如果针对这两类信息分别定义各自的呈现模式，那么每一个都可以是高度特定化的。另一方面，如果将它们整合在一起，统称"内容模块"，那么这个模式就必须具备更高的通用性，以便承载不同类型的内容。

这个概念听上去是显而易见的，但 关于模式特定化程度的决策其实是模块化设计当中最为棘手的问题之一 。模式的特定化程度越高，其复用性就越低；反之亦然。此外，一个体系当中包含的高度特定化的模式越多，其整体的维护难度就越高，一致性也更加难以保障；而过多的通用化模式又会导致较弱的设计独特性。

这里没有所谓的"正确答案"，具体的策略永远取决于我们希望达到的目标。我们是否希望用户以更独特的方式对展会信息产生感知？活动信息与展会信息当中是否存在某些会引发设计方案冲突的元素？如果答案是肯定的，那么我们就需要单独为它们进行定义。例如：

• 展会信息或许需要围绕着艺术品的图片进行设计。展会的独特性或许需要某种订制化的标题来进行辅助说明，并与图片搭配形成明信片的效果；而日期信息可以相对弱化，避免对重点信息造成干扰。

• 活动信息可以更加简练，譬如仅通过图标和日期信息来进行传达。

另一方面，如果没有足够的必要去区分不同类型的内容，我们便可以将它们整合为同一种模式。这种模式具有更强的适应性，可以同时用于多种信息的呈现；但其灵活性较弱，任何样式迭代都会同时作用于多种类型当中。

2.梳理信息架构

我们曾在第三章当中介绍过如何对功能性设计模式进行信息架构梳理；这里稍作回顾：

1. 判断并提取某个模块当中最为核心的内容元素。图片是否会对模块的功能造成影响，是否会直接影响到设计目标的实现？某个文本标签是否是必需的？将那些非必要的元素标注出来。

2. 判断核心内容元素的层级关系，进行必要的分组；譬如图标属于关键信息的组成部分，还是属于图形类内容。

3. 通过草图将信息架构抽象地呈现出来。

通常，对于底层内容架构相同的模块，我们可以将它们整合为同一种设计模式。另一方面，如果你发现难以在不影响其目标实现的基础之上将若干模块进行整合，那么它们便不应该被整合。

此外，某些模块可能有着相同的信息架构，但出于设计意图或具体页面情境的考虑，它们需要拥有独特的外观样式或行为方式。在这种情况下， 我们可以将其视为相同设计模式的不同变体，而不是一一创建不同的模式 。

仍以图书馆网站为例。假设我们将以下界面元素划分到了"查看书籍信息"分类当中。

其中 A 与 B 都被用于构建书籍列表，目标是帮助人们了解书籍的更多信息；它们还有着相同的信息架构：

虽然 B 当中没有封面图片及相关操作，但鉴于其所处的页面环境（愿望清单），缩略图并非必需，相关操作也可以在页面中统一执行。

再来看 D 和 E。它们的目标都是通过书籍封面强化推荐效应，吸引用户关注；它们的信息架构如下：

D 更加独立，用于在发现页中代表一本书籍；为了实现吸引关注的目标，D 或许需要涉及更多的动效及样式表现能力。而 E 则是标准书籍列表中的一个缩略图元素。对于这两者，我们或许有必要区别对待。

而 C 与 A、B有着相似的信息架构。但相比于后两者所处的列表环境，C 的目标是在详情页以更为详实的方式呈现信息。因此我们可以将其视为"书籍单元"的变体与扩展。

我们在模式的默认状态当中定义其核心内容及样式，通过变体状态提供额外定义。需要判断哪些信息属于核心，哪些属于扩展部分。

以上这些同属于"查看书籍信息"的模块，它们之间的差异感在很大程度上是由于某些关键信息的样式区别所造成的，例如：

• 标题字号

• 缩略图尺寸

• 布局规格

改变内容不会对模块造成影响，而改变内容样式则可能带来新的变体。

通过考量信息架构与风格样式之间的关联性，你可以判断能否通过扩展变体来提升某些基础模式的复用性，而无需针对任何样式单独定义一种模式。

第四步：为设计模式命名

正如我们在 第五章 （协作语言）当中所了解的，命名方式会影响到设计模式的使用方式。合理的命名方式是设计体系及设计协作得以良好运作的重要基础。

试着在命名中体现设计模式的特定化程度；如果难以把握，则尽可能为其赋予一个高度特定化的名称。譬如在 FutureLearn，我们习惯于将"学习进度"看作一套特定而独立的模式，其中包含了一系列高度特定化的模块。

这种情况下，将其中的 tab 命名为"课程 tab"是合理的，因为我们那时没打算在任何其他页面环境中进行复用。这一名称也可以让团队所有人了解它的特定用途。而随着产品的发展，我们开始需要在其他地方用到这一模式了，因此我们也将其名称改为"页面导航 tab"。新的名称更具通用性，其他人也因此而了解到它的用途范围开始扩大。

在很多团队，模式命名都是由工程师在前端开发过程中顺带完成的。然而这实际上是一项设计工作，需要在设计阶段由多方面协作完成。命名需要考虑到内容类型，但也不能被特定的内容类型所限。良好的命名方式体现着合理的复用性，并能充分体现其使用方式。

重复上述步骤，逐步降低颗粒度

上述步骤所针对的是那些构成了关键行为的若干具体任务。接下来，我们可以继续重复这些步骤，对其他关键行为中的任务进行模块化定义；同时我们还要逐步降低颗粒度，深入到更基础的一类元素当中，例如：

• 按钮和链接

• 页头

• 列表

• tab 和菜单

• 单选按钮、切换按钮、复选框

• 反馈信息

• 导航

• 图片

• 图标

如果某些元素有着类似的设计目标，那么可以试着将它们归为一类，而非单独定义。按钮与链接，tab 导航与列表菜单，下拉菜单与一系列按钮，复选框与切换按钮，这些元素之间有着怎样的本质区别？目标是否一致？

以按钮与链接为例，我们可以从以下几个方面来判断这些元素的异同：

行为一致性

在较为传统的网页设计开发当中，链接和按钮通常有着明显的区别。链接用来将用户导航至另外一个页面，而按钮通常用来提交用户行为或是触发当前页面中的某些状态变化。但在实际当中，这些还不足以成为设计决策的依据。

试想书籍信息模块当中包含一个"查看详情"按钮，点击之后，该模块会展开，进而呈现出更多的详细信息。如果这些详细信息位于另一个单独的页面，而非隐藏在当前模块当中，那这是否意味着"查看详情"应该以链接而非按钮的形式来呈现呢？

造成困惑的本质原因在于概念的定义。有些人（很多时候特指工程师）习惯于将按钮定义为"用于提交数据的触发元素"，因此不会考虑将其用于这种定义之外的行为，他们也不会将拥有按钮样式的链接元素看作真正的按钮。而另一些人（很多时候特指设计师）会将按钮视为特定而独立的行为召唤元素，无论其实现代码究竟是按钮元素还是链接元素。

不同的设计体系对于这两类元素的定义方式也有所差异。在 IBM 的 Carbon 体系中，链接被定义为一种导航元素，而按钮仅用于那些涉及到数据变化的行为。而在 Shopify 的 Polaris 体系中，按钮可以被用于任何行为，包括导航；而链接可以被用于导航，也可以用于局部的、内嵌式的功能行为。

在我看来， 无论如何定义，最关键的还是在于清晰一致的诠释方式 。用户在使用界面时需要对元素的功能及行为结果产生正确而一致的预期。如果你们始终通过按钮来实现数据提交方面的功能，那么一旦某个按钮突然开始拥有链接元素的行为特征，用户的预期便会被打破，心智模型开始失效。

为避免对于元素的误解和误用，团队内部对于其定义和目标必须达成一致。"按钮"和"链接"对于你的团队而言意味着什么？在使用方式上是否有着最基本的定义？

Heydon Pickering 在其 Inclusive Design Patterns 一书当中所进行的描述是我所见过的最为简单有效的。他认为真正的区别存在于链接与行为召唤之间，而非链接与"按钮"之间。一个重要的功能行为可以通过"按钮"的形式来体现，无论其在实际代码中究竟是"链接"还是"按钮"；而我们更需要关注的是这个元素是否具备行为召唤的特质，还是在于将用户带离当前页面。