Design systems

翻译by Beforweb

前言

第一部分 设计体系的基础构成

“设计模式”
“实践方法”

第二部分 如何构建设计体系

第一章 设计体系

设计模式受什么因素影响？
由产品核心功能及所在领域决定设计模式→功能性模式
产品的气质（品牌形象）→感知性模式
产品所在平台（桌面端，移动端，iOS，安卓）

• 设计模式

  • 概念提出：建筑设计师Christopher Alexander “每种设计模式都针对某个在我们的环境当中反复发生的问题进行了描述，并提供了相应的解决方案。” 《建筑模式语言》
  • 模式的好处
    • 多数模式是历经验证且为人所熟知的。符合用户的心智模型
    • 其复用能力可以避免过多聚焦于设计模式本身，从而集中精力用于思考需求
    • 有助于体系化地控制整个产品的设计方案：小的调整→可应用于全局
  • 案例：Tom Osborne的“视觉音量规范”

• 工作语言

  • 团队内部需要统一名称和使用方式
  • 让系统模式（界面）与用户心智模型统一
• 设计模式库及其局限性
  • 创建、提炼、共享、迭代设计模式的方法技术：模式库
  • 静态文档较难维护更新
  • 包含设计模式与真实代码的动态模式库→产品工作模式
  • 设计模式库不等于设计体系。只是用于构造高效设计体系的工具之一
  • 设计模式库无法保证设计产出的质量
  • 设计模式库无法修复坏的设计：模式本身的设计可能存在问题；模式可能被误用或以不恰当的方式组合
  • 协作是动态模式库的基石
  • 模式库反映的是整个设计体系的风格，未必会“束缚创意”
  • 发挥模式库、组件库的作用，需要与实践方法整合统一
• 如何定义设计体系的有效性
  • 观察各个组成部分能否有效协同促进产品目标的实现
  • 增加设计流程中的成本效益，同时有助于产品使用效率、满意度和整体体验的提升
  • 具体要素
    • 统一目标
      • 子系统之间高度关联且目标一致
    • 识别问题
      • 松散混乱的设计体系
  • 范例：十分钟食谱网站
    • 产品的目标与价值：一句话概括
    • 设计原则：团队全员认同并理解
    • 关键行为与功能性设计模式
    • 视觉样式与感知性设计模式
    • 工作语言：从初期的非正式定义到结构化的规范

第二章 设计原则

确立基础设计原则能够帮助将产品目标落实于设计方案。
不过在产品项目早期，难以清晰定义设计原则。
设计原则可能用于特定项目，或贯穿整个公司业务。

有效的设计原则需要具备哪些特质？

1. 详实可考 - 避免诠释方式过于泛化的普遍性原则（简单，有用，令人愉悦……）
2. 切实可行 - 能提供可行性建议（搭配实例进行诠释是必要的）
3. 观点明确 - 权衡要素的优先级

4. 易懂易记 - 团队里的同事清楚设计原则吗？（控制数量在三到五个；反复运用与交流）

   
   如何定义设计原则？

• 以目标为始
• 寻求多方意见
• 聚焦于目标受众

• 测试与迭代

  
  从设计原则到设计模式
  设计模式的选择及运用方式，包括它们独特的组合方式，都会受到产品目标、特质及设计原则的影响。
  设计原则→语法
  设计模式→单词
  

  第三章 功能性设计模式

  功能性设计模式是产品界面的实体化组成要素，存在目的通常是帮助用户完成特定的操作行为。
  功能性设计模式可以是简单而独立的，也可以被组合成为更加复杂的模式。
  功能型设计模式会随着产品的发展而扩充或调整。
  在项目早期对最为核心的功能型设计模式进行定义，会有助于后续设计流程的统一性。
  

  关键行为与功能性设计模式

  设计模式是界面行为逻辑的具像化体现，其外观及交互层面的特征无需一成不变（功能性设计模式甚至无需可视化，例如语音交互），只要它们所承载的产品目标及关键行为是相对稳定的；关键还是要确保设计模式在逻辑层面符合产品目标。因此在早期尽可能对核心设计模式进行定义还是利大于弊的。
  

  如何定义功能性设计模式

