如何让你的设计稿完美落地

2020年的第4篇文章

（本文约3900字，预计阅读时间8分钟）

我在前一篇文章开头讲过，在实际项目中，直至开发扣完最后一行代码之前，UI所输出的视觉稿其实并不算是产品的最终形态。

一个设计师输出了90分的视觉稿，如果视觉仅仅还原了60%，即使设计师的能力再牛叉，在用户甚至是面试官的眼中，54分就是这位设计师的最高水准了。因此，产品最终的视觉还原度不仅仅影响着产品的走向，更影响着设计师本身的发展。

那么，在实际项目中到底该怎么保证视觉的完美落地？

下面我基于之前的项目经验，通过前篇文章的开发工作逻辑讲解三个老生常谈、却极为重要的核心步骤，规范、标注和走查。

1.规范

视觉规范的制定一般出现在设计前期（却影响着整个项目周期），在完成一些关键页面的视觉后，将已有的或者提前定下的颜色、字体、组件等内容制定成规范，不仅仅保证了视觉的一致性，也极大得方便了样式、组件的复用，提高了设计效率。

统一的规范对于视觉还原是极具保障的。缺失规范时，开发仅凭肉眼基本没办法知道这个颜色、字体是之前页面所出现过的，还是新增的，过多无法公用的样式将会大幅增加开发的工作量，视觉还原也将无从保证。尤其是在一个迭代周期长达一年甚至好几年的项目中，没有规范所带来的后果是毁灭性的。

而有了一份详尽的视觉规范，开发就可以提前单独写好公用的样式表，通过link标签在html头部引入，“二码分离”，一方面可以大幅减少代码的冗余，进而提升网页加载速度以提高SEO，另一方面也利于今后代码的维护及迭代，后期样式的改变只需要修改样式表便可以实现全局替换。

一份设计规范应至少包含颜色、字体、图标、排版以及诸如按钮、表单、弹窗等方面的组件，并且你需要尽可能考虑到它们的所有状态。

举个

拿dropshipping项目中选品页的商品卡片举例。用户对商品进行“add to import list（收藏）”操作后，按钮会在短暂的加载后变为次级按钮，将这个过程拆分的话，会发现按钮足足有7个状态：默认、hover、pressed、loading、次级按钮的默认、hover和pressed。

不仅仅在商品卡片中，其他页面都可能会出现类似的按钮。为了让开发能够迅速理解按钮状态及所处的场景，设计师就需要将这七个阶段整合到btn规范中，并为开发注明会出现的所有页面、模块，通过规范来避免状态的不一致。

在定制好规范后统一上传到蓝湖等协同软件（尽可能避免本地协作），方便开发一键查看和复制。后期一旦有新增或者修改，立刻通知所有参与的开发进行修改，减少后期的走查次数和沟通成本。

组件的制定规则比较特殊。它不像颜色、字体这些元素一样简单加入样式表就行，大多数组件会有着各种各样的规则和交互态。并且基于交互的属性，开发得花费较多的成本去结合基于JS的框架（React、Vue等）去codding和封装。因此组件在制定规范前

请务必拉上开发！

然后在下面这三个选项中，根据你们的目前状态来选择方（nn）向（d）。

1.自有组件

检查开发手头有哪些之前项目就写好的组件，全不全？是否需要新增？样式和现有项目是否匹配？好不好修改？

2.第三方组件

如果自由组件你嫌它太丑、觉得即使改也要花费很多时间，那就可以考虑第三方组件——Antd或者Fusion，前者开箱即用，后者可以愉快得定制（比如按钮的padding），定制完再开箱即用。

3.DIY

如果你是个比较倔强的设计师，并且开发没有带刀的习惯，那你可以选择自己用sketch去DIY一套组件库让开发coding并封装。具体的样式、规范可以参考Antd这个优秀的语言。

当然，在时间不是非常充裕的情况下，我并不会这么建议。因为在实际项目中，即使你成功做了一套相对完善的组件库，开发、测试那边也需要花费庞大的时间成本来coding和解决bug（键盘下面的大刀止不住了），时间紧凑的情况下一旦没有顺利推动，很容易沦为死项目。现有的第三方组件它不香吗？

当然，如果你有幸碰到了愿意给排期的产品小姐姐，和愿意配合你的开发小哥哥，在他coding完之后请务必善意得提醒他进行封装以保证组件的顺利落地！

2.标注

我知道蓝湖、Pxcooker、Zeplin这类堪称神器的标注软件，的确将我们广大设计师从手动标注和切图的水深火热当中解救了出来。但是，我们如果仅仅将视觉稿往蓝湖上一扔了事，那么无疑增加了视觉还原度下降的风险。

因为，标注软件只负责自动生成所有元素的尺寸、样式，但是开发不知道应该看哪个，尤其是toB项目中一些涉及到表单填写的复杂页面，即使在你已经将所有字段长度设置好足够空间，每一处间距都用规律的4倍、8倍去进行规范，开发仍然可能漏掉一些关键尺寸，OR没有足够耐心查看每一处的尺寸，写完div后用“差不多”的感觉去搭建元素。最后粗看之下还行，但是一旦上了测试环境，很有可能就出现视觉灾难。

