【读书笔记】设计体系：数字产品设计的系统化方法 (1)

译者序言

• 设计实践的三层级
• 组件库
• 设计语言
• 设计体系

• 几个大厂的范例
• Apple的Human InterfaceGuidelines:https://developer.apple.com/design/human-interface-guidelines/
• Google的Material Design:https://material.io/
• Microsoft的Fluent DesignSystem:https://www.microsoft.com/design/fluent/
• Atlassian的设计体系：https://atlassian.design/
• IBM的Carbon设计体系：https://www.carbondesignsystem.com/
• 蚂蚁金服的Ant Design:https://ant.design/

第一章：设计体系

基础

• 定义：设计体系是为了实现数字产品的目的而组织起来的一套相互关联的模式和共享实践。
• 模式：指的是界面中那些重复的要素：用户流程、交互方式、按钮、文本框、图标、配色、排版、文案，等等。
• 实践：我们如何创建、捕获、共享和使用这些模式，尤其是在团队协作时做这些事情的方法。

• 关于模式（下文详述）
• 功能性模式（functional pattern）
• 感知性模式（perceptual pattern）

设计模式

• 概念：最早被最早是建筑师克里斯托弗·亚历山大（Christopher Alexander）提出
• “每种模式都描述了一个在我们的环境中反复出现的问题，以及该问题的解决方案的核心思想。”

• 大多数设计模式都已打造成型并为人所熟知。这些模式利用了人的心智模型，让设计可以被直观地理解。

• 一套相互关联的模式构成了产品界面的设计语言。
• 我们开始设计产品的时候，设计语言就出现了。
• 当你阐述你的设计语言时，需要确保它可操作、可重现。

• 功能性模式（functional pattern）
• 受产品所属的领域及其核心功能影响
• 表现为界面上的具体模块，如按钮、标题、表单元素、菜单等。
• “像名词和动词”

• 感知性模式（perceptual pattern）
• 塑造产品调性/精神的模式
• 描述性的样式，以可视化方式表达和呈现产品的个性，如文案语气，配色、排版、图标、间距与布局、特定的形状、交互、动画和声音等
• “类似于形容词”

• 其他类型的模式（不是本书重点讲的）
• 用户流程（例如包含错误提示和成功消息的表单的设计）
• 面向领域的设计模式（如教育科技系统的学习模式、电子商务模式等）
• 说服式用户体验模式

共享语言

• 相当于“大家都说一种语言”才能交流协作。

• 开始构建界面之前，就应该通过讨论、审议和记录语言决策等方式建立起一套共享的设计语言。

• “建立共享的词汇表”也是一种实践方式。

• 针对一个特定的元素/模块，参与产品创建的每一个人都应该知道
• 它的名称和目的是什么（What）
• 为什么会被设计成这样（Why）
• 应该如何使用它（How）
• 何时应该使用它（When）

模式库及其局限性

• 模式库不仅包含收集、存储和共享设计模式的工具，还包含相应的使用原则和操作指南。
• 模式库以前是静态的PDF文档或Wiki。
• 现在动态：它不仅包含设计模式，还包含用于构建它们的实际代码。

• 模式库的局限性
• 不能等同于设计体系。它只是有助于设计体系变得更加有效的一种工具。
• 模式库无法让糟糕的设计变好。模式可能本身就设计得不好、用得不对，或者与整体不协调。
• 构建动态模式库需要更好的协作。以及协作过程中大家如何迭代。
• 有时模式库也受到了批评，因为它扼杀了创造力，容易导致开发出外观千篇一律的网站。

构建有效的设计体系

• 共享目的
• 你的设计体系又是一个更大的体系——你的产品、你的团队、你的公司文化——的一部分。
• 弄清楚用户是谁，他们的目标、需求和动机是什么。
• 我们需要建立一些基本原则和价值观。
• 可以非正式地讨论，也可以写下来形成宣言。
• 重要的是参与产品创建的人都认同这些价值观，并承诺实践它们。
• 共享语言：术语的统一和共识