• 创建设计模式地图

  • 早期的方向探索/原型设计：用户体验地图，JTBD (Jobs to be Done)
  • 实际界面设计阶段：融合设计模式到整个产品图景当中
    • 聚焦于大的图景，分辨整个系统的若干关键组成部分，识别每个部分当中包含哪些典型的设计模式
    • “在用户历程的这个特定阶段里，我们希望用户执行怎样的行为？有哪些设计模式是用于支援这些行为的？整个产品里还有哪些地方用到了这些模式？如果这是一个我们未曾使用过的模式，那么它还能在哪些其他地方被用到？”
• 开展界面清查
  • “界面清查”概念：由Brad Frost在《原子化设计理论》中提出
  • 汇总所有典型界面，将不同类别的组件元素截取出来，分类呈现
  • 无需涉及所有界面元素（除了第一次）；应规律性进行（每隔几个月进行一次）
• 从“行为”的角度理解设计模式
  • “它用来做什么？”而非“它是什么”

• 梳理信息架构

  • 提取设计模式的组成要素及关键内容类型，梳理出信息架构，在团队内部达成统一认知
  • 判断元素的层级关系，进行必要的分组

• 衡量模式的权重

  • 帮助设计师在不同的需求情境当中选择最为恰当的设计模式；避免不必要的重复定义
  • Scream>Cheer>Wisper
  • “假想界面并非可视化，而是需要通过语言来传达信息，那么有哪些地方需要朗读者提高音量或改变语调？”
• 将内容作为变量
  • 用符合设计模式目标定义的内容对该模式进行测试。若结果不理解，原因可能有：
    • 对设计模式的目标定义有误。尝试回到设计目标与关键行为的层面重新审视。
    • 我们对设计模式本身的实现方式定义有误。尝试针对可预计的内容重新设计该模式。
    • 该设计模式并不适于承载可预计的内容。尝试修改内容或选择其他设计模式。
  • 理解功能型模式与设计目标、关键行为之间的重要关联！

第四章 感知性设计模式

产品界面设计中的感知性设计模式大致包括：话术气质、字体、配色、图片与图形风格、空间与布局、特定的形状、交互感知、动效、音效，以及所有对这些要素进行组合运用的特定方法。

感知性模式有助于品牌特质的体现
风格元素逐渐构成界面的感知性设计模式。配色、字体等风格要素彼此间的关联逻辑也会对“感知”构成影响（比例关系、搭配方式）。

感知性模式将局部连接为整体
串联各个模块…………

探索感知性设计模式

功能性与感知性的特点：

• 功能性：反映用户的目标与诉求；要求对目标与行为进行分析
• 感知性：聚焦用户的感受与体验；要求关注产品体现出的人格特质和整体氛围

常用的探索感知性模式的方法：

• 情绪板 Mood Boards
• 风格磁贴 Style Tiles （由一些关键字体、配色及界面元素的基础定义所组成的设计产出物）
• 元素拼贴 Element Collages （将若干界面元素汇集在一处，集中探索品牌风格在实际界面中的传达效果。聚焦于实体元素）

迭代与精进

收敛，持续进行细化和精炼，使感知性模式与功能型模式逐渐融合如一。

在品牌风格与一致性之间寻求平衡
避免追求极致的一致性，可能导致平淡僵化的产品气质。应鼓励设计师在正确的方向上进行探索。

关于“标志性时刻”(Signature Moments)
概念：足以成为产品差异化标志的细节设计模式 （Dan Saffer, 微交互 microinteractions）

小规模测试
以最小化的方式进行新风格尝试，明确探索的目标是什么。如果新风格被证明在局部有效，接下来也要谨慎地逐渐进行推广，期间明确其作用范围。