因此，一些关键页面我依然建议做些额外的手动标注，主动告诉开发：哥们这个地方很重要麻烦按这个来。而且这个过程对于设计师来说也是个回头审查自己视觉稿的好时机。

举个

这是之前Drop shipping项目中的list it to store弹窗，它属于用户进行刊登商品的核心模块，同时也是很有代表性的字段繁多的复杂表单。视觉还原过低不仅仅会影响到本身的视觉效果，更会影响到后续的用户转化。

降低这种风险的最好办法，就是手动标注，并且为特殊情况制定规则。

根据我们之前所讲的开发工作逻辑，所有的元素都可视为盒子。而盒子的标注尺寸看元素自身属性，比如固定尺寸的img，就直接加上overlay。而可变的字段，就根据字段的重要程度以及通常情况下的平均长度去做盒子。

比如sku code和价格这两个字段——在查询了需求文档后，我知道了相比sku code，价格是用户衡量自己可赚利润的重要字段，因此我为价格的盒子预留了更多的宽度，避免频繁出现折行降低它的可读性。（查询需求文档是个很方便的办法，不限于字段，任何功能及信息你都可以从中检索到）

另外，根据页面是否需要响应式以适配触屏端，标注方式也需要规定是固定数值还是百分比。

这是手动标注后的弹窗，由于适配的要求，盒子尺寸均以百分比进行标注了，但是我希望每个盒子之间保持一个安全距离，因此盒子之间的margin均以固定数值进行标注。

另外，标注本身也共享了样式，以绿色解释间距、红色解释块面及尺寸，黄色解释样式，以此帮助开发更快得获取信息，更好得提升视觉还原度，减少后续的沟通成本。

3.走查

我们并非在完成视觉稿的交付后就可以拍拍屁股走人，即使你的视觉规范、标注多么完善详尽，开发的coding过程依然会出现很多不确定性。而设计师所要做的就是积极得跟进走查，主动推进项目的顺利进行。

我根据以往的经验，将走查分为三种办法：

（1）即时软件沟通法

一种很方便但不适合长期使用的办法。虽说可以在截图中做标记帮助开发理解，但是很多时候开发忙着coding，来不及进行回复，而且这种本地化传输式的走查也很容易被聊天记录所淹没。

（2）小板凳大法

直接拉个小板凳坐在开发旁边盯着改。

这是当之无愧最为高效的走查办法，不过这个办法也有弊端，一来很多地方并不是改个margin padding那么简单，涉及到一些底层逻辑、bug问题时往往要花费很久，我们也很难一直坐在旁边暗中观察；二来给予开发过多的心理压力，很容易引来开发键盘下的40米长大刀。

当然，如果是紧急需求或者多次沟通仍未修改的情况下，大胆得去使用这个方法吧！

（3）共享文件法

根据开发同事的反馈，他们其实相当不太喜欢那种间断式的走查，一会改下这个一会改下那个。因为开发在写代码时需要高度集中注意力，一旦多次被打断要求修改很容易降低coding效率。因此，将页面中所有问题罗列到一个文档中是他们乐于接受的办法，他们可以暂时放下，找一段时间集中进行修改。

一般我目前的走查流就是，标记-罗列-交付-复查

标记：在开发写出的页面中，将出现的问题用单个序号标记在对应的位置上并共享到蓝湖。因为仅仅局部截图说明的话，开发并不能立刻找到问题在页面中的精确位置。而如果将所有问题详细罗列到页面对应位置的话，就会造成可读性的严重降低。

罗列：将单个页面的所有问题按照标记序号，依次罗列到一个文件中。如果一些位置光凭标记不便于理解，完全可以再进行局部截图（比如序号4的弹出气泡）另外，根据开发习惯将样式设置为最低优先级，因此我会将涉及底层逻辑、功能类的bug问题标红，让开发一眼就能看到并优先处理这些问题，最后进行样式的修改。

承载问题的文件可以是sketch等设计工具的画布，也可以是语雀、腾讯文档这类的共享文档。

前者直接上传到蓝湖的项目中，方便开发直接对接视觉稿，但是视觉会有较多的排版工作量；

后者免去了上传这个步骤，团队每个人都可以方便得添加走查意见以及批注，只是开发需要较频繁切换界面；

文件的选择看每个人的习惯，但是多设计师的情况下需要尽量保持统一。

交付

将问题共享给开发，并且主动告知他，如果有任何疑点、或者难以实现的地方，可以直接在标记气泡旁进行批注。

另外，我们不一定将所有页面验收完再交付，完全可以先将一两个页面问题交付给开发后，我们这边在同步进行其他页面的走查，以此主动推进项目的进度。（我一般是按人头对接，走查完开发A的页面交付给A，再走查开发B的页面）

复查

开发完成修改之后再进行第二次走查，并根据之前所罗列问题的修改程度进行标记状态的更改。我这里直接用了measure插件的样式。红色即新增，黄色即未解决，绿色即解决。