一、设计师出完设计稿就完了吗？

当然不是！上线前还有个UI验收的工作。

为什么要验收？

验收可以保证线上的效果和设计稿更加吻合，因为上线后，没人会去看你的设计稿。在线上发现视觉问题，可能下意识的认为就是设计师没做好！那么不验收的你，就特别自然的背上了一个锅！

验收范围是什么？

1，很明显的视觉问题

如：间距、大小、颜色

2，交互问题

小问题如：按钮hover没变色，  文字超出范围没有...   有...的情况没有浮层显示全部内容

大问题如：列表页，页面超出滚动时，表头没固定，无法对应看信息

3，偶现问题， 在某个电脑上才能看到的问题 

如，在1920X1080的分辨率下，看不到页面底部的按钮

4，适配问题

如，需要按百分比的宽度，写成了固定宽度， 那不同屏幕上，看的效果差异很大

二、如何提高开发对设计稿还原度的重视？

一般情况下，开发时间紧迫，往往时间都花在功能搭建和bug的修改中，UI还原问题是他们最无暇顾及的环节。

我们要做的，是将UI验收流程规范化、标准化：

1，首先要把验收这个环节通过项目经理，安排进整个项目流程里

2，明确UI验收时间和测试们的验收时间是同步的

3，明确告知验收标准：还原度90%及以上为达标，低于90%不达标

4，不达标就属于风险项，要发邮件抄送全员和相关部门领导，做风险报备。

5，发邮件同时，@开发负责人，请他安排人员继续跟进。

三、大家都是怎样做验收的？

我见过很多种验收方法：

1，Excel问题列表 

（缺点：截图放Excel里很难看清）

2，Word版/ppt问题描述+截图

     根据尺寸，APP验收适合用PPT来做问题汇总、web端适合用Word来做。

  （缺点：此验收方法，虽然美观，但是花费时间很多，时效性差、问题数量汇总也有点麻烦。）

3，公司内部项目管理系统，问题上传。

（缺点：流程繁琐，花费时间很多，时效性差）

测试一般是用这个方法的。但是对于UI设计师来讲，挺痛苦的。 

痛苦在于：添加一个问题，你必须填写8-10个必填项。

例如：

版本号、当前阶段、问题所在模块、问题描述、问题截图、优先级、发现人、发现阶段、指派给谁、完成时间、验收人是谁

一次验收，如果模块较多，可能有100+条问题。 你想想你要点多少下，才能记录下这些问题。

兵贵神速，尤其是快上线的时候，你不快点把问题反馈给开发，他们怎么改呢？

四、多轮截图验收法

插播一下：亲身经历，友情提示

1，验收前要先清空缓存，有些前端改的内容，你不清缓存看的还是旧的。（谷歌-右上角三个点icon-更多工具-清除浏览数据）

2，浏览器看一下，缩放尺寸是不是100%（这个验收登录页或者大屏等一屏内容时，不同电脑分辨率下，要格外注意）

OK，回来~

下面这种方法，是我们组现在在用的。投入实践几个月了，简单粗暴，但传达问题简洁易懂，时效性高，特别适合以结果为导向的设计师使用。分享给大家，供参考。

验收分多轮进行，每一轮一个文件夹，完成一轮就发给开发，开发改好后，进行下一轮验收。

截图要求：

（1）框清楚路径：（怎么才能找到这个问题页面！前端要找到对应的页面才能改）

（2）问题框出后：

        简单的问题直接写出修改建议：XX改为XX，  

        问题复杂的，框出有问题的地方，然后写：请前端参照蓝湖修改

（3）一个截图说一个问题，多个问题，截多次分别提（后期汇总数量好汇总，也防止页面上有两个问题，开发只          改了一个，不知该怎么处理的情况发生。）

（4）能用代码直接调的数值，可把代码数值直接标注出来

五、第一轮问题改好了，如何进行下一轮验收？

1，先把第一轮的文件夹复制，改名为第二轮

2，然后以第二轮为主，复查。改掉的问题直接删掉，发现新问题，继续新增。

例如：

一共10问题。1-7改好了，删掉，8-10保留，名字不要改。新问题截图从11开始依次排序 

好处：最后能从序号直接看出，这个模块一共多少个问题，方便算数汇总。

六、全部验收完毕，要干什么？

要汇报结果：

1，不达标就属于风险项，要发邮件抄送全员和相关部门领导，做风险报备。

2，达标的需要发验收结果报告，抄送全员。例如：

3，公司有问题记录系统的，例如我们公司是“神兵”，那么就把所有剩余的未解决问题全部传神兵。如果没有的，就放到下一个版本的验收文件夹里，以便后续跟进。

还原度评分是怎么算出来的？

我们是这样的，最高97分封顶，一个稍大的交互问题扣3分，一个视觉/交互小问题,扣一分。

95以上，优秀

90以上，达标

90以下，不达标

后来，我们形成了一套，富有情感化的汇报规范。为了肯定前端同学的努力！

95分以上，我们给予 优秀奖章

90-95分，给予达标奖章

低于90分，灰色不达标

并艾特负责人，罗列未修改问题，抄送相关人员

到此，验收工作就结束了！

虽说没有那么多细致的验收文档，但是验收反馈时效性很高，

UI验收，我们更看重结果，所以目前此方法对我们来说是更适用的。

tips：验收时，怎么能完整的验收，不遗漏？

1，设计稿设计时，流程、页面、各种交互状态、就要全。

2，做好第一点，你只需要按照设计稿上的内容，一张一张校对。视觉上是否准确、交互效果是否缺失。

  （例如：按钮hover状态，滚动条hover，tips气泡宽度等问题）

3，很多时候会有没数据，或者状态不全的情况，需要截图单独放一个文件夹里，起名：找测试造数据。

     这样你就知道自己哪里还没验收，最后单独对这些问题进行复查就好。

4，web端以用户主流屏幕测试，APP端需要多机型测试，一般是iPhone8，iPhoneX ，和安卓系统手机2台

tips：对本公司商业小组组员的提示

1，列表中（包含自定义列的，就是列表共有20列，但是现在只显示了10列，那么要把剩余的内容也都选中，展现出来，再一起验收，否则每列的显示内容、列表宽度验不全）

2，神兵（和开发协同，用来传缺陷的系统），L1 为阻断性缺陷、L2 为较严重缺陷。 UI可提 L3（较大视觉问题、交互体验问题）, L4级别（视觉小问题，间距，字号，颜色等）的问题。

3，L3级别的问题，发现需和产品确认，确认无误后需先上传神兵，以便开发跟踪修改。L4级别的问题，通过文件夹发送开发修改。

4，神兵上传问题命名规则：【ui-模块名称】- 简单的问题描述