在品牌风格与业务需求之间寻求平衡
保持敏感，避免体系外的元素泛滥

团队练习：识别标志性设计模式

让每个人将他们认为最能体现产品差异性的感知性设计模式记录下来。也可以超越具体的元素和模式，从设计原则层面来挖掘品牌的差异化特质。对于具体的设计模式，还应考虑其蕴含的意义，它们共同描绘的图景或背后的故事。

第五章 协作语言

在团队规模扩大的状况下保持产品设计的整体性与一致性：所有人必须以相同的方式理解设计原则、品牌愿景、产品目标及信息架构，必须对设计模式的特质及使用方式形成共识。

设计模式的命名方式

探索最适合团队的命名方式

基于样式的命名方式难以被复用或扩展，对设计模式的目标用途不具备指导性和启发性。
Atlassian团队站在用户的角度对组件进行命名。
FutureLearn认为，好的命名方式意味着高度聚焦，易于记忆，并能体现设计模式的目标用途，必须令设计师明白其所指，进而意图明确地进行使用。

好名字是基于隐喻的

“斗拱”：用于支撑和强化建筑结构 - 通过辅助信息来支撑和强化主要内容的设计模式
“聚光灯”：将用户注意力吸引到特定内容的推广位设计模式
“进度切换按钮”“二元单选按钮”：无法形成易于记忆的具象，设计师在需要时很可能创建类似的新模式而不是进行复用

好名字是有个性的

较小的次级功能按钮 - Minions（小黄人）
硕大的行为召唤主按钮 - Boss （老板）

好名字可以体现目标用途

模式名称本身具有自解释性。
恰当的隐喻与个性化都是能够帮助解决命名难题的有效方式；承载着目标用途的名字是保险的解决方案。

团队协作

通过团队协作来推动命名规范。不同工种的人看待问题的角度也有所不同。
协作也有利于非设计职能的员工了解设计模式的用途。

建设贡献渠道

比如在Slack新建一个“设计体系”频道。

通过用户测试命名方式的有效性

将界面组件打印在纸片上，被试检视卡片并进行归类。与相关用研方法的区别：用研方法注重考量线性任务和脚本的完成状况。
保持聚焦，切勿陷入无止境的讨论。

在团队内部推广协作语言

命名规范的可视化

“模式墙”：有助于全团队对设计模式和协作语言规范进行全局化的纵览。
可以将最核心、常用的模式打印在A3纸上，标注清楚命名。可参考第三章的“设计模式地图”，按照用户历程的不同阶段分组放置。
还可以用在线协作工具创建自动化的备忘提醒。

日常用语的标准化

在日常对话中使用，培养标准化的语言习惯

纳入新人培训流程

定期同步

鼓励跨职能合作

之前章节介绍过的协作模式：

• 创建模式地图
• 开展界面清查
• 梳理信息架构
• 协作命名
• 识别标志性模式
• 小规模测试

编写词汇表

提供参考，在团队范围内形成审查、讨论、确立协作语言的工作习惯与氛围

第六章 设计体系的特质参量

设计体系并非以模式库的构建为始、为终，其背后有着一系列的影响要素，包括团队组织架构、团队文化、产品类型、设计流程等等。

• 实践规则（严格、松散）- Rules (strict - loose)
• 构造方式（模块化、整合化） - parts (modular - integrated)
• 管理机制（集中式、分布式）- organisation (centraised - distributed)

实践规则：严格或松散

案例1 Airbnb

标准化规范
Design Language System团队对设计模式进行了精确、全面的定义（包含字号规则、8像素栅格体系的运用、细节交互模式、元素命名方式等）。

设计与开发的精准同步

• sketch主文件里每一个设计模式都有前端代码与之精准对应，并始终保持同步
• 设计模式的命名在sketch主文件及前端代码当中保持一致
• 所有设计模式都提供多平台方案，包括iOS,安卓，React Native和响应式页面等

