我在刚进入公司不久的时候，有幸参与了PC软件端的设计规范制定。我在接手的时候，PC端的产品已经比较完整，但是却没有一个完整的设计规范。面对这么多模块多少让人有点头疼，从整理模块内容到规范的制定，前前后后大概花费了一个月的时间。这次结合亲身参与的制定规范项目，围绕：设计规范的必要性；制定规范的时机；制定的过程和后续工作这几个方面和大家分享。
首先，我们要了解什么是设计规范。
设计规范
设计规范是指对设计的具体技术要求，是设计工作的规则。设计规范大致可以分为三类：
品牌类
一般以产品宣传手册的形式呈现，主要是对公司整体的用户体验、品牌、视觉等方面的规范，帮助塑造企业形象。
平台、系统类
一般为介绍平台、系统生态的设计规范，主要是在遵照上一个层次的基础上，说明平台理念，开发者需要遵循的规则，以及遵循这套规范的优势。
产品业务类
这类规范侧重在某个产品的设计和实现层面，主要是为该产品制定统一的用户体验、品牌、视觉等方面，需要将内容梳理清楚。设计师和开发可以很直接参考和使用。
设计规范的必要性
互联网公司的产品设计规范，更多用在使用、简化开发的过程，使多个产品拥有一致的体验，是落到实处的东西。
统一产品用户体验
由于公司的产品项目比较复杂，每个产品经理负责不同的产品线，此时设计师们又是渗透到各个产品组中，那么产品之间的体验就根本让用户感觉不出是一个部门设计开发出来的。
不同产品线的产品经理交给设计师的线框图就千差万别。比如实现一个筛选功能，有的采用下拉菜单，有的采用弹窗。相同的情景不同的交互方式，产品之间就会出现体验上的矛盾。
最后，不同产品线上的设计师设计风格也存在差别，比如外观尺寸设计，配色选择等等。当没有独立的设计组时，产品线上的设计师均各自为政，并直接对产品经理负责，更加深化了产品间的不协调。
方便设计开发产品
在制定设计规范的过程中，会形成统一标准控件库、页面元素尺寸规定、配色方案规定和视觉风格统一指导。设计者可以按照功能需求直接调用规范中的标准控件，按照信息结构需求调用不同的元素尺寸进行设计，减轻了设计过程中对交互控件选择和信息排版的思考负担。
形成备案和文库
如同技术文档一样，产品在设计方面也需要文档与规范。由于业务需求的变化，设计规范不会一成不变。通过文档备案记录每次设计调整，调整的初衷和理论依据，便于日后的回顾与总结。自己在刚入部门时既没有产品设计规范文档，又没有规范的技术框架文档，在产品成长与传承中出现了中断。
制定规范的时机
做一份设计规范可能会花不少时间和精力，什么时候应该做设计规范比较合适，又怎样使规范制定的结果得到落实呢？
什么时候不需要设计规范
在产品刚刚起步或者版本迭代次数比较少的时候，总结出一份规范为时尚早，此时的产品仅仅拥有大体发展方向和基本功能，很多细分工功能不够完善，产品整体不够丰满。这时候，建立和维护一份设计规范是很奢侈的。此时制定出的规范不但不能起到概括和统一的作用，随着产品不断完善，大量功能需求会添加进来，而规范也要随之大更改，会增加设计师修改调整规范的工作负担。如此大规模修改规范本身就失去了规范作为一个准则的意义。
什么时候应该考虑制作设计规范
在产品做出一次大的设计变更之后，比如从2.0版本更新到3.0版本，这个过程中，设计师会产生出一份崭新的全面的设计稿。在这个基础上，制定设计规范更容易。除了大改版，设计师也可以只改外观，不改逻辑，对规范进行小幅度的迭代。这时有了设计规范，就可以根据规范一点一点地调整，而不担心会遗漏了。
如果公司旗下有一个以上的产品线，又想让产品之间保持一致性，有设计规范作参考会容易很多。设计规范应该设置为所有员工都可以浏览，设计师或前端工程师有权更改，并且每一次更改都需要记录。在规范里标明品牌个性，设计原则，各种可复用的元素等等，可以减少设计和开发之间的摩擦。
如何制定设计规范
了解了设计规范的必要性以后，我们就开始谈谈规范的制定。设计规范虽然只是简单几页，但那是浓缩概括的结果，并非一蹴而就。
设计规范制定计划
首先要确定这个项目的范围，明确设计规范的类别，预估项目所需要的时间。
对于设计规范的类别，由于PC端是一个比较完整且复杂的PC软件客户端，我可能更想做一个动态的，可不断更新的设计规范库，而不是一个画满标注的PDF，我选用了axure来制作规范，直接生成HTML文件，可以满足所有员工浏览设计规范。确定类别后，便要考虑如何梳理各个模块的内容。
归纳和确定规范的模块
在制作之前，设计师要对规范自身的展现形式和样式达成一致。按照讨论决议出的结果确定各个模块维度的规范。我把模块分为：标准色、字体、布局、图标、控件尺寸和控件交互、导航、数据展示以及动效交互。
制定设计规范
标准色
对于一款产品来说，颜色传递给用户的感觉最直接，设计中对色彩的运用不仅要考虑品牌的识别性，还需达到信息传递、操作指引、交互反馈，或是强化和凸显某一个元素的目的。
首先我使用了24标准色环作为参照，每个颜色在色换上的范围是15°，根据赤、橙、黄、绿、蓝、靛、紫的七色顺序，依次编号（白和黑色属于中性色）。随后在整理好的模块中，确定产品使用的品牌色、主色调和辅色，对应不同色颜色范围，填入对应的色块中，同色号的排序根据饱和度和亮度的范围，由浅到深排序。
色号上标明了HSB值，方便设计师理解当前颜色的色相、饱和度和亮度。同时标明了RGB值，方便程序在开发时可以直接调用RGB编码。
HSB值：HSB模式以人眼作为对应的媒介。H(hues)表示色相，S(saturation)表示饱和度，B（brightness）表示亮度。
在完成颜色的整理后，对品牌色、主色和警示色等使用率较高的颜色进行举例说明，帮助设计师理解如何使用色调。
字体
字体是界面设计中最重要的基本构成之一。随意使用字体，即使其他规范都很统一，也会给用户感觉这不是同一款产品，或者不是同一个设计师做的。
梳理最常用的中、英文字体定义为主要字体，标注字体的字重、字体颜色、字号和行高，并进行举例说明常用字体。在整理的过程中，顺便修改模块中使用不规范的字体。合理的使用不同的字重、字号和颜色来强调界面中最重要的信息。
布局
针对电脑分辨率的不同，对PC端的产品做了两套尺寸的布局来满足用户的使用：当屏幕分辨率大于1920 x 1080(px)时，PC端界面的窗口模式尺寸为1920 x 1080(px)；当屏幕分辨率低于1920 x 1080时，PC端界面为800 x 600(px)。随后陆续梳理登录窗、弹窗、下拉菜单和其他特殊的布局尺寸。
控件
控件的目的是为了帮助用户了解应用当前要做什么，也给用户的下一步行为做参考，以及了解操作后所产生的结果 。当用户和客户端需要交互时，使用不同的模式来反馈信息或结果。将控件的交互分为四种状态：默认、悬停、点击、禁止。然后与其他规范制作的过程一样，从泛用最高的控件开始整理，并给出对应的举例。最后制作特殊的控件样式。
优秀的设计规范是高度精简和概括的，把同一种情境下的不同设计样式统一成更具适应性、更科学合理的设计样式，参与产品的设计师和程序员开可以直接调用适合的设计样式，尽量减少特殊情况的设计和繁琐的重复尺寸标注。当然在设计过程中总会出现特殊情景，此时设计师要单独给出规范和对应的设计效果图。当特殊情况越来越多，就要考虑将这些情况整合，补充进现有的规范中。
收尾
规范制定出来并非一成不变，随着业务发展、需求增加，规范要在原有内容基础上进行需改、增删。规范的弊端就是每次有重大更改，会造成很多产品线多个产品的相应调整，甚至还会牵扯到结构架构的修改。慎重修改已制定出的规范，多采用小更改迭代的方式对规范进行补充修改。
拥有设计规范并不代表团队不再需要设计师，也不代表团队中谁都可以使用规范组件拼拼凑凑就输出设计效果图。产品设计含有感性的成分，需要设计师通过调研和认知去设计、把握产品的体验。规范是工具、是标尺，需要设计开发人员的灵活运用和不断完善，适应变化。规范拥有重要作用，但不可拿着规范把产品做死、做僵。
