前言——假设你是一个设计师
从零开始，你会如何设计界面？
用户分析
用户分析，即针对用户群体、用户画像、用户习惯进行调研——谁在用？
不同的用户群体，偏好不同的界面设计——适老化、低龄化、女性化
场景分析
场景分析，即针对产品使用的时间、空间，使用时的心态进行分析——在哪用？什么时候用？
不同的使用场景，会有不一样的设计——高频、低频、重复性/夜间、白天/用户心理
产品目标分析
产品目标，即产品实际上解决的是什么问题——用来干什么？
不同的产品目标，引导不一样的设计——功能性/感知性
已有界面，你要如何在上面加功能？
保持相同的风格
统一的设计风格，包括统一的配色、间距、排版、动画等
保持相同的设计风格，可以使新增的模块不会显得突兀，降低用户的学习适应成本
保持相同的目的
如果设计原本的目的是方便老年用户使用，那么在新增功能时也一样要保持这个目的
什么是设计体系
组件库是设计体系吗？
在此之前，可能包括我在内的组件库本身理解为设计体系。但实际上，模式库/组件库只是设计资产，处于整个设计体系中的塔尖位置。
组件库在设计时通常会为了适应各种场景而保持高度的灵活性，这会导致很多人在使用组件的时候，找不到统一的原则和规范，尤其是设计层，在面对同样的场景下，使用同样的组件和规范，不同的人还是会出现不同的结果。
支付宝体验大会上有这么一张图：
我们最熟悉的 Antd 组件库作为设计资产，其只是整套设计体系呈现出来最直观的一部分，而其下方不可见的设计模式、设计原则和组织协同等，则是设计体系更加不可或缺的部分。
那么什么是设计体系？
设计体系是为了实现数字产品的目的而组织起来的一套相互关联的模式和共享实践。
设计体系包括设计目的、设计原则、 组件库、样式指南，以及用于提高设计师和开发人员沟通效率的工作流程和实用工具
设计体系可以保证数字产品拥有连贯且一致的设计
设计目的
设计的目的，是解决特定用户在特定场景下的特定问题。
基于确定的设计目的，可以催生出设计的价值观，其可以用于判断设计的目的是否有效达成（判断设计好坏的内在标准）
如基于“让用户更快地完成操作”这样的设计目的，却在界面上放置了太多的其他元素，就可以认为这个设计是不好的。
设计原则
设计原则决定了设计的基本理念，其需要传递产品的精神，并且需要在团队内形成共识。
Ant Design
Ant Design 的设计原则是：自然、确定性、意义感和生长性
Apple
Wayfinding（路径指引）、Feedback（反馈）、Visibility（可见性）、Consistency（一致性）、Mental Model（心智模型）、Proximity（接近性）、Grouping（分组）、Mapping（映射）、Affordance（可供性）、Progressive Disclosure（渐进式披露）、80/20 Rule（80/20 法则）、Symmetry（对称性）是Apple 的设计原则
- Wayfinding 路径指引——跳转、返回、选中高亮
- Feedback 反馈——角标红点、表单校验
- Visibility 可见性——电脑的所有设置项对用户都保持可见
- Consistency 一致性——列表元素的样式保持一致
- Mental Model 心智模型——滑块上标记了方向及其效果
- Proximity 接近性——分辨率、颜色、显示器排列等功能都放在显示器模块下
- Grouping 分组——类似的功能项进行分组（关于本机、软件更新、存储空间等功能可以划为一类）
- Mapping 映射——滑块的值和实际效果保持实时同步
- Affordance 可供性——滑块上的 handle 提示你可以拖动
- Progressive Disclosure 渐进式披露——按照层级点击进入查看细分内容
- 80/20 Rule（80/20 法则）——80% 的使用场景（WIFI、蓝牙、网络、电池）等放置在前 20% 的位置
- Symmetry（对称性）——界面元素具备对称性（基于对称的美感）
设计原则可以让整个团队对设计有一致的评判标准
- 列表跳转缺少箭头指示、子页面缺少返回按钮——违背 Wayfinding 路径指引原则
- 不同的列表样式不一致——违背 Consistency 一致性原则
- 音量滑块不区分是铃声音量还是媒体音量/开机键放置在电脑底部——违背 Mental Model 心智模型原则（如何评价？）
心智模型的评价标准相当主观，难以用一个统一的标准去衡量，只能说针对这些场景，Apple 的设计团队并不认为这会增加用户的心智负担/认为用户的心智模型已经被带歪了需要矫正。
但是在大多数人机交互场景下，我们可以认为 Apple 设计的心智模型最易理解的。
没有设计原则会怎样？
为什么明明是同一个东西，换了个页面就长得不一样了？
日常工作中总会在这些细节问题上争论很久，美其名曰“打磨设计”，其实很多时候就是因为设计原则在团队内部没有达成共识，为了避免出现上述问题，我们要建立一套基本的价值观和原则。
设计模式
设计模式主要分功能性模式和感知性模式两类
- 功能性模式：表现为界面上的具体模块，如按钮、标题、表单元素、菜单等。
- 感知性模式：表现为描述性的样式，以可视化方式表达和呈现产品的个性，如配色、排版、图标、形状、动画等。
这其实可以对应为前端开发中的 HTML（功能性）和 CSS（感知性），前者描述页面结构，后者描述界面样式
针对相同的功能场景，不同的设计，在功能性模式层面可能极其相似——例如钉钉和飞书
两者具有非常相似的结构，左侧的功能栏，消息列表，右侧的对话界面，以及顶部的功能按钮，这是因为两个产品的设计目的及设计原则是相似的（因为其用户、使用场景、以及产品目标是一致的）
但是实际上，即便我们忽略在截图中可能透出的品牌信息，仅凭界面设计的排版、配色等属性，就可以非常轻松地区分出两者属于不同的品牌，这就是感知性模式在起作用
模式库
在针对功能性模式和感知性模式做系统化提炼的过程中，我们可以沉淀出一套可复现、可复用的模式方案，即模式库。对应到前端开发领域中，就是组件库。
针对设计模式的系统化，可以参考《设计体系：数字产品设计的系统化方法》的第八、第九两章，这里不多做赘述
我们以一个实际开发过程中大家可能经常会感到困惑的点来引入模式库的概念——链接。
在 Ant Design 中有两个链接，分别是 Button 的链接按钮，和 Typography 的 Link 链接，很多时候我们会感到疑惑，究竟在何种场景下选择按钮还是链接？对此，Ant Design 4.0 是这么说的：
按钮和链接定义是不同的，按钮用于发起动作，触发相应的业务逻辑。其与链接的区别在于，链接的作用是导航，但链接并不影响后端或前端展示上的逻辑。
然而，现在，按钮和链接的界限越来越模糊，按钮面临的使用场景越来越复杂，也常出现用链接作为按钮的场景，例如表格的操作列，通常这样的设计通常并无大不妥。
实际上，设计师真正考虑的是操作的一致性，即按钮和链接两种模式各自对应的操作是否始终保持一致：
- 对于用户而言，如果按钮总是用于提交数据，却在一种情况下表现得像链接，就会造成困惑。
- 同样的如果链接总是用于跳转页面，却在一种情况下表现得像按钮，也会给用户造成困惑。
因此，即便在前端开发看来，链接按钮和链接可以使用同一个组件，但是在设计视角中，它们是截然不同的两个模式。
设计语言/共享语言
一套相互关联的模式构成了产品界面的设计语言。设计师的设计表达目标是用户，而实际向用户表达的则是前端开发者。这本质上是一个传声筒，由设计师向前端开发者表达设计意图，再由前端开发者向用户表达意图。
如果一个设计模式，对于设计师是一个概念，对于开发者是另一个概念，那么当设计实际到达用户侧时，就会产生交流和表达上的歧义，形象点说就是“中间商赚差价”。
以上文提到的链接为例，假设我们大部分的开发者对于链接没有明确的认知，在开发过程中进行了混用，那么如果后续设计师要对模式库进行统一修改时，例如要将所有的链接加上下划线，那么我们修改了组件库后就会发现，有大量页面跳转的场景使用了按钮而非链接，这就会给用户带去困惑。
因此，一套用于在设计师与开发者之间进行沟通的共享语言就极为重要了。在构建设计体系的过程中，我们需要打通设计师和开发者之间的沟通壁垒，统一心智模型，才能更好地达成设计目的。
理想情况下，参与产品创建的每一个人都应该知道这个元素是什么：它的名称和目的是什么，为什么会被设计成这样，应该如何使用它，以及何时应该使用它。这种共享的信息越多，就越有可能恰当地使用它。
古茗的设计体系——GuDesign 2.0
特指古茗的 B 端设计
设计目的/设计价值观
服务的用户
加盟商（门店宝、古茗学院）、总部人员（督导工作台、维修宝、古茗通）
共性目的
更好地服务加盟商和总部人员
催生出怎样的价值观？
- 简单易用：基于用户画像——加盟商平均 35 岁
- 快捷高效：门店日常工作繁琐，不应当继续增加工作量
体现在什么地方？
- 颜色：对比度（线下场景）
- 文案：自然、平等、尊重、友好
设计原则——简单、统一、高效
模式库/组件库
设计模式库：基于 Figma 的变体组件库
前端组件库：
gudesign：基础组件gudesign-pro：Pro 组件、业务组件formily-gudesign：基础组件 Formily 桥接formily-gudesign-pro：Pro 组件、业务组件 Formily 桥接
设计语言/共享语言
Ole UI：设计体系文档建设，组件专题分享
模式和组件的一一对应
使用 Figma 来统一设计师和开发者的心智模型
——组织协同（用于提高设计师和开发人员沟通效率的工作流程和实用工具）
当你觉得设计使用的组件不合理或是实际开发时难以使用
这里应该是按钮吗？按钮有灰底的状态吗？实际的业务场景像是一个按钮吗？不触发 CTA（Call To Action，行为召唤）的按钮是合理的吗？
设计师（Button）=> 开发者（Selector）=> 用户（？？？）
（当然这个例子不太合理，因为目前的 Selector 也不支持自定义图标，但单从场景来看，这更像是 Selector）
这应当是选择器吗？这里会有选择器的选中逻辑吗？选择器应当触发 CTA 吗？
设计师（Selector）=> 开发者（Button）=> 用户（？？？）
根据这些设计违背了“统一”的设计原则，会给用户造成交互上的困扰。作为开发者，我们应当对设计师提出反向要求，不能交付这样的设计。
总结
本文主要分享从一个前端开发者的视角，在参与设计体系建设和落地的过程中，对于设计体系的学习和理解。
目前前端组件库和设计的模式库都处于快速迭代中，在文档建设上难免存在疏漏，后续我们会加强设计体系和组件的文档建设，帮助大家更好地进行开发。
参考文章
Human Interface Guidelines | Apple Developer Documentation