• 同步机制在团队中有很高的优先级

  
  严格的新模式入库流程
  DLS团队希望模式的复用率可以达到90%以上，并尽可能降低新模式的创建频率。

1. 设计师需要通过一份 Sketch 模版来提议新模式；其中包括设计方案本身，以及对于设计目标、行为规则的描述，同时还需要附带使用情境范例以及命名建议。
2. 提议经由 JIRA 系统发送给设计支援团队。很多时候，支援团队会发现库中已经存在类似的模式，于是驳回提议，或是根据特定的情况建议升级现有模式。

3. 通过审核的提议会被发送到 DLS 团队，并由他们来判断新模式的需求和目标是否足够明确，是否能切实解决设计问题。如果答案是肯定的，他们会按照提议创建新模式，或进行适度优化，确保其符合体系特质。

   
   详实全面的设计文档
   DLS的设计文档基于sketch主文件生成，存放于内网。工具团队开发了一套自动化流程，用于从sketch主文件中获取组件的截屏及元数据，自动发布上线。线上文档也与Sketch主文件、前端代码保持同步。
   

   案例2 TED

   团队规模小。设计体系的建立方式比较松散，其中关于品牌感知与页面性能的内容在权重上超过了视觉表现一致性方面的定义。
   
   草图示意
   多数时候使用白板或低保真草图来呈现规范及设计方案。
   
   简化的文档
   没有真正意义上的设计模式库；一套承载着若干关键设计元素的网页及sketch文件。
   
   “对于页面情境的洞察力与敏锐度仍是最重要的，即便这意味着必须对标准化的设计模式进行突破或改造” - Michael McWatters
   
   深刻的共识是确保设计体系行之有效的根基，即便这个体系很松散。
   
   了解利弊，选择方向—-
   通常，严格型体系有助于设计方案的精准度和一致性，但同时也会显得较为死板，有时甚至会导致为了符合设计规则而损害产品体验的状况出现。
   允许设计师在体系界定的范围之外进行必要的探索；既要确保大家理解规则，同时也要赋予他们挑战规则的权利。当然，充分理解现有规则仍是探索的前提。
   松散型设计体系更适用于对灵活性与适应性的需求较高的产品及团队。
   

   构造方式：模块化或整合化

   | 模块化的优点：
   - 敏捷性
   - 成本效益高
   - 易于维护
   - 适应性强
   - 效率高
   | 整合化的优点：
   - 适用于特定类型的内容、情境、创意方向
   - 更具整体性与连贯性
   - 可以面向一次性需求而快速构建，无需考虑扩展性与复用性
   - 工作流程更聚焦，更易协调
   | | —- | —- |

模块化与用户体验—-

模块化的程度并非越高越好，具体状况取决于你需要实现的设计目标。

模块化程度与项目特质—-

模块化构造方式适用于具备下列特质的产品需求：

• 需要扩展与进化空间
• 需要适应不同类型的用户需求
• 需要大量的可复用部件参与构建

• 需要多个团队同步并行地参与构建

  
  整合化构造方式适用于具备下列特质的产品：

• 面向一个特定目标进行设计

• 无需具备扩展性与适应性
• 需要在体系范围之外进行风格探索
• 部件复用率较低
• 一次性

例如，创意展示类页面，一次性的运营活动页面，创意履历及作品集等。

了解利弊，选择方向—-

模块化构造方式更具适应性和扩展性，在长期发展上具有更高的成本效益，但自有其弊端：

• 构造高复用度的模块本身成本较高
• 需要具备足够的通用性才能被用于各类需求用例
• 为了充分发挥模块化的优势，团队往往会要求尽可能复用设计模式

