最近听了 Design Details 的一期播客,讲的是 The Designer-Developer Handoff,也就是“设计交付到开发”的事情。正好最近发布了自己做的 Figma Handoff,有感而发,想聊一聊设计交付这件事。

我们总能听到设计师对开发的吐槽,或者开发对设计师的吐槽。在我们的印象中,这两类人是两个星球上的人,拥有着完全不同的思维方式。但工作中我们总是需要互相对接,如果还是给对方贴着固有的标签,就不可避免地导致一些沟通上的损耗。这种损耗表现在最终的结果上,就是我们的产品不能达到预期。

所以,我想说的第一点就是,我们可以先摒弃对开发的固有印象,敢于上前和他们多沟通。可能你会觉得有些开发不好沟通,但有可能只是你没有使用他们熟悉的方式去沟通而已。

在这期博客中主播提到的一个做法就挺好的,就是他们会找每一个新来的开发一起,开一个小会给他们讲清楚设计交付到开发的流程,并演示如何使用这些交付工具,比如在 Zeplin 中如何查看样式集合,或者在 Figma 中如何导出图标。

当然,仅仅在事前讲清楚还是不够的,在真实的对接中还是会遇到很多小问题。对于这种情况主播介绍了他们的一个经验,在我看来和开发之间所谓的“约定大于配置”有点相似。举个例子,你所有的设计都使用 4x 栅格(4 的倍数),内边距或元素间距永远都只可能是 4px、8px、12px 等等,但是开发在交付工具中却看到了一个间距为 17px。

栅格系统

假如开发不知道你使用的是 4x 栅格,那么他可能就按照 17px 写下去了。但是,如果你事先和他约定好了“我所有的设计都是 4x 栅格,如果你看到某个间距不是 4 的倍数,你可以自己把它改为最相近的一个 4 的倍数,实在不确定可以找我确认一下”,他可能就会自己纠正为 16px 了。

其实很多情况可以事先约定好,比如说你的设计稿都是像素对齐的,那么如果开发看到了小数就可以自己四舍五入一下。还有 Figma 中的切图,开发很容易点到里面切出尺寸不对的图,那么你们可以事先约定好所有的图标都是 16px 宽的正方形组件,这样他们点到了里面一看尺寸不对就知道点错了(此处打个广告,用 Figma Handoff 可以设计师自己切好图,避免开发切错)。

比如这个外层才是正确的图标边缘

其实,在设计中我们很容易手误,有时候多了一像素,有时候整数尺寸变成了小数,这都有可能。但是,如果我们事先和开发约定好,告诉他们你的设计习惯,就能省去很多沟通过程。毕竟,工具是死的,而人是活的。

播客中还聊到了另一个建议,就是我们可以尝试去理解开发的思维方式,并学会使用他们的开发工具。前文也说到了,我们会让开发去使用交付工具,让他们注册 Zeplin 或者 Figma 账号,反过来想,我们是不是也可以去学一下 XCode、Android Studio 或者 VSCode 如何使用呢?

当然,这并不是说我们要学会完整的开发技能,而是当整个项目环境在我们的电脑上运行起来之后,我们起码应该知道如何改代码以调一下颜色或尺寸这些视觉属性。会使用这些开发工具,自然而然地也会学会他们的思维方式,这对于双方沟通是大有裨益的。

除了播客中提到的这几点,我还有一些比较落地的建议:

  • 合理分布图层结构
  • 图层合理命名
  • 尽量使用真实或者接近真实的填充数据

虽然在很多交付工具中是看不到图层结构的,但是合理地分布图层结构对我们自己影响很大。设计稿中的图层结构和代码中元素的结构虽然不一定完全一致,但也有着很大的相似性,合理分布图层结构,其实就暗含着你引入了一定的开发思维,就不至于做出天马行空的设计。

图层的命名也有很大学问,整齐优雅的命名不仅有助于别人理解,让别人少一步思考,有些命名方式能和开发习惯对上甚至能减少开发很多工作量。比如说图标命名,开发代码中使用 icon-home 的命名方式,正好你也是用这种形式,就很容易对上。同时,建议所有图层没有特别必要都使用英文命名,毕竟开发写代码都是用英文的。

满屏的 Group、Rectangle 看着就很痛苦

最后,设计中的数据,比如商品描述、人物头像、评论等,尽量使用真实或者接近真实的数据。首先,真实数据可以让你提前感知你的设计在真实环境中是什么样的。假如说有一个商品列表页面,每一个商品图你都用了特别好看的插画,这样设计时看起来可能很好看,但是一旦上线变成用户上传的图可能就惨不忍睹。其次,数据尽量接近真实可以减小开发理解成本。

看右图完全不知道是什么

其实,要把设计交付开发这件事做好,说到底还是“多沟通”三个字。借用最近在看的《因计算机而强大》这本书里的观点:“我们的文化分裂为‘人文’与‘科学’两种领域,这让他们感到安全……它构成一个怪圈:文化越是分隔,被分隔的两方越是各行是”。虽然我们的工作内容不一样,思维方式也不太一样,但我们不应该互相排斥,而是要互相学习。