交互设计

团队设计沉淀:做好 Style Guide 不容易

0
登录或者登记去做吧。
团队设计沉淀:做好 Style Guide 不容易

说起 Style Guide (即设计规范),大部分人的第一反应就是 Material Design 和 iOS Human Interface Guidelines,我自己就是靠读这两份文档逐渐入门设计领域,国内外的设计师、开发者们自然也是对它们了然于胸。来大公司实习之后,接到的第一个任 务就是维护、优化团队的设计规范网站,同时最近也经常和饿了么、随手记等互联网公司的设计师或产品经理探讨如何沉淀团队的设计。

一个完善的 Style Guide 是什么样的?也许 Material Design 官网给出了一个范本,从交互、视觉、体验、开发四个维度入手,全方位诠释了平台规范一致性的含义。尽管 Material Design 目前的推广还不够理想,不少细节也可能并不完美,但这并不妨碍国内的设计团队像它学习。

构建Style Guide 并不是一件简单的事,尤其对于目前快节奏的行业氛围,从前期就开始沉淀设计内容会耗费很多的精力。就拿设计师来说,有时为了赶项目进度,连命名、标注和切 图规范都不一定能做到细致,更别提去制作一份详细的设计文档了。更关键的是,在高速的迭代下,我们通常很难界定一个设计是否能够称为规范,也许下个月就大 改版了,那前期所做的沉淀不就浪费了嘛。因此,往往很多公司和团队都是到了一定的产品阶段才开始注重 Style Guide 沉淀,这时的工作重心更偏业务和体验优化,迭代也更多遵循已有的样式,规范的重要性才得以体现。但是很容易明白,沉淀这件事,做得越晚,越难做好。

所以第一个问题,我们为什么需要 Style Guide?最简单地说,是为了迭代一致性和设计开发高效性。

团队设计沉淀:做好 Style Guide 不容易

有一份完善的 Style Guide ,它不会直接给你提供设计稿源文件,也不会直接告诉你代码的文档细节,但是它是一个有效的索引。设计稿可能存在于PS 或 Sketch 中,代码则往往放在 Git 平台上,它们像是你开发迭代产品的工具箱,那么Style Guide 就是这份工具箱的使用说明书。它会告诉你什么场景下要使用什么样的锤子,这把锤子要和什么钉子结合在一起,使用方法又是怎么样的,该有哪些注意事项。因 此,通过 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 本身作为一种规范,方便的是设计师和工程师,因此他们对设计沉淀的贯彻程度几乎直接影响了规范的建立和维护。

一个组件的新增,需要有特定的设计师和工程师来审核,这个人数不要太多,因为人数越多牵绊就越多。每个组件可以对应到特定的负责人,主要可以是这个组件的设 计师和代码编写者,同时源文件必须同步显示在网站上,让其他设计师可以直接下载,但若有修改,则应该找负责人来提交审核。只要制度执行够好,这种方式可以 平衡精力的开销。

凡是和稍大的设计团队同学聊,都会遇到设计规范的问题,所以今天也结合自己的实际工作提出一些想法,希望给大家一定的启发,也是督促我自己在接下来的工作中把设计沉淀做得更好一些。

 

原文来自:简书

作者:镇雷

值得你深入了解的交互设计五大支柱
用户体验是建立在牺牲员工利益之上的