• 如何确保不同模块之间无缝衔接 （需要更加关注模式之间的关联性）

  
  整合化构造方式更为聚焦，更具特定性，能带来整体感更强的体验。但其弊端在于扩展性与适应性较弱，且组成要素的复用度较低，
  模块化或整合化程度还可能随着时间而发生变化。
  

  管理机制：集中式或分布式

  集中式—-
  所有模式、规则由专门的团队统一管理。权责明确，构建方式与风格走向更加聚焦。
  分布式—-
  所有使用到设计体系的人同时也要对其维护与发展工作进行负责。
  个人拥有自治与决策的权利，使设计体系更具敏捷性与适应性；构建方式与风格走向由众人共同制定。
  
  分布式的挑战
  缺乏统一管理，整个设计体系项目会逐渐放慢速度，甚至彻底停滞。个人的主动性随时间降低。
  
  集中式管理机制需要以特定的团队文化作为运作基础；严格型设计体系也离不开团队文化的支持。例如，集中式管理机制无法很好地作用于BBC的Global Experience Language，因为每个设计团队都有着很强烈的意见主张。
  
  了解利弊，选择方向—-

管理方式不完全取决于团队规模。
“我们希望设计师们不仅能认同设计体系，同时更能参与到其发展过程当中。” - Jürgen Spangl，Atlassian

小结

团队文化也是必须考虑的因素之一。
“任何体系化产品的设计特质，都能反映出其设计团队自身的沟通架构。” 康威定律（Conway’s law)

真正优秀的设计体系，其核心并非特定的工具与形式，而是在于能否为特定的团队与产品提供一系列原则与方法，帮助其构建最优的产品体验。如果这些原则与方法足够清晰，那么其他一切都会自然而然地随之而来。

第七章 前期规划与实践

如何获取高层的支持

将其作为商业案例进行演示！让高层意识到，一套行之有效的设计体系能够帮助公司以更高效率、更低成本实现业务目标。

• 节省设计与开发成本 - 以量化的方式呈现低效流程的成本消耗
• 节省全局迭代成本 - 可复用的设计模式可以在任何用到它的地方实现自动更新
• 加快上线速度 - 可以实现快速验证和迭代，利于新功能设计
• 其他好处：
  • 统一品牌认知
  • 建立品牌信任 -

符合心智模型的、行为可预期的设计模式可以有效降低用户使用产品时的认知负荷，界面也因此而具备”符合直觉”的特质

• 提升协作效率

  
  

  如何起步

确保目标清晰一致

对这项工作的产出有着怎样的预期？
设计体系由“设计模式”和“实践方法”两部分构成，构建工作也可以体现这一结构。

• 界面的体系化定义工作
  • 制定设计原则
  • 定义标准化的设计模式
  • 建立设计模式库
  • 创建模式库源文件
  • 重构前端架构与代码

• 工作流程与管理机制的标准化工作

  • 建立知识共享机制
  • 推广设计模式库
  • 推广标准化的协作语言
  • 将设计体系纳入新人培训流程

  
  在目标规划阶段，一份清晰的路线图有助于大家形成共识（可以使用Trello，白板和便利贴……）
  帮助大家理解项目的优先级关系和可预计的进程。
  要确保人们了解这项工作的节奏，避免产生不现实的预期。
  

  提升工作透明度

  “我非常希望设计规范能够成为公众化的产品，这会令我们感到自豪。其他设计师会将其作为重要的参考资源 - 想到这一点，我们就会动力满满地继续前进。“ - Dan Jackson，Eurostar
  公开、诚实的记录对于设计体系团队来说也是保持学习、激发动力的有效方式。
  

  打造协作文化

• 在 Slack 里创建一个单独的频道，用于对设计模式的命名及其他相关问题进行讨论。

