为什么视觉还原很重要？

在我们工作的实际项目中，直至开发扣完最后一行代码之前，UI所输出的视觉稿其实并不算是产品的最终形态。一个设计师输出90分的视觉稿，如果视觉仅仅还原了60%，即使设计师的能力再牛X，在用户甚至是面试官的眼里，54分就是这位设计师的最高水准了。视觉还原，不仅仅直接影响着产品本身的“面子”，更影响着设计师的“里子”。

那么，在实际项目中到底该怎么保证视觉的完美落地呢？下面我基于目前的项目经验，简单谈谈三个老生常谈、却极为重要的核心步骤——规范、标注和走查。

规范

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

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

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

一份设计规范应至少包含颜色、字体、图标、排版以及诸如按钮、表单、弹窗等方面的组件，并且你需要尽可能考虑到它们的所有状态。在定制好规范后统一上传到蓝湖等协同软件（尽可能避免本地协作），方便开发一键查看和复制。后期一旦有新增或者修改，立刻通知所有参与的开发进行修改，减少后期的走查次数和沟通成本。

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

请务必拉上开发！

因为只有开发自己知道，目前库里有哪些封装好的组件，样式根据视觉调整下可以直接使用，而不是你哼哧哼哧得搞完一套全新的组件库让开发埋头Coding，开发会磨刀霍霍向“牛羊”的。。。

一般我会从以下三个方向确立组件的定制计划：

1.自有组件

检查开发手头有哪些之前项目就写好的组件，全不全？是否需要新增？样式和现有项目是否匹配？好不好修改？因为毕竟很多老组件按今天的眼光看已经过时了，这些都需要我们视觉来审核。

2.第三方组件库

如果自由组件你嫌它太丑、觉得即使改也要花费很多时间，那就可以考虑第三方组件——Ant、Element或者iView。作为设计师，个人比较喜欢使用Ant design资源很全，下载的sketch源文件基本能满足大部分通用功能，很多控件（比如：各类选择器、穿梭框等）的视觉与交互体验也相对较好，可直接复制组件粘贴至设计稿中。但前端同学更倾向于【Element】组件封装简单容易修改，对于没接触过框架的同学也方便上手无障碍。【iView】的组件封装过于严密，且收费，不太喜欢用。

3.DIY

如果你是比较倔强的设计师，并且开发没有带刀的习惯，那你可以选择自己用设计软件去DIY一套组件库让开发Coding并封装。具体的样式、规范可以参考Ant这种优秀的语言。当然，在时间不是非常充裕的情况下，我不会这么建议。因为在实际项目中，即使你成功做了一套相对完善的组件库，开发、测试那边也需要花费庞大的时间成本来Coding和解决Bug（键盘下面的大刀止不住啦，时间紧凑的情况下一旦没有顺利推动，很容易沦为死项目。现有的第三方组件它不香吗？当然，如果你有幸碰到了愿意给排期的产品小姐姐，和愿意配合你的开发小哥哥，在Coding完之后请务必让他进行封装以保证组件的顺利落地！

标柱

我知道蓝湖、Pxcooker、Zeplin这类堪称神器的标注软件，的确将我们广大设计师从手动标注和切图的水深火热当中解救出来。但是，我们如果仅仅将视觉稿往蓝湖上一扔了事，那么无疑增加了视觉还原度下降的风险。因为，标注软件只负责自动生成所有元素的尺寸、样式，但是开发不知道应该看哪个，尤其是toB项目中一些涉及到表单填写的复杂页面，即使在你已经将所有字段长度设置好足够空间，每一处间距都用规律的4倍、8倍去进行规范，开发仍然可能漏掉一些关键尺寸，OR没有足够耐心查看每一处的尺寸，写完div后用“差不多”的感觉去搭建元素。最后粗看之下还行，但是一旦上了测试环境，很有可能就出现视觉灾难。因此，一些复杂的关键页面我依然建议做些额外的手动标注，主动告诉开发：哥们这个地方很重要麻烦按这个来。而且这个过程对于设计师来说也是个回头审查自己视觉稿的好时机。

走查

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

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

（1）即时软件沟通法

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

（2）小板凳大法

直接拉个小板凳坐在开发旁边盯着改。这是当之无愧最为高效的走查办法，不过这个办法也有弊端，一来很多地方并不是改margin、padding那么简单，涉及到一些底层逻辑、bug问题时往往要花费很长，我们就很难一直坐在旁边暗中观察；二来给予开发过多的心理压力，很容易引来开发键盘下的4 米长大刀。当然，如果是紧急需求或者多次沟通仍未修改的情况下，大胆得去使用这个方法吧！

（3）记录文档法

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

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

1.标记

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

2.罗列

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

承载问题的文件可以是Sketch等设计工具的画布，也可以是语雀、腾讯文档这类的共享文档。前者直接上传到蓝湖的项目中，方便开发直接对接视觉稿，但是视觉会有较多的排版工作量，后者免去了上传这个步骤，团队每个人都可以方便得添加走查意见以及批注，只是开发需要较频繁切换界面，文件的选择看每个人的习惯，但是多设计师的情况下需要尽量保持统一。

3.交付

将问题共享给开发，并且主动告知，如果有任何疑点、或者难以实现的地方，可以直接在标记气泡旁进行批注。另外，我们不一定将所有页面验收完再交付，完全可以先将一俩个页面问题交付给开发后，我们这边在同步进行其他页面的走查，以此主动推进项目的进度。（我一般是按人头对接，走查完开发A的页面交付给A，再走查开发B的页面B）。

4.复查

开发完成修改之后再进行第二次走查，并根据之前所罗列问题的修改程度进行标记状态的更改。尽量在第三次走查时让标记们全部消失，否则就放心的使用“小板凳大法”让开发修改吧！

最后

虽然是三个老生常谈的东西，但是一定程度上的确能够有效保证我们的视觉还原度！但愿不成熟的分享可以帮助到你~

Powered by Froala Editor