从作为 UI/UX 设计师典范级入门教材的 Human Interface Guidelines 和 Android Design Guideline（已升级为 Material Design），到各个团队的业务都有自己的设计规范，设计规范似乎越来越重要。甚至每做一个项目都会出一套新的规范，定义好设计原则，把项目中用到的字号/色值/按钮/输入框等全部整整齐齐罗列出来。
可是，花这么多精力建立的设计规范是为了解决什么问题？有没有人用？最终的成效如何？这些都是建立规范的设计师应该反思的问题。
一、设计「设计规范」
经历了多个团队和项目设计后，发现设计规范的建立也要像对待一个项目一样，需要根据面向的用户、资源、目的、方法，设计出合适的设计规范。
本文将会结合一些业内优秀的设计规范和腾讯视频过往案例的部分设计规范，讲述我们团队在追求「合适」过程中的一些经验和踩过的坑。
二、设计规范是什么
不同的团队对设计规范的定义是不太一样的，有些设计规范主要描述常用控件和色值，而像 Material Design 则涵盖大至整个平台设计的价值观、小至元素设计的细节，造成这些差异主要是团队和业务的不同。（个人觉得我们平常使用的设计规范用 Design System 来形容可能比 Design Guideline 更为合适，它以适应当前项目和团队为前提，可能涵盖项目设计的指导原则、设计标准、设计控件等。）
常见的不同范围的设计规范有：
1. 平台规范
△ Material Design https://material.io
△ Fluent Design https://fluent.microsoft.com
涵盖整个平台的特性、世界观、界面逻辑、设计模式、设计控件等，帮助第三方开发者更清晰地知道在该平台中怎样的设计是符合平台习惯的、不同界面/内容间的关系、操作方式、设计细节等。
2. 企业对外设计规范
△ UBER https://www.uber.design/case-studies/rebrand
△ Dropbox https://www.dropbox.com/branding#use
企业或业务的对外设计规范（设计指南）通常针对第三方开发者或合作伙伴，内容重点一般是品牌设计解释或使用规范，向外部传递企业价值观及帮助合作伙伴更准确地使用企业信息，对内部统筹多个业务的一致性、帮助内部人员理解设计原则或指导设计落地。
3. 业务对内设计规范
△ 腾讯视频移动端设计规范
业务对内的设计规范一般会更微观，通常也会涵盖设计原则、品牌使用规范、界面逻辑、设计控件、元素细节等，偏向具体设计落地的指导，帮助业务设计更准确和一致，提高团队协作效率。
三、建立怎样的设计规范
1. 业务诉求决定设计规范的范围与形态
设计规范跟项目的设计一样，都需要基于当前背景下进行设计，不同的业务诉求所需要的设计规范是不一样的，如 Google 需要建立 Material Design 来指导和规范第三方开发者基于 Android 生态进行设计和开发，而初创团队/项目只需要准确、可复用的标注就能满足协作诉求。
从设计规范的范围和形态上来说并没有绝对的对与错，不是范围越广越细致的规范就越好，能适应当前项目和团队、满足业务诉求的就是「合适的」设计规范。
而规范中需要涵盖到哪些信息、以什么方式呈现和协作，这些都需要基于业务的诉求决定。我们也可以像拆解设计需求那样，通过一些关键点来帮助我们更准确地判断设计规范的范围和形态。
2. 拆解背景
以腾讯视频为例，如果需要建立一套各方面都完整细致的设计规范，需要跨多个部门及业务，其中包含品牌规范、界面设计、广告规范、运营图规范等等，其中耗费的人力和资源非常庞大，在业务快速上升的时期，相比一次性建立规范，根据优先级来单点解决可能是更好的办法。
所以我们在建立移动端设计规范时，遵循「合适」的原则，围绕当前的条件和主要问题，通过规范来解决这些问题：
3. 涉及业务
腾讯视频 iOS/Android 端界面设计，不包括内容运营规范。
4. 需要解决的问题
- 腾讯视频 iOS/Android 端经历5个大版本和几十个小版本，存在一些冗余和不一致的控件；
- 界面的通用模块设计时效率可以进一步提高；
- 多人协作设计和输出过程中容易产生误差导致不一致和细节错误；
- 业务复杂、模块数量多且交叉，每次整体改动都需要耗费大量设计、研发、测试资源；
- 设计、研发对接成本高，尤其是新设计师或新研发介入项目时；
- 1位设计师需要对接多个研发，并且输出/沟通所需的工作量较高。
5. 目标
- 减少冗余控件；
- 帮助组内设计师快速复用基础组件；
- 建立通用的细节设计标准；
- 提高界面的模块化通用程度；
- 建立设计与开发对接的基础标准；
- 提高设计输出对接的效率，降低输出工作量。
6. 目标用户
- 主要负责腾讯视频 iOS/Android 端界面设计的设计师（参与设计师5人左右）
- 会员等相关业务的设计师
- iOS/Android 研发工程师
7. 资源
- 时间：2周内，需要兼顾项目进度
- 人力：1设计师，标准建立后需推动研发进行对接，预计 iOS/Android 研发工程师各1人。
8. 思路
- 在主要界面和栅格定稿后，梳理出主要模块；
- 建立基础控件的规范，并定义使用场景和样式；
- 规范字号、色值、图标尺寸等基础尺寸、间距、位置等信息；
- 建立设计 – 研发对照表；
- 建立设计资源输出规范。
9. 载体
由于这套规范基本不需要与第三方团队对接，常用的 PDF 设计规范更新麻烦且每次修改后都需要所有参与者更新，所以并未使用 PDF 作为规范的输出格式。
- PSD 源文件：用于设计师之间模块、控件、样式的对接和复用；
- Google Docs/内部 wiki：用于承载样式文档、设计 – 研发对照表。
这套规范的最终输出物包含通用模块、控件、设计样式、设计?– 研发对照表、输出（标注）规范，能满足团队现阶段对设计规范的诉求。
除了比较常见的样式/模块/组件等，重点为大家分享是设计 – 研发对照表（后来发现国外的 lightningdesignsystem 也有类似的方法，他们称这类型设计样式与前端结合的格式为 Design Token，并且把大部分设计样式都 Token 化了，但这样需要设计师掌握更多的重构知识以及对Design Token 非常熟悉才能有效落地）及输出规范，这两项对团队协作效率有较大提升。
在主要界面视觉框架基本定型的阶段就开始定义设计 – 研发对照表，梳理框架和组件的间距/尺寸等信息，把视觉转换为准确的数值和编码，并且在后续进行设计时随界面设计不断相互迭代。
在这份视觉 – 研发对照表中主要包含：
- 文字
- 色彩
- 尺寸
- 布局
- 通用基础属性
10. 迭代优化
在使用过程中，发现布局参数上，框架间距的代号应与普通间距代号区分开，否则在界面大改版无法灵活地调整界面框架的间距和尺寸参数。分离框架代号（#WG）与普通代号（#W）后，研发工程师只要修改框架间距代号的数值就能快速调整框架，并且不影响界面具体代号的效果，极大地降低过往版本迭代中要逐个参数对比修改的工作量。
四、推动研发部门建立对接样式表
设计 – 研发对照表能否顺利且高效地执行下去，研发部门的配合非常重要。建立完对照表后，需要推动 iOS/Android 研发在开发端建立对应的样式代码，可以通过 Google Docs 或者内部 Wiki 等在线协作工具进行更新。
并且基于设计 – 研发对照表，设计师在输出标注时使用代号标注的方法，主要有几个优势：
- 省去过往一大串的标注信息，只用几个代号就能完成一个模块的标注；
- 减少在标注过程中出现的人为错误导致数值不准确；
- 客户端研发能快速调用样式参数，提高代码复用和开发效率；
- 提高效率早点下班。
随着项目正计划进行的品牌升级，我们也会逐步针对当前规范进行迭代，如继续完善交互规范、丰富设计模块、完善设计原则等，使设计规范更完整和准确。
除了内部规范，我