一、什么是功能性设计模式
1. 功能性设计模式时产品界面的实体化组成要素，其存在目的通常是帮助用户完成特定的操作行为。
2. 功能性设计模式可以是简单而独立的，也可以被组合成为更复杂的模式。
3. 功能性设计模式会随着产品的发展而扩充或调整。
4. 在项目早期对一些最为核心的功能性设计模式进行定义，有助于后续设计流程的统一性。
5.（用户）关键行为直接决定着实际界面由哪些最为核心的功能性设计模式所构成。
二、功能性设计模式的体系化
1. 界面清查
界面清查是体系化定义工作的起点，大致包括界面元素的汇总及分组归类等典型步骤。
本书中，从“目标”（行为）的维度对界面元素进行归类，而非按照元素类型（按钮、tab、下拉菜单）进行分组。因为首先需要理解设计模式的目标及运用方式，而非它们是否应该拥有相同的外观。
1.1 准备工作
1. 时机：确保现有的设计当中没有本质性的缺陷或明显的可用性问题，避免设计体系相关工作被历史的或现有的重大问题影响
2. 团队：初期的规模控制在4到8人比较理想。人员构成包括设计师与前端工程师；如果有后端开发人员、内容生产者或产品经理能够参与则更加理想
3. 打印页面：识别出产品核心行为路径所设计的最为关键的页面；通常10-12个不同类型的产品；可以使用mock-up或现有页面里的截图；每个页面一式两份，一张贴墙上用于演示用户历程，另一张用来裁剪组件并归类粘贴
1.2 第一步：识别关键行为
首先要从用户历程的每个阶段中识别出最为关键的用户需求与对应的行为。对于由少量页面构成的产品，可以聚焦于每个界面对于较大的产品，首先将界面按照用户历程的不同阶段进行分组。
1. 从“行为”的角度理解设计模式：聚焦于“它用来做什么”而非“它是什么”，通过动词描述尝试找到最能体现设计模式行为特征的说法；
2. 选择恰当的用词：用于描述关键行为的用词会影响我们的思维方式；对于行为的描述方式应该聚焦于用户的角度，而非单纯处于产品或业务目标；
3. 解构关键行为：对识别出的关键行为进行结构，分解为更具体的任务，用便利贴标注在打印稿旁边；通过行为解构处理出界面中具有重复性的任务。
1.3 第二步：归类
按照行为将元素归类。每次聚焦于一个特定的目标任务，将所有页面当中用于执行该任务的元素归为一类。要确保元素颗粒度一致，比如避免在同一个分组当中出现书籍列表与借阅按钮这样颗粒度完全不同的元素。
1.4 重复上述步骤，逐步降低颗粒度
逐渐降低颗粒度，深入到更基础的一类元素当中。比如按钮、列表、图标等。如果某些元素又着类似的设计目标，那么可以试着将它们归为一类。可以通过以下几个方面来判断这些元素的异同：
1. 行为一致性：相同的元素在本质上能触发的行为必须是一致的；当行为有细微的差别时，也需要进行精准的定义。如按钮与链接的差异需要详细描述。
2. 视觉层级：对于视觉层级以及组合运用状态下的彼此之间的关联也需要进行精准定义，如主按钮与次按钮。
3. 特例：通用原则之外总会有特例存在。如特殊样式按钮等。特例应保持偶然性，一方面可以体现其在整体环境中的差异性，一方面也可以避免通用性的模式受到破坏。
2. 整理信息架构
需要整理出信息重要及关系、统一组件样式的同时明确设计时可以隐藏、展示的信息。此处的信息架构不是整个软件的信息架构，而是单个组件或模块的信息架构。
2.1 步骤
1. 判断并提取某个模块当中最为核心的内容元素，并将非必要的元素标注出来
2. 判断核心元素的层级关系，进行必要的分组
3. 通过草图将信息架构抽象地呈现出来
如果没有足够的必要去区分不同类型的内容，便可以将它们整合为同一种模式。这种模式具有更强的适应性，可以同时用于多种信息的呈现；但其灵活性较弱，任何样式迭代都会同时作用于多种类型当中。
2.2 判断
1. 整合：底层内容架构相同的模块
2. 不整合：整合后将影响其目标实现
3. 变体：具备相同的信息架构但不同的外观样式或行为方式，将其视为相同设计模式的不同变体，而不是创建不同的模式。通过变体对模式提供额外定义。
2.3 命名
为模块命名。命名需要考虑到内容类型，但也不能被特定的内容类型所限制。良好的命名方式体现着合理的复用性，并能充分体现其使用方式
3. 创建设计模式文档
3.1 组织方式
功能性设计模式是保持增长的。组件的组织方式多种多样，可选择的维度通常包括命名字母顺序、颗粒度层级、类型（导航、表单元 素等）、目标等。设计模式组织方式的选择需要经过尝试，才能找到最适合团队的方法。
1. 按字母排列
（a）优点：简单的列表，决策更轻松，避免分类方式的争议
（b）缺点：列表项数量的增长导致管理难度增大
2. 按颗粒度层级排列（原子化设计 Atomic Design）
（a）优点：有助于以层级构筑的方式思考元素的复用性，组合和嵌套方式的明确定义能提升一致性
（b）缺点：颗粒度层级的过多容易导致混乱
3. 按目标排列
优点：有助于设计师理解模块的运用方法
3.2 文档化
对于小团队或起步阶段，一开始先为最关键的模式添加简要的概述，在后续的迭代中根据团队需求将信息逐渐补充进去。可以从几项基本信息入手：名称、目标、范例、变体。
1. 名称：必须易于记忆，且能体现设计模式的目标用途。理想情况下仅通过模式名称就能理解其使用过方式。
2. 目标：言简意骇，尽可能通过一两句话讲设计模式的定义与目标描述清晰。还可以对内容规格进行必要的说明或建议。
3. 范例：最理想的范例是同时提供样式与实际代码，连同响应性、交互方式及动效在内均可做到实际演示。
4. 变体：以列表的形式将变体并列呈现出来，同时对各自的目标用途及差异之处进行详细的说明（Carbon）。
5. 版本信息：在相关组件文档中记录变更；替换掉的设计模式要做好注释说明。
6. 相关人员：带来权责意识与荣誉感，也便于后续沟通。
7. 相关模式：提供相关的备选建议，确保设计是找到最适合自己需求的模式，防止重复创建。
以上笔记均来源与《设计体系 Design Systems》Alla Kholmatova —— C7210译版（译者C7210，于2018年7月至8月发布于公众号“Beforeweb”，并非中国大陆官方引进的译版）有兴趣的朋友可以去阅读一下这本书的完整版。
本篇笔记纯个人读书记录非盈利目的，禁止商业转载或任何盈利目的传播。
