团队设计沉淀：做好 Style Guide 不容易.pdf

团队设计沉淀 ：做好 Style Guide 不容易 说起 St yle Guide （即设计规范 ），大部分人的第一反应就是 Mat erial Design iO S Human Int erf ace Guidelines ，我自己就是靠读这两份文档逐渐入门设计领域 ，国内外的设计师、开发者们 自然也是对它们了然于胸。来大公司实习之后 ，接到的第一个任 务就是维护、优化团队的设计规范 网站 ，同时最近也经常 饿了么、随手记等互联网公司的设计师或产品经理探讨如何沉淀团队的 设计。 一个完善的 St yle Guide 是什么样的 ？也许 Mat erial Design 官网给出了一个范本 ，从交互、视觉、 体验、开发四个维度入手 ，全方位诠释了平台规范一致性的含义。尽管 Mat erial Design 目前的推 广还不够理想 ，不少细节也可能并不完美 ，但这并不妨碍国内的设计团队像它学习。 构建St yle Guide 并不是一件简单的事 ，尤其对于目前快节奏的行业氛围 ，从前期就开始沉淀设计内 容会耗费很多的精力。就拿设计师来说 ，有时为了赶项目进度 ，连命名、标注 切 图规范都不一定 能做到细致 ，更别提去制作一份详细的设计文档了。更关键的是 ，在高速的迭代下 ，我们通常很难 界定一个设计是否能够称为规范 ，也许下个月就大 改版了 ，那前期所做的沉淀不就浪费了嘛。因此 ，往往很多公司 团队都是到了一定的产品阶段才开始注重 St yle Guide 沉淀 ，这时的工作重心更 偏业务 体验优化 ，迭代也更多遵循已有的样式 ，规范的重要性才得以体现。但是很容易明白 ，沉 淀这件事 ，做得越晚 ，越难做好。 所以第一个问题 ，我们为什么需要 St yle Guide ？最简单地说 ，是为了迭代一致性 设计开发高 效性。 有一份完善的 St yle Guide ，它不会直接给你提供设计稿源文件 ，也不会直接告诉你代码的文档 细节 ，但是它是一个有效的索引。设计稿可能存在于PS 或 Sket ch 中 ，代码则往往放在 Git 平台上 ，它们像是你开发迭代产品的工具箱 ，那么St yle Guide 就是这份工具箱的使用说明书。它会告诉 你什么场景下要使用什么样的锤子 ，这把锤子要 什么钉子结合在一起 ，使用方法又是怎么样的 ， 该有哪些注意事项。因 此 ，通过 St yle Guide 我们最直观可以看到的就是“组件” ，可能会在网站上 放不同组件的使用规范 ，以及设计源文件 代码文档的地址。 这里引出了一个概念 ，就是“组件”。我对“组件”的定义就是 ：一些符合整体平台设计规范 ，具有较高 可复用性且具备完善设计、使用说明 ，代码 档的控件。 因此 ，组件应当是有比较大概率反复被用到的——比如按钮、表单、图片样式等 ；组件也应该易于 衍生出新的子组件——比如基于某个表单的子表单 ，修改了颜色或滚动样式等 ；最重要的 ，组件必 须有完善的设计规范 代码文档 ，这才能让设计师 工程师复用它们时效率倍增。 然而在实际工作中 ，我遇到的一个最大的问题就是 ，如何定义一个内容是否为组件。从定义上来说 ，将一个设计内容确定为组件的成本是不低的 ，主要除了产出那些必 要的信息以外 ，还需要特意撰 写设计规范文档、开发文档 ，上传到某个网站或者服务器上 ，最重要的是还需要后期维护。很多内 容在用的时候很难推测未来是否会经 常复用 ，在纠结要不要投入精力去做成组件时 ，往往就放弃了 。 另一方面 ，由于产品的快速迭代 ，组件更新往往也可能变得很频繁 ，这时新增或修改组件还需要一 个小组去评估确认 ，并且要更新相关代码 文档 ，最后还要通过网站让所有同事都知道这件事 ，确 实要花费不少的精力。 基于这样的一些问题 ，不少团队的 St yle Guide 都没有做得太好 ，毕竟这是一件需要长期督促的 工作 ，一旦有些许的松懈 ，St yle Guide 就会逐渐落后于极快的迭代速度 ，漏洞越来越多 ，沉淀的内 容越来越陈旧 ，最后导致需要花费更大的精力去维护它 ，可能慢慢就荒废了。所以 ，做好 St yle Guide 就是在 快速迭代赛跑、是在对抗人的惰性 ，但如果能够坚持下去 ，一定会让团队受益匪浅 。 从这段时间的工作出发 ，我提出几个可以帮助有效构建 St yle Guide 的方法 要点。 第一 ，如果产品规模并不太大 ，可以考虑构建页面到组件维度的 Guide 形式。 做设计的时候 ，尤其是在 已有的产品页面上修改 ，我做的最多的一件事就是截图。把现有页面截 下来 ，然后直接在图上修改 ，增加新的组件。但是