• 识别问题
• 行为和功能性模式：确定了希望用户实现或让用户有能力实现的主要行为
• 审美和感知性模式：用户使用的过程中是什么感受

第二章：设计原则

观点

• 对于原则到底是什么，也可能存在一些争议。有些公司的设计原则偏重于品牌，有的偏重于团队文化，有的则偏重于设计流程。
• Pinterest的设计原则便偏重于品牌（如“清晰易懂”“充满活力”“牢不可破”等）
• 英国政府数字服务小组制定的原则则偏重于团队的运作方式（如“精简”“重复再重复”等）

• 有时候，设计原则仅适用于有限的一段时期，或仅适用于特定的项目。

• Atlassian的例子：一开始市场营销和产品的原则不同，但后面逐渐融合。
• “这是一套统一的体系。设计原则将散落的点串联了起来。”——Jürgen Spangl, Atlassian公司设计负责人
• 目标是在客户可触及的每一点上都体现一些核心的价值观，比如“大胆”“乐观”“实用但不乏味”。

有效设计原则的特性

• 真实而贴切
• TED“追求永恒，而不是追求潮流”。

• 实用的、可操作的：反例 vs. 正面
• 简化 vs. 消除无用的部分
• 明确 vs. 第一优先级只有一个
• 简单 vs. 把界面做到牢不可破
• 有用 vs. 从需求开始

• 有观点的
• Salesforce公司的Lightning设计体系“清晰、高效、一致、美观”。该体系强调，这些原则的优先级必须遵从以上顺序。
• Medium的一个早期设计原则是“方向大于选择”。（文字的编辑器里需要这么多的字体选项吗？）

• 能产生共鸣、容易让人记住的
• Airbnb公司的四条设计原则
• “统一”“通用”“风格化的”“对话式的”
• 每当设计一个新的组件时，我们都会确保它完全满足四条原则。如果我们没有这一套原则，便很难就各种问题达成一致意见。我们希望保证界面里的每一小块都符合这些原则。”——Roy Stanfield, Airbnb首席交互设计师
• Spotify
• 缩写为TUNE
• tone（语调），usable（易用），necessary（必要），emotive（情感化）

定义原则

• 从目的开始
• TED网站的主要目的可以用一句话来表述：“尽可能广泛地传播演讲。”

• 寻找共识

• 面向正确的受众

• 对原则进行测试和修订

从原则到模式

• TED：信息的清晰比美观更重要
• Banner设计中要能容纳长标题。
• 对主页性能的不断优化：压缩图片等。

• Atlassian：“乐观”原则体现在“乐观的界面”中
• Jira从”进行中“到”完成“，虽然有大量校验工作，但是对看板拖动的顺滑要求也是”立即完成“

• 其它
• “透明、协作”的精神是如何融入到Slack的开放频道中去的
• “捕获生活中的精彩瞬间”的概念是如何体现在Instagram的照片提要和交互方式里的
• Trello的卡片（一种源自经典的HyperCard系统的功能）是如何促进特定类型的工作流的。

第三章：功能性模式

模式演变，行为不变

• FutureLearn的几次迭代，核心模块没变

定义功能性模式

• 创建模式映射
• FutureLearn来说，就是关注三个主要的方面：发现内容、学习课程、实现目标

• 打造界面清单
• Brad Frost提出的界面清单流程



• 这些组件形成了不同的分类——导航、表单、标签页、按钮、列表等。
• 通过这一过程，你能看出哪些模式是重复的，并发现需要留意的问题区域。
• 当你发现你有几十个页眉或弹出菜单，便会开始思考如何构建规范。
• 为了保持最佳效果，应该定期维护界面清单。

