说起 Style Guide （即设计规范），大部分人的第一反应就是 Material Design 和 iOS Human Interface Guidelines，我自己就是靠读这两份文档逐渐入门设计领域，国内外的设计师、开发者们自然也是对它们了然于胸。来大公司实习之后，接到的第一个任 务就是维护、优化团队的设计规范网站，同时最近也经常和饿了么、随手记等互联网公司的设计师或产品经理探讨如何沉淀团队的设计。
一个完善的 Style Guide 是什么样的？也许 Material Design 官网给出了一个范本，从交互、视觉、体验、开发四个维度入手，全方位诠释了平台规范一致性的含义。尽管 Material Design 目前的推广还不够理想，不少细节也可能并不完美，但这并不妨碍国内的设计团队像它学习。
构建Style Guide 并不是一件简单的事，尤其对于目前快节奏的行业氛围，从前期就开始沉淀设计内容会耗费很多的精力。就拿设计师来说，有时为了赶项目进度，连命名、标注和切 图规范都不一定能做到细致，更别提去制作一份详细的设计文档了。更关键的是，在高速的迭代下，我们通常很难界定一个设计是否能够称为规范，也许下个月就大 改版了，那前期所做的沉淀不就浪费了嘛。因此，往往很多公司和团队都是到了一定的产品阶段才开始注重 Style Guide 沉淀，这时的工作重心更偏业务和体验优化，迭代也更多遵循已有的样式，规范的重要性才得以体现。但是很容易明白，沉淀这件事，做得越晚，越难做好。
所以第一个问题，我们为什么需要 Style Guide？最简单地说，是为了迭代一致性和设计开发高效性。
有一份完善的 Style Guide ，它不会直接给你提供设计稿源文件，也不会直接告诉你代码的文档细节，但是它是一个有效的索引。设计稿可能存在于PS 或 Sketch 中，代码则往往放在 Git 平台上，它们像是你开发迭代产品的工具箱，那么Style Guide 就是这份工具箱的使用说明书。它会告诉你什么场景下要使用什么样的锤子，这把锤子要和什么钉子结合在一起，使用方法又是怎么样的，该有哪些注意事项。因 此，通过 Style Guide 我们最直观可以看到的就是“组件”，可能会在网站上放不同组件的使用规范，以及设计源文件和代码文档的地址。
这里引出了一个概念，就是“组件”。我对“组件”的定义就是：一些符合整体平台设计规范，具有较高可复用性且具备完善设计、使用说明，代码文档的控件。
因此，组件应当是有比较大概率反复被用到的——比如按钮、表单、图片样式等；组件也应该易于衍生出新的子组件——比如基于某个表单的子表单，修改了颜色或滚动样式等；最重要的，组件必须有完善的设计规范和代码文档，这才能让设计师和工程师复用它们时效率倍增。
然而在实际工作中，我遇到的一个最大的问题就是，如何定义一个内容是否为组件。从定义上来说，将一个设计内容确定为组件的成本是不低的，主要除了产出那些必 要的信息以外，还需要特意撰写设计规范文档、开发文档，上传到某个网站或者服务器上，最重要的是还需要后期维护。很多内容在用的时候很难推测未来是否会经 常复用，在纠结要不要投入精力去做成组件时，往往就放弃了。
另一方面，由于产品的快速迭代，组件更新往往也可能变得很频繁，这时新增或修改组件还需要一个小组去评估确认，并且要更新相关代码和文档，最后还要通过网站让所有同事都知道这件事，确实要花费不少的精力。
基于这样的一些问题，不少团队的 Style Guide 都没有做得太好，毕竟这是一件需要长期督促的工作，一旦有些许的松懈，Style Guide 就会逐渐落后于极快的迭代速度，漏洞越来越多，沉淀的内容越来越陈旧，最后导致需要花费更大的精力去维护它，可能慢慢就荒废了。所以，做好 Style Guide 就是在和快速迭代赛跑、是在对抗人的惰性，但如果能够坚持下去，一定会让团队受益匪浅。
从这段时间的工作出发，我提出几个可以帮助有效构建 Style Guide 的方法和要点。
第一，如果产品规模并不太大，可以考虑构建页面到组件维度的 Guide 形式。
做设计的时候，尤其是在 已有的产品页面上修改，我做的最多的一件事就是截图。把现有页面截下来，然后直接在图上修改，增加新的组件。但是，有些页面并不是随时可以得到的，比如做 支付成功的页面，或者做退款的页面，往往需要有一个真实订单才可以截到这些内容。所以除非你事先就把截图整理好，不然每次都要去对付这些事，真的挺烦的。
因此，我们可以把产品先模块化。比如电商产品的 detail 页是一个模块，导购是一个模块，支付交易又是一个模块，然后把每个模块的线上界面做好记录，存放起来。同时，最好在每个页面旁边提供这个页面的设计源文件 下载。另外，在每个页面上可以简单注视一下用到了哪些组件，并提供这些组件规范的链接。
这样做的好处就是，从查找页面会非常简单，并且组件以页面为依托，更容易查找对应的组件，也很方便理解组件的实际使用场景，避免光看规范文档但是脱离了场景的情况发生。
第二，严格要求设计稿的命名规范。
我和开发同学聊下来，使用 Style Guide 最大的问题就是，经常找不到设计稿里用了什么组件。本身组件的命名可能很代码化，比如xui/button_homepage，当复杂起来之后，光在规范 网站上搜名称是很难定位到目标组件的。因此，除了界面维度的索引，将设计稿中组件命名规范非常重要。
以Sketch 为例，经常我们画板的名字是 button copy、button copy copy 3，再加上一些 group 操作之后，甚至连 button 字样都不见了。如果只是按钮，好歹还容易认知，但是如果是面包屑、逃生舱等快速入口，或者复杂的表达，就真的很难定位了。所以在设计软件中时刻注意每一个 图层的命名，虽然有些繁琐，但在让设计稿更严谨之余又能极大地帮助开发同学进行定位，真的很有必要。
第三，严格规范组件更新制度。
都说，每件事做到最后，最大的阻碍在人本身，这真的太正确了。 Style Guide 本身作为一种规范，方便的是设计师和工程师，因此他们对设计沉淀的贯彻程度几乎直接影响了规范的建立和维护。
一个组件的新增，需要有特定的设计师和工程师来审核，这个人数不要太多，因为人数越多牵绊就越多。每个组件可以对应到特定的负责人，主要可以是这个组件的设 计师和代码编写者，同时源文件必须同步显示在网站上，让其他设计师可以直接下载，但若有修改，则应该找负责人来提交审核。只要制度执行够好，这种方式可以 平衡精力的开销。
凡是和稍大的设计团队同学聊，都会遇到设计规范的问题，所以今天也结合自己的实际工作提出一些想法，希望给大家一定的启发，也是督促我自己在接下来的工作中把设计沉淀做得更好一些。
原文来自：简书
作者：镇雷
原创文章，作者：Catherine，如若转载，请注明出处：https://www.iamue.com/32284/
