我们公司前段时间进行了3.0项目的开发，本次项目的进展整体上还是比较顺利的，但是还是遇到了很多小插曲，其中最让人崩溃的就是验收环节，简直就是跟技术的一场拉锯战。当然这场战争的始作俑者并不是某一方，而是每个角色身上都有各种各样的问题。今天就想来客观的陈述一下整个过程，希望在下次进行项目推进的时候可以有所改进。

目录：

1. 我们遇到的问题及解决方案；

2. 提升技术更改Bug的要点；

3. 那些容易出错的地方。

一、我们遇到的问题及解决方案

前提：之前我们公司对设计还原度要求很低，且技术有较高的话语权，他们就觉得UI界面不重要，所以之前我们是没有设计验收环节的，界面的问题提上去也是石沉大海，我们每次进行设计验收都很沮丧，也不会特别抠细节。

但是最近公司高管有了很大的变动，新来的CEO、CTO和产品总监都对设计要求特别高，当然也就特别看重线上效果，所以就有了这次正式的设计验收环节。

首先，我想总结一下我们在这次验收中遇到的几个主要问题：

1. 技术同学对设计稿的理解度不够

首先检讨一下设计同学的问题，为了图自己省事，直接用Sketch Measure 导出标注文件给到技术了，对于有适配需要的地方也没有进行单独的标记和说明。所以技术同学就会按照自己对页面的理解进行布局，到验收的时候设计同学才发现不是自己想要的结果，这个时候要改动的话就会比较困难。因为一开始的框架就不对，技术也没有时间重新写一遍，所以就会有很多问题被搁置。

直接导出的标注对界面的准确性要求也特别高，你必须保证所有的界面都准确无误，不然就会遇到开发者提出的来自灵魂的质问：“为什么这里是15px，那里是16px，两边不一样，究竟让我们怎么写？”

听到这句话是不是有点不服，但是就是你错了呀。所以时间允许时还是要手动标注，不但可以减少这种质疑，在标注的时候还会对页面的细节进行盘查，会发现一些遗漏的状态和缺失的细节，这样下来最终提交给技术的设计稿会更加完善。

再者，缺少设计稿评审的环节，这个环节主要给技术讲述一些适配要求、交互状态及动效（我们公司近期撤了交互岗位，所以交互的相关工作需要设计同学进行考虑）；同时解答技术同学的一些疑问，这样就能将一些可预见的问题解决掉，解决后期的沟通成本。

解决方案：

1. 时间允许，尽量进行手动标注/时间紧张需要适配的地方单独标记；

2. 技术开发前进行设计稿评审。

2. 设计稿的缺失

这个首先当然是设计师的失责，因为我们提交给技术的设计稿的第一要素就是完整度，到开发进入尾声才发现缺失，那技术同学只有说“对不起，排期吧”。然后设计同学还一肚子委屈，觉得开发不配合。

下面是设计稿中常见的缺失内容：

1. 页面极限状态：无内容、无网络、加载中；

2. 页面交互状态：上滑导航栏固定的样式、社交操作的交互状态、下拉刷新样式、按压状态等；

3. 页面适配：文字的极限情况、屏幕横向竖向的适配、X和Android等各种极限机型的适配。

这些都应该是在出设计稿的时候就考虑清楚的问题，因为技术是根据你的设计稿进行技术排期的，如果你的页面不完整，后期再增补导致项目延期，这个责任在谁呢？

3. 技术同学的“不配合”

这里的不配合不是说技术同学偷懒不想干活，原因是多方面的：

1. 设计审核时间太靠后，结果就是在我们提交UI问题的时候，产品也在提交功能型的bug，那技术同学同时拿到这两个问题，按照问题的优先级来说肯定是先改功能性问题，然后你的问题就被搁置了。

2. 技术没有完美还原设计稿的意识，还是觉得这件事情没有那么重要，所以觉得设计师抠像素就是跟他们过不去一样，其实我们也很无奈，因为设计稿就是一个像素一个像素抠起来的呀。

3. 设计的时候没有考虑开发的可实现性和实现成本，所以就觉得开发应该完全按照自己的设计稿做出来，做不出来就是不配合，设计师尤其爱说“你看XX大厂能写出来，你咋就写不出来呢”，这是极其自大且没有情商的一种表现。首先大厂的技术团队实力理论上是比小公司要强；另外我们也要倾听技术同学的声音，他们也许是因为排期紧张而做不到呢，所以在批判别人之前要首先想想自己的问题，看到客观存在的问题，然后一起寻找更好的解决方案。

解决方案：

1. 提前进行设计验收，最好是提前知道模块的开发者，这样后期一对一进行模块的打版验收效率更高；

2. 设计时考虑开发成本和可实现性。

4. 设计验收不完整

之前没有完整验收的经验，所以我们基本上是看到哪里是哪里，没有一个系统的验收框架，这样就会导致在验收的时候会有缺失，然后会被其他同事发现还挺尴尬的，测试是由测试用例的。所以我们也应该输出一份设计审核清单，对照表格进行验收，才能避免遗漏。

5. 通用样式未进行组件化开发

从源头来说这个是我们自己的问题，因为没有将通用模块进行组件化整理。同时技术同学也没有这个意识（或者是组内配合度不够），因为我们本次项目是视觉升级，所以有些模块的开发者会根据设计稿新出，有些是直接调用之前的样式，这样导致的结果就是不同模块的弹层样式不一致的尴尬结果。

解决方案：

通用模块样式进行组件化整理，比如Toast、对话框、错误提示等。协助技术进行组件化开发。

提升技术更改bug效率的要点

1. 不要只是告知技术错哪里了，而是直接告知技术更改的方案

比如说图片尺寸错了，有些设计师就直接标注出来说这里出错了，请参考设计标注重新调整。另一个设计师不仅标注哪里错了，还直接标出这个图片尺寸是多大。很明显技术看第二个设计师给的验收文档更改的效率更高。