• 将模式视为操作
• 要理解一个模式的目的，需要关注它的作用是什么，而不是你认为它是什么。
• 要试着找到最能描述其行为的操作。用动词而非名词来描述模式，有助于扩展模式的潜在用例，并更准确地定义其用途。

• 描绘模式的内容结构
• 总结下来就是很多样式其实是跟着内容走的。
• 梳理内容的结构，其实是抓住了不变的东西。以下是”神“：



• 有了”神“以后，”形“其实可是多样化的

• 按某个维度排列模式
• 举例：广告位不同的效果程度，用”音量“大小来排列

• 将内容视为假设
• 我们设计的时候往往不从内容本身开始。不然容易陷入到内容本身的表达。
• 转变视角为从”目的“开始，即这些内容到底产生什么目的。

第四章：感知性模式

观点

• 数字产品感知性模式的例子包括语气、排版、配色、布局、插图与图标样式、形状与纹理、间距、意象、交互或动画，以及这些要素在界面中的组合和使用的具体方式。

• 有时，人们将这样的特性视为产品的样式，或称作皮肤，也就是最外面的一层。
• 但要想取得成效，它们必须不仅存在于表面，还必须存在于品牌的核心，并随着产品的发展而发展。

感知性模式的作用

• 有助于传递品牌形象
• Spotify的亲密氛围是一系列感知性模式（如微妙的交互、柔和的意象和着重呈现的颜色）结合在一起的结果



• Smashing杂志的个性是俏皮、富含创意、开放热情、稍微有些不同寻常。从排版上的处理，到倾斜的图像和图标



 

• 让系统更为连贯
• Vox和《卫报》
• 在Vox，醒目的图像上覆盖着大大的标题、清爽的字体和宽大的留白，传递出一种生活杂志的感觉——宽敞、非正式，甚至有些叛逆。
• 相比之下，《卫报》的排版、间距、图像和配色则营造出更密集、更可靠的感觉，这更适合于严肃的稿件。



• 对于Twitter来说，尽管它的Web应用、原生应用和第三方平台应用之间存在差异，但是像心形“Like”（喜欢）这样的交互细节是统一的，这有助于传播Twitter的模式语言。
 

探索感知性模式

• 功能性模块反映的是用户需要且想要的内容，感知性模式关注他们直观的感受或行为。

• 情绪板

• 样式叠片

• 元素拼贴

迭代与改进

• 平衡品牌性与一致性
• 如果一个设计体系过分追求完美的一致性，那么它就会变得普通、僵化。会扼杀品牌性。

• 标志性时刻
• 最小的细节也能体现感知性模式的存在
• “优雅的加载动画或吸引人的声音（‘你有新邮件了！'）”。如果标志性时刻是有含义的或者背后有故事的，它们就会显得尤其强大。
• 在TED网站上点击播放按钮时的涟漪效果（见图4-13），其灵感就来源于其视频介绍中标志性的水滴动画。

• 小规模试验

• 平衡品牌和业务需求

标志性模式：团队练习

• 不妨在团队中做一个快速练习：让每个人写下产品中最独特的感知性模式。
• 鼓励他们超越配色、字体这一层次，考虑更高级别的针对品牌的原则、组合和处理方式。
• 不仅要想到元素，还要考虑到它们背后的含义——它们描绘的图景和讲述的故事。

• 一个实例，FutureLearn
• 积极的、鼓励性的语气
• 主要用白色，并用粉红色强调
• 大面积的留白
• 通常用较大的字号，注重可读性
• 高对比的排版样式，标题用相对较大的字号
• 鲜艳的粉红色到蓝色的渐变
• 鼠标悬停时从粉红色到蓝色过渡的动画
• 1像素浅灰色的线
• 带有“断点”的1像素方形图标
• 主要用方形，偶尔在促销区域使用圆形和三角形

第5章：共享设计语言

为模式命名

