下面将以百度手机助手为例，介绍设计规范产出的过程：
目录：
一 编写背景
二 目标人群
三 使用场景及诉求
四 编写时的注意事项
五 阶段划分与介绍
一 编写背景
1、手助是一个处于成熟期的应用，有大量的设计经验需要沉淀
2、经过多期版本迭代与越来越多的设计师的参与，端内出现了很多体验不一致的现象，需要打磨细节体验，对端内设计进行统一
3、产品处于转型阶段，需要构建新的设计模式与架构
4、为新人培训进行设计储备
二 目标人群
1、交互设计师与视觉设计师
2、PM
3、组内设计新人
4、第三方插件的设计师
三 使用场景及诉求
1、设计师在设计时不知道该用哪个控件合适或不知道控件里的元素该如何使用。诉求：快速准确的在规范里找到相应内容并准确使用控件
2、在做控件统一与更新时，需要对照规范统一整理与修改。诉求：具有一定的规范性与指导性
3、两个设计师在同一场景下使用的控件不一致需要对照规范进行统一时。诉求：具有一定的规范性与指导性
4、与PM的方案有分歧时，对照规范进行说服。诉求：对控件的使用方法及限制做一定说明，必要时增加反例
5、新人到岗，对端内控件的使用规范不理解时。诉求：通俗易懂有一定的指导意义
四 编写时的注意事项
1、通俗易懂，高效便捷。尽量使用图解而不要使用大段的文字，帮助读者快速理解，如下图，为“按钮”的每一种使用场景配图，更易于理解与查看
2、规范要具有弹性与扩展性，重点在于指导而非限制，要考虑产品将来的拓展与变动
3、考虑控件与控件间的关联性，各控件元素可以组合生成一些特殊的组合控件，规范的编写要方便进行后续的演变与扩展
4、考虑规范的通用性与代表性，除了应用商店类产品，是否可扩展至其他类型产品的使用中
5、考虑对第三方应用的指导性
五 阶段划分与介绍
设计规范的产出经历了如下几个阶段：
下面对每个时期作一下大概的介绍
1、编写期
编写期同样可以分为几个阶段，如下图：
· 成立小组：
我们将小组成员分为评审组与编写组，以保证有丰富经验的前辈为编写组整理的规范进行把关，同时，小组的成员还要包含交互、视觉、品牌的同学，以保证输出的规范尽量全面。
· 汇总案例：
搜集尽可能多的需要整理的内容，例如控件中需要哪些些控件作规范、要对哪类页面布局重新整理、哪些设计模式需要规范等，尽量做到不遗漏。
· 分类排序
针对汇总到的案例对各元素进行重定义与再分类，例如我们将几类比较容易混淆的控件：中间弹窗、底部弹窗、浮层、toast统一放在【提示控件】的分类里，在制作规范的时候，重点强调这四者之间的区分，方便设计师选用。分类完成后对需要编写的内容区分优先级，根据优先级分先后产出。
图：提示控件间的区别
· 开始编写
编写时要考虑使用哪种载体比较合适，我们考虑了word、pdf、sketch、wiki平台等形式，最终决定统一在wiki平台上进行编写，一来方便编辑、存档与修改、二来便于推广与更新迭代。
在编写时，我们从以下四个维度保证规范的指导性，下一篇将针对规范的内容作详细介绍。
·评审修改
第一版编写完成后，召集所有小组成员对规范进行评审，搜集改进意见，尽量保证规范的易读性与指导性
2、设计规范的推广与落地
规范编写完成后，需要促进规范在组内的推广落地与迭代，我们在组内选定了2个接口人负责规范的推广与更新工作，考虑到规范不好推动的问题，我们采用分批分拨的方法，与团队内各个角色进行沟通。采用的形式主要有：
1、开会向大家宣讲规范内容
2、用设计规范对新人进行设计培训
3、内审时针对不符合规范的案例重申设计规范，让大家更加熟悉
4、创建symbol让大家直接调用现成的控件
关于规范的落地，因为产品有自己的阶段性目标，不能影响发版节奏，所以我们将规范放到几个迭代中，分块进行落地，每一块选取相关联的内容，从最底层的控件开始，慢慢针对端所有体验不一致及需要升级的内容进行更新。
在优先级的排序方面，我们将不依赖业务逻辑与代码的纯控件样式上的内容放在优先级较高的层级上，有一定逻辑依赖和业务影响的内容放在更长的战线中，方便规范进行落地。
3、关于规范的迭代
在后续使用中，我们会遇到一些之前没有考虑到的情况，需要及时对这些内容作补充完善，例如在中间弹窗与底部弹窗的选用中，
一开始我们将两者的使用场景区分得很细，在后来的使用中，发现其他设计师很难去理解，为此，我们简化了中间弹窗与底部弹窗的使用场景
改版前
修改之后图示如下：
即除了运营类弹窗外，由“策略”触发的“引导”使用中间弹窗，由“用户”触发的“简单反馈与提示”以及由策略触发的“提示”使用底部弹窗
改版后
以上便是百度手机助手设计规范整体流程的一个大概介绍，因为这些规范是针对手助的功能特点而做的，因此不能完全适用于其他应用，写本文的目的，在于希望我们编写规范过程中的一些小技巧与小经验，可以帮助同样想要编写规范的小伙伴们理清思路。