• 创建”模式墙”，鼓励更多人参与进来。
• 将设计体系纳入新人培训流程。
• 定期举办同步会议，让大家了解相关进程。
• 鼓励跨职能合作，鼓励主动性强的员工通过协作带动他人。
• 通过工作坊或培训教程帮助更多员工了解设计体系。在 FutureLearn，我们发现基于”问题-解决方案”模式的宣讲最为有效。首先，我们会和大家一起讨论当前设计流程当中遇到的典型问题，然后抛出设计体系可以带来的具有针对性的解决方案。譬如当前页面中的字体使用存在着一系列问题，包括”字号在大屏设备上显得太小，而对于小屏设备来说又太大了，致使阅读体验折损”，”标题样式太多了，不知道该用哪一种，而且在一致性上也有问题”等等。然后我们会为大家讲解如何通过设计体系中的标准化定义来解决这些问题。

• 游击策略。Smashing Magazine 会为特定的工作日指定一个界面组件，例如他们有”轮播组件日”、”Lightbox 组件日”、”折叠组件日”等。在这些日子里，大家会收到包含组件样式、状态、前端代码等内容的传单。

  
  “我们将这些传单贴在茶水间和洗手间。一个月之后，每个人都将组件名称记得一清二楚，包括保洁人员在内。“ - Vitaly Friedman，Smashing Magazine
  

  保持团队动力

  构建模式库时，可以将工作氛围“主体”和“精进”两部分，首先聚焦于各个模式最关键的构成，然后逐一细调。
  对于设计体系当中的一些关键工作，例如界面清查或模式库搭建，尽可能让大家都参与进来，至少在初期。这有助于形成权责自主的氛围。
  用事半功倍的方式制定前期规划也很重要。可以先将设计稿中的标准化组件截屏并添加到模式库的相关页面当中，而无需等待所有代码重构工作的完成；这样设计团队也可以立刻进行参考使用。
  

  如何培养体系化的思维模式

  “模块化设计”不仅是将界面切割成若干部分然后再重新拼合起来这么简单。
  
  团队实践方法：

1. 识别产品的关键行为或风格特质
2. 对现有元素进行清查

3. 定义设计模式

   
   对于功能性模式与感知性模式，每一步的具体实践方式都略有不同。

需要从整体层面入手，再将界面解构成若干组成部分依次定义。（有助于理解模块之间的协同运作方式，以及它们是如何驱动产品整体目标的实现的，而不是浅显地聚焦在一个个独立的模式当中进行研究。）

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

在思考模式与产品目标及设计意图之间的关联时，必须要考虑到特定的产品所鼓励的关键行为是怎样的。

目标导向的界面清查

从“目标”（行为）的维度对界面元素进行归类，而非按照元素类型（按钮、tab、下拉菜单）。
首先理解设计模式的目标及运用方式。

界面清查的准备工作

时机

清查前对现有产品进行必要的研究，确保现有设计中没有本质性缺陷或明显可用性问题。
（内容策略、信息架构、可用性等方面）

团队

初期规模4~8较理想。设计师+前端工程师。后端开发人员、内容生产者、产品经理。

打印页面

识别产品核心行为路径所涉及到的关键页面，即对于产品来说绝对需要、无可替代的页面。
具体数量取决于产品类型，通常10~20个。
每个页面一式两份，一张贴在墙上用于演示用户历程；另一张用于裁剪组件并归类粘贴。
在整体与局部之间切换视野。

第一步：识别关键行为

将界面按照用户历程的不同阶段进行分组。

选择恰当的用词

对于行为的描述方式应该聚焦于用户的角度，而非单纯处于产品或业务目标。
用词的选择体现着设计策略，能间接决定产品以怎样的方式呈现怎样的内容。

解构关键行为

将关键行为分解为更具体的任务，用便利贴标注在打印稿旁边。
可能会发现界面里有些任务从本质上讲是具有重复性的，即使表现形式不同。（例如tab导航或类别菜单都拥有筛选功能）

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

每次聚焦于一个特定的目标任务，将所有页面当中用于执行该任务的元素归为一类。
这些元素会成为接下来定义功能性设计模式的备选。
要确保元素颗粒度的一致（应避免：例如同一分组中出现“书籍列表”和“借阅按钮”这样颗粒度完全不同的元素）