• 学习为你的团队创造一个好名称
• 德国电信公司Sipgate的团队一开始使用了表现型的名称。但是他们发现，像“突出的Tile”[插图]或“带点的圆圈”这样的名称效果很差，最终导致他们的设计体系碎片化。
• 使用表现型的命名方式的主要问题是，当模式库里模式的数量增大之后，你就很难找到所需的内容。
• 在Atlassian，组件是从用户的角度命名的。
• 例如，“Lozenges”[插图]和“行内编辑框”这两个名称之所以这样命名，就是因为他们的用户是这样叫的。
• 起初，这样的命名是有争议的，有人认为这样做会对开发带来额外的负担。但该团队认为，以这种方式为模块命名，能让工程师也能站在用户的角度思考问题，并始终把用户放在心上。
• 在FutureLearn，我们认为，一个好名称必须是聚焦的、令人难忘的，能体现它所代表的模块的目的。
• 既有精确的描述性命名（如“进度转换按钮”）
• 也有有趣的命名（如“耳语框”）

• 好名称是基于隐喻的
• 在建筑领域，“支架”（Brackets）是对一种结构进行支撑和加固的东西，例如，有一种支架是用于支撑屋顶的。
• 类似地，在FutureLearn的界面中，“支架”是用于支持主要内容的小块辅助信息.
• 另一个例子是“聚光灯”（Spotlight），它指的是一种宣传元素，旨在吸引用户对特定内容的关注。

• 好名称有个性
• FutureLearn的界面上有些小的辅助性按钮，它们被称作“小黄人”
• 有小黄人的地方也应该有老板（Boss）。在FutureLearn，“老板”是一种大按钮的名称，这种按钮通常用于页面上主要的行动召唤
• 在CSS中看到．minion和．boss这样的类名也是很有意思的事情。

• 好名称能传达目的
• 例如：有很多个”小黄人“，只有一个”老板“

• 协同命名：团队多人一起参与进来。

• 建立专用频道
• 简述就是搞个公开文档/wiki，让大家随时能把取名的idea提出来。

• 跟用户一起测试设计语言

将团队融入设计语言

• 让设计模式变得可见
• 团队文化：让这些玩意儿在办公室，物料很多地方能看到。

• 引用事物的名称
• 所有语言的共同特点是，只有不停地使用才能让它保持活力。它需要成为日常对话的一部分。

• 将设计体系作为入职培训的一部分

• 定期组织设计体系会议

• 鼓励多样化协作

• 维护一份术语表

第6章：设计体系的参数

规则：严格或宽松

• Airbnb的“严格”
• 标准化的规范：例如，它严格地定义了排版处理，网格的间距是8像素，交互方式都有说明，关于命名也有一致的约定。
• 设计与工程完全同步
• 主Sketch文件里的设计模块与代码实现完全相同，并保持同步。
• Sketch文件里的名称与代码中的名称是匹配的。
• 所有模块都是跨平台的：Sketch文件中绘制的每一个组件，在iOS、Android、React Native和响应式Web库等平台中都有尽可能相似的实现。为此也做了Sketch的插件，叫DLS。
• 严格的引入新模式的流程
• 有专门的DLS团队维护组件。
• 新组件需要有提交，评审等严格流程。
• 全面详尽的文档
• 内部的DLS指南网站：一个Wiki
• 这个Wiki也做一个自动化的工具，组件更新时指南也更新。

• TED的“宽松”
• 部分原因是因为团队小：2个设计师，4个前端。
• “做正确的设计，而非一致的设计。优先考虑的应当是把页面本身做到最好。为此我们不断地改进页面，以期达到最佳效果。不应该用教条式的一致性和已有的模式去驱动设计决策。”——Michael McWatters, TED用户体验架构师
• 简单的草图胜过详尽的规格说明，简单的文档。

• 思考：哪些因素决定更偏向“严格“还是”宽松“
• 团队规模大小
• 效率问题以及业务对效率的追求，越”严格“时间成本越高
• 团队人员平均水平问题，越”宽松“对平均水平要求越高。

部件：模块化或集成化

• 模块化方法：类似打造积木，自由的拼积木
• 优点：敏捷，经济，易维护（一个模块不影响其它），适应性（各种组合满足不同需求），生成性（新的模式/组合方式带来创新）
• 缺点：建造耗时长不一定值得这个成本，为了通用性容易牺牲创造性和故事性，为了复用而复用不好，模块间一致性高≠整体体验一致性高
• 适用的产品特点：需要扩张和发展，用户需求多样化，需求本身有大量复用部件，需要让多个团队并行独立工作

• 集成化方法：也是拼积木，但是积木不太能互换，连接并不考虑适应不同方式
• 优点：针对性（特定内容等），连贯凝聚感，初始化更快（不用思考模块化里部件复用），易协调（团队目标一致）
• 缺点：可扩展性差，复用能力差
• 适用的产品特点：定制化设计，无需扩张改变，超越边界的艺术创作，几乎无共享模块，一次性（不太复用）

组织：集中式或分散式

• 集中式模型：专人专团队管理，典型公司：Apple，Airbnb
• 定义模式和规则
• 对设计体系的决策拥有否决权
• 管理模式库或其他存放模式的地方

• 分散式模型：几乎每个人都要负责维护
• 自主权高
• 一人漏掉，其它人也可以补位

• 问题
• 完全分散式的方法似乎在特定的团队文化下才能发挥作用

第7章：规划与实践

获得高层的支持

• 在设计和构建模块时能节省时间
• 在设计和构建模块时能节省时间

• 在做整站修改时能节省时间

• 能让产品更快上线

• 其它好处：品牌统一，视觉一致性，团队协作

从哪里开始

• 就目标达成一致
• 将界面系统化：定义设计指导原则 —— 定义并标准化设计模式 —— 建立模式库 —— 建立主设计文件 —— 重构代码和前端架构以支持
• 建立共享的流程和治理：建立知识共享的流程 ——在整个公司推广模式库 —— 面向所有部门推广共享的设计语言 —— 在入职培训中引入

• 将成果公开

• 创造知识共享的文化，例如
• 建立专门频道，让大家在这里定义设计模式并为其命名，讨论与设计体系有关的话题
• 创建一个模式墙，让设计体系的工作对公司其他人公开透明，并鼓励更多的人加入这项工作。
• 将设计体系的知识放入入职培训的内容。
• 组织例会，同步每个人的工作。

• 提升团队士气

第8章：功能性模式的系统化

目的导向的清单

• 先收集各种UI元素的屏幕截图，再根据外观的相似度对它们进行分组。

准备工作

• 安排时间：最有效的时间是在基础用户体验工作（包括用户研究、内容策略、信息架构及设计方向的确定）做完之后

• 选择人员：除了设计师，前端参加也重要。

• 打印界面
• 找最重要的界面。通常，10～12个界面就够了，有时甚至更少。
• 第一份按照典型用户轨迹的顺序贴在墙上，第二份则将用于剪切模式并对其进行分组。

确定关键行为

• 可以对”关键行为“先进行分类。

• 措辞是一项基础工作：行为要考虑和公司业务的关联性。

• 将行为分解为操作：具体化这些行为，概括用户做了什么操作

按目的对现有元素进行分组

定义模式

• 具体性尺度：具体的东西越多，可复用性就越差；但也反之。

• 内容结构：看起来就是整理一个好的思维框架把这些元素放进去？

• 命名

在更小的维度上重复目的导向的清单过程

• 如果有一些元素具有相似的目的，就需要将它们放在一起考虑，而不是分开处理。
• 按钮和链接有何不同？
• 标签页式的导航和列表式的菜单有何不同？
• 下拉列表和一组按钮有何不同？
• 复选框与切换按钮有何不同？