第三步：定义设计模式

完成元素的归类分组后，还要考虑具体的模块化策略，例如是否需要将某些元素整合为同一个模式，还是保持单独定义。
判断标准的两个思路：

1. 考量特定化程度

specific - generic
具体策略永远取决于希望达到的目标。
“是否希望用户以更独特的方式对展会信息产生感知？”
“活动信息与展会信息当中是否存在某些会引发设计方案冲突的元素？”

2. 梳理信息架构

对于底层内容架构相同的模块，可以整合为同一种设计模式。
某些模块可能有相同的信息架构，但出于设计意图或具体页面情境的考虑，它们需要独特的外观样式或行为方式。这时，可以将其视为相同设计模式的不同变体，而非不同的模式。
在模式的默认状态中定义其核心内容及样式，通过变体状态提供额外定义。需要判断哪些信息属于核心，哪些属于扩展部分。
通过考量信息架构与风格样式之间的关联性，可以判断能否通过扩展变体来提升某些基础模式的复用性。

第四步：为设计模式命名

试着在命名中体现设计模式的特定化程度。

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

深入到更基础的元素当中。
按钮和链接，这两个元素之间有怎样的本质区别？目标是否一致？
几个用于判断异同的方面：

行为一致性

无论如何定义，关键在于清晰一致的诠释方式。
用户在使用界面时需要对元素的功能及行为结果产生正确而一致的预期。

视觉层级

特例

第九章 感知性设计模式的体系化

通过灵活而可靠的方式塑造产品感知。

仅定义属性是不够的

颜色的细微差异不是问题。同一种颜色在全局界面环境中表达相同的含义即可。
仅有一系列色值定义是不够的，你必须同时对它们在实际页面情境中的使用方法进行标准化定义。
应该以怎样的方式在风格定义中将样式的目标与使用方法体现出来？从较高层面入手，从整体的外观特质起步。

外观特质与标志性设计模式

可以让团队分享它们认为最能体现产品差异性的、最令人印象深刻的样式元素。
“想到你们的产品时，哪些风格或调性会首先浮出脑海？”
“用户使如何描述你们产品的外观特质的？”
“哪些元素是用户时常在反馈中提及的？”

不要只关注样式属性，而是要上升到设计原则层面，考虑风格要素之间的作用关系，以及如何组合运用等等。例如“白色区域为主，通过粉色与蓝色传达品牌特质”。

定义感知性设计模式

完成了标志性设计模式的识别后，可以将其归纳为若干类别，逐一进行体系化定义，其中通常包括：

• 配色
  
• 交互状态
  
• 动效
  
• 字体
  
• 字号
  
• 栅格边距
  
• 图标风格
  
• 形状与边框样式
  
• 插图
  
• 图片
  
• 语气基调
  
• 音效
  

其中每个类别的体系化定义工作都要参考以下流程进行：

1. 分析目标
   
2. 清查与归类
   
3. 定义设计模式
   
4. 规范使用方式

往往需要多轮迭代。
定义过程中可能出现重叠的状况。可以首先着手核心风格要素的定义，以此为基础对其他模式进行定义。

配色

分析目标

用清晰明了的词语来描述，例如：

• 用于体现文本的类型与层级关系（正文、标题、引用）。
  
• 用于呈现链接与行动点（主要行为召唤、次级行为召唤、文本链接）。
  
• 吸引用户关注特定的信息，体现信息的类型差异（确认信息、警示信息）。
  
• 区隔内容，体现重点（背景、边框）。
  

• 体现数据的类型差异（图表、曲线图）
  

  配色清查

  从四个方面对每种颜色进行描述，包括：

• 类型 (type)：使用了该颜色的界面元素类型，例如行为召唤按钮、页头、反馈信息等等。
  

• 范例 (example)：通过实际截图演示使用了该颜色的具体界面元素。
  