• 操作的一致性
• 例如按钮和链接：不同的设计体系有不同的处理方式
• 在IBM的Carbon设计体系中，链接是导航元素，按钮只能用于对数据有改动的用户操作。
• 在Shopify的Polaris设计体系中，按钮可以用来表现包括导航在内的任何类型的操作，链接既能用于嵌入式操作，也能用于导航。
• 最重要的是对目的的一致表述：如果按钮总是A事情，突然用来做B事情就会困惑。

• 视觉层次
• 例如：大多数界面都有主要按钮和辅助性按钮。
• 在Marvel的设计体系中，“扁平”按钮用于“必要的或强制的操作”，“幽灵”按钮用于“可选的、低频的或微小的操作”。如果两个“扁平”按钮对应的操作是同等重要的，那么这两个按钮可以并排在一起。
• 在Atlassian的设计体系和Shopify的Polaris设计体系中，主要按钮用来表示“所有体验中最重要的操作”，因此每个界面只能出现一次主要按钮。

• 特例
• 特例应该只能偶尔出现。它们拥有特殊的外观，也不能打破一般的模式规则。

第9章：感知性模式的系统化

超越样式属性

• 最明显的方法是使用属性值：颜色值、文本大小、长度等。

• 但是，仅仅把一组颜色值共享出来是不够的，还需要共享不同的环境下的颜色的用法。（明晰的使用指南）

美学特征与标志性模式

• 有效的样式不会流于表面，而会随着产品的发展而发展。

• 如果设计已经存在一段时间了，再去解析模式就不容易了。

• 标志性模式的创建：让团队里的每个人写下影响产品感观的最令人难忘、最独特的元素。
• 当人们想到你们的产品时，最先想到的样式是什么？
• 用户是如何评价你们产品的审美的？
• 在用户的反馈中，是否有一些经常提到的时刻？（例如“那个粉红色的对勾总能让我开心地笑起来”。）

• 不仅要考虑属性，还要考虑更高级别的原则、不同元素的组合以及它们之间的关系。
• 例如，不能简单地把颜色列出来，还要说明它们之间的比例：“主要是白色，辅以粉红色和蓝色点缀。”
• 还可以为模式配上典型示例。

• 团队成员一起寻找标志性模式，能为整个感知性模式的创建过程提供指导和灵感。

识别感知性模式

• 处理完标志性模式之后，就可以依次处理每一种样式了。样式的种类包括以下这些：
• 配色❑ 交互状态❑ 动画❑ 排版❑ 间距❑ 图标样式❑ 形状和边框❑ 插图❑ 照片❑ 语气和语调❑ 音效

• 用下面这些简单的步骤将其系统化
• 从目的开始。
• 收集现有元素并对它们进行分组。
• 定义模式和模块。
• 形成统一的指导原则。

• 很难一次性搞定，需要迭代；产生重复内容或重叠并不是坏事。

配色

• 从目的开始
• 对目的的表述不应该太模糊或者太空洞。
• 例如，颜色可以用于：
• 显示不同类型或不同层级的文本（正文、标题、块级引用等）
• 突出显示链接和操作（主要CTA、辅助性CTA、链接等）
• 提请注意消息，并区分不同类型的消息（确认、警告等）
• 将内容隔开，突出显示重点内容（通过背景、边框等）
• 区分不同类型的数据（图表、图形等）

• 收集现有颜色并分组
• 每个类别都有以下几列
• 类型：指定使用颜色对象的类型，如行动召唤、标题、反馈消息等。
• 示例：添加元素的屏幕截图，以显示颜色用在哪里。
• 值：指定十六进制的颜色值。
• 感觉：如果颜色的目的是创造某种情绪或感觉，请在此说明。



• 如果有能给产品带来特定情感属性的颜色，一定要多加留意。滥用颜色会削弱选择该颜色的初衷。

• 定义模式
• 根据颜色的目的（甚至感觉）来定义其用法的模式了，体现在
• 什么时候使用蓝色的链接，什么时候使用灰色的链接？
• 红色的行动召唤有什么含义？
• 为什么有些背景是灰色的，有些背景却是色彩鲜艳的？
• 黑色的标题和红色的标题有什么区别？
• 不必急着确定十六进制的颜色值，重要的是对界面上颜色的用法达成一致。
• 目的优先意味着有时需要改变颜色的用法
• 例如，如果你定义“所有红色是可点击的”。遇到过往设计一个不可点击的红色标题时，就要尝试去修改这个标题的颜色。

• 指定模块
• 增加配色的集中度、准确性和可访问性。
• 仅从需要的开始：尽量控制同类颜色的数量。如果过多，一个方法：
• 如果一种颜色有两种以上的变体，还可以先设置一个基准的颜色值，再为其他色调指定明暗度数值：比基准亮20%，比基准暗20%，等等。
• 确保颜色对比度的可访问性
• 检验：通过了WCAG 2.0标准，参考工具：Lea Verou做的Contrast Ratio
• 借助一些工具可以用来生成对比度合理的色彩组合

• 就指导原则达成一致
• 有些原则是比较通用的，例如“必须确保有可访问性的颜色对比度”
• 有些则是品牌特有的，例如
• Sky的Tookit设计体系：“我们用描述性的内容来定义实际用到的颜色。我们不会用颜色值来定义我们的网站或网站里的内容。”
• 牛津大学的样式指南：“牛津蓝（深色）主要用于页面的一般元素，例如页眉和页脚的背景。这让整个网站都呈现强烈的品牌感。但由于这些区域的品牌感如此强烈，因此不建议在其他地方大面积地使用该颜色。不过，它可以用于一些较小的元素，如活动日期图标、搜索框、筛选框等。”

动画

• 目的和感受
• 确定动画所承担的角色。举例
• 让交互状态之间的过渡变得轻柔，例如鼠标悬停时的动画。
• 对特定的内容或操作加以强调，例如鼓励用户前进到下一步。
• 隐藏或显示额外信息，例如隐藏在侧边的菜单、下拉菜单、弹窗等。
• 同时，也要评估“动画给人的感觉”。

• 评审现有动画
• 也是分组和评审，以下为示例：

• 定义模式

• 指定模块
• 动画有两个重要的概念：时长和过渡效果
• 对于时长，一个建议是可以先不要指定数值，而是一个基准值，基于基准值看如何提高/增量。

• 就指导原则达成一致
• 一般性原则，举例：“将动画用在交互中最重要的时刻”“别让动画妨碍任务的完成”
• 与团队实际情况相结合。举例：“保持动画简短、轻柔”

语气和语调

• 评审语气和语调的模式
• 一个方法：用情绪版（代表了什么情绪）先做分类。

• 定义模式
• 一般是举例“xx场景下，用xxx语言”

• 就指导原则达成一致
• Intuit的设计体系：不仅列出了处理语气和语调的原则（“引领”“简单”“有趣”），还解释了如何做到这些。
 

第10章：模式库

内容

• 团队里的每个人都可以访问这些内容，并对其进行审阅、编辑、提供反馈。

• 没有模式库之前，团队也肯定写过相关文档，这些文档就是模式库的草稿。基于这个草稿再延展会更容易。

模式的组织

• 提炼感知性模式
• 最简单的方法：将模式库分为组件和样式（即功能性模式和感知性模式）
• 不过不同团队的“叫法”有差异

• 组织功能性模式
• 可以按字母顺序、按层级、按类型（如导航、表单元素等）、按目的组织模块，也可以用其他完全不一样的方式。
• 按字母顺序排序：好处是不再需要对新增的顺序进行讨论，提升效率。
• 按层级进行组织：按复杂度进行分类
• 由Brad Frost开创的原子设计（atomic design）是做层级分类的一种流行方法