• 色值 (value)：Hex 色值。
  
• 感知 (feel)：如果该颜色用于塑造特定的感知或氛围，则在这里进行描述。

  定义设计模式

  从功能目标的维度对配色进行梳理，有助于发现颜色误用的问题。
  对标志性设计模式的深刻理解有助于在样式迭代和品牌感知之间寻求平衡。

  凝练

  移除非必须的颜色

  仅定义用得到的配色

  确保对比度

  规范使用方式

  动效

  暂时略……

  语气基调

  暂时略……

第十章 设计模式库

原始内容的呈现

不必纠结模式库网站的构建工具和外观形态……Google Docs类似的协作工具就可以帮助完成设计模式清查及定义工作。

设计模式的组织方式

以怎样的架构对设计模式及相关文档进行组织。初期架构无须尽善尽美，完全可以进行后续迭代。最重要的是团队共识。一些典型的组织方式：

“组件”与“风格”

感知性设计模式通常彼此关联，作为单独的一大类更佳。
样例：“组件”“基础”；“组件”“风格”；“UI组件”“设计元素”

功能性设计模式的组织方式

会始终保持增长。易访问性是相当大的挑战。
组织方式多种多样，例如命名字母顺序、颗粒度层级、类型（导航、表单元素）、目标等。
找到适合团队的方式。无论架构看上去多么合理，只要设计师们仍然受困于无法找到所需的模式，就需要继续尝试和迭代。

设计模式文档

初期可以为最关键的模式添加简要概述，在持续迭代当中，按需补充。

功能性设计模式的文档化

几项基本信息：

• 名称
• 目标
• 范例（包括可视化样式与实际代码）
• 变体

额外元素：版本信息，相关人员，相关模式

感知性设计模式的文档化

描述使用方式
跨类定义（在功能性设计模式的文档中引用相关的感知性模式定义，例如按钮的配色形状等风格）
描述风格元素之间的关联

工作流程

新模式入库流程

一个供参考的三步流程：

1. 设计师将设计方案提交到dropbox上的一个UIKit文件夹
2. 团队共同讨论该方案是否应该添加入库

3. 通过后，将新模式录入文档，同时将设计文件添加到Craft (Sketch) 当中

   新模式入库条件

   两个参考流程：

4. 通过自动化工具将每一个新上线的元素添加入库，前提是上线之前的设计开发流程严格遵从模式库的规范要求，且有评审环节来判断模式库中是否已有类似的模式，或是否可以对现有模式进行迭代。

5. 仅在元素被复用之后将其添加入库。很多团队会在第二次或第三次用到某个元素的时候将其判断为具有复用价值。这种方式的意义在于，元素要证明其自身可以成为设计模式。为了确保可行性，团队可以通过一份”未入库元素清单”来对所有新元素的复用状态保持跟踪，并且要做到密切沟通。

   团队与权责

   管理员+制作者

   齐头并进

   设计模式库、设计源文件、前端代码……
   团队需要以一致的思路与方式在每个方面的工作中进行实践，包括目标、架构、命名等诸多方面。

工具

暂略！

设计模式库的未来

解放设计师的时间，将精力用在更重要、更有意义的问题当中。

结语

Alexander 最初提出的设想当中仍然有一个非常关键的部分是我们目前所忽视的：从道德层面来看，我们的体系化设计思维能否真正为人们的生活带来积极的改变？

即便有着良好的设计初衷，我们所创造出的多数方案也仅是服务于短期商业目标的，而非力求为人们的生活带来真正的价值 - 我们成功地创造出了各种令人上瘾的设计模式，创造出了各种鼓励人们浪费时间、花费金钱的设计模式。

我们对自己负有责任，对所有使用我们产品的用户负有责任，我们需要对设计模式的价值与作用保持长久的思考与验证，同时也要对我们自己的设计目标与意图保持清醒。

（全书完结）