• 缺点是复杂度高，不太容易“开箱即用”。
• 按目的或按结构进行组织
• 如促销模块、鼓励学习者进步的模块、同用户沟通的模块、社交模块等
• Shopify Polaris中的组件是按结构和功能排列的

模式文档

• 为功能性模式编写文档
• 基础：名称，目的，示例（含视觉示例和代码示例），变体
• 名称
• 突出，能说明模式目的
• 区分性
• 目的
• 简单聚焦关键，1-2句就够。
• 例如，“事实网格（Fact Grid）是一种短小的列表，用于列出事实或其他一些有趣的信息。使用事实网格可以让访问者对即将看到的内容快速地建立印象。”
• 示例
• 举例：Marvel的样式指南



• 最好能为模式的示例配上代码，这样便能表现响应方式、交互方式和动画效果，从而以“活”的方式呈现模式。
• 变体
• 举例，Carbon
• 举例，Atlassian

• 其它重要的
• 组件的版本控制
• 团队成员列出来：主要是利于团队文化建设
• 相关模式：组件库大的时候，让用户很快能去看相关的。

• 为感知性模式编写文档
• 指定用法，而不仅是构件本身
• 举例：英国政府网站的样式指南说明了如何指定文本、链接、背景等元素的颜色



• “应该与不应该”（dos and don'ts）的格式也很有用
• “靛蓝（indigo）和蓝色（blue）都是用于交互元素的主要颜色。不应该将蓝色用于按钮。”
• 交叉引用样式
• 在Carbon中，模块的样式（如颜色）显示在单独的标签页里。同时，颜色的用法也在单独的标签页里



• 和交互状态也可能需要交叉引用



• 显示元素之间的关系
• 颜色之间的关系：例如，如果在TED网站上使用太多的红色或太少的红色，都会让人感觉这不是TED
• 排版和间距之间的关系：例如，字号大、对比强烈的排版便需要更多的留白
• 语气语调与视觉效果之间的关系

工作流程

• 添加新模式的过程
• 工作流的标准化
• 举例：Nordnet团队遵循一个简单的三步法
• 将设计稿提交到Dropbox（云盘）里的“UI工具箱”文件夹。
• 整个团队一起用Trello（看板）讨论新模式的引入。
• 对UI工具箱里的设计编写说明。将新设计放入模式库之后，它将自动推送到团队所有人前面。

• 引入新模式的标准
• 方法1：网站上的每个新元素都会自动地添加到模式库里
• 应该有一个流程来检查相似的模式是否已经存在，或者是否有可以修改的现成模式。
• 可以在团队范围定期对新模式进行评审。如果没有，这种方法就有产生重复模式的风险。
• 方法2：只有当元素被复用时，才会被添加到模式库里
• 往往第二次，第三次使用的时候才有人提出。提出需要有机制，以及没有引入前有地方注释。
• 定期评审，从“可复用性”的角度评估。

• 人员与责任
• 每个人都贡献 vs. 专人专团队搞，需要结合团队实际情况。
• 不可或缺的职责：审校者，制作者

• 统一设计体系的各个方面
• 代码、设计和模式库是设计体系的不同方面
• 一些好的团队实践会尽量让这几个方面同步

工具

• 保持模式库的更新
• 容易实现的是CSS文档解析器，如KSS
• 更为强大的工具是样式指南生成器，如Brad Frost、DaveOlsen和Brian Muenzenmeyer制作的Pattern Lab
• Mark Perkins的Fractal则是一种灵活的轻量级工具。

• 保持主设计文件的更新（作者更多还是结合Sketch的推荐）
• Abstract是设计文件的版本控制中心
• Invision的Craft
• 更为全面的工具，如UXPin、Brand.ai、Lingo等

• 将模式库作为求真来源
• 设计师将模式库作为最新模式的主要参考来源，而Sketch或Photoshop则主要用于探索性工作。

模式库的未来

• 未来的模式库可以适应跨领域的工作流程。

• 效率更高：几小时的工作变成几分钟。