前言

前段时间，公司对某个重要功能进行了改版。本来，这次项目设计时候感觉还是比较顺利的，可是一到设计验收环节，就发现了很多问题，有些甚至是非常基础的问题，和开发沟通修改起来简直是费时费力。

回顾这么多年的设计生涯，至今没有做一个项目，能所有页面都100%还原设计稿。有些开发可能不太理解，为什么设计师这么重视设计还原度？有句俗话说的好：“开发还原不仔细，设计再牛没意义”。就算设计图做得完美无瑕、美轮美奂，开发还原不出来，上线后用户看不到、用不好也没有意义。所以，从某种角度上来说，设计验收真的非常重要。

一、问题百出的设计验收

在日常的工作中，很少有一次设计验收是非常轻松的，或多或少都会遇到各种问题，看看以下问题你有没有在工作中遇到过。

问题一：开发对设计稿不理解

开发同学在实现页面时，对设计细节、设计意图理解有偏差，将开发目标主要集中在实现功能上，能用就行，忽略了设计细节。以至于验收时，界面带着各种各样的基础问题，影响产品的整体用户体验。

这个问题的原因，一方面可能是设计同学自己图省事，对需要注意的地方没有单独标记和说明，对界面的多个状态的样式没有展示清楚。所以开发同学就会按照自己的理解去实现页面，也就是边猜边想这里该怎么实现。到验收阶段，设计才发现这里不是自己想要的样式。如果功能比较复杂，这时改又比较困难，不一定有足够的时间给开发，重新写一遍开发也不太愿意，所以就会有很多问题被搁置。

另一方面是，交付给开发时设计没有进行自查。靠谱一点的开发会过来问，为什么左侧的间距是30px，右侧就变成了32px，故意吗？听到开发这么说，是不是有点尴尬，这种设计问题就是设计的锅，怎么狡辩也没用。而且这种问题出现多了，开发还会给你打上不专业、马虎的标签，大大降低设计话语权。

问题二：开发同学不配合

有时候，让某个开发同学改某个界面，说了半天一直都没有改。这个原因除了开发偷懒，也可能是以下几点：

1. 设计验收时间太靠后，此时要么开发时间不够了，要么产品也在验收，提交了一些功能性bug。开发看到功能bug和设计问题，大概率是先去解决功能bug，优先保证产品能用。然后设计问题就被延后了。

2. 开发认为完美还原设计稿没有那么重要。他们觉得差那么几个像素也还好吧，设计师至于那么抠细节吗？可是好的设计，正是一点一点的细节所组成的。


3. 设计时没有考虑开发能否实现，以及实现的成本。觉得开发就应该按照设计稿来写，写不出来就是能力不行。有的人甚至还和开发说：“看看人家大厂都能实现出来，你怎么就实现不出来”。这种低情商的话，开发只会翻你个白眼。导致关系变差，以后能实现出来也不给你实现。换位思考一下，如果开发说你：“人家大厂都能画出来的图标、插画，你咋就画不出来，还画得这么丑。”你是不是也不高兴。首先不同人的实力不同，大厂的平均实力都比较强，中小公司的开发有的实现不出来也很正常。另外也有可能实现起来很费时间，排期的时间不够用。所以我们的目标是想方法解决问题，不是怼人、冒犯别人。

问题三：设计师验收不仔细

有的设计师要说验收页面，也验收了，问题呢也发现了一些，但是问题总是找不全。开发按照设计提的问题改了一遍后，问是不是可以了，结果又发现了新的问题，还得求着开发一遍又一遍地改。

上线后的界面还是有点问题，要么提示反馈没有显示，要么图标或文字变得非常小、要么文案增加了多余的标点符号或语气词，甚至有的交互方式都没有按设计稿来，总是出现一些比较基础的问题。

这个问题的原因，可能是在产品开发环节中，设计师工作非常忙，接了多个需求，或者多个项目。导致设计师在验收阶段没有足够时间，大致看一看就完事了，设计验收草草了事。

问题四：缺少设计稿

这对设计来说可是非常严重的大问题，这锅得自己主动背起来。开发主要依据设计稿评估开发难度和排期。如果在设计验收阶段才发现缺了设计稿，这时候补，开发只能说加时间吧。整个项目都可能延期，这个责任可太大了。

问题五：口头说验收问题

在不少中小公司，设计师做设计验收时，只是跑到开发工位，口头和开发说哪里有问题。开发听你说问题时，频频点头，说：“知道了、知道了”。


但这种方式很容易出问题。往往你说了10个问题，开发只记得了7个，改完只改对了5个。你去找开发，说怎么还有3个问题没有改？开发说你没说这里要改，这时真的是百口难辩、死无对证。这种方法只会导致重复返工，影响工作效率。

当然了。也有人发现了这种问题，稍微优化了一下。就是搬个小板凳坐在开发旁边一边说一边看他改，做到指哪改哪。但这也仅限于小公司，开发人数比较少的时候，当你对接多个开发时，就十分影响工作效率了，开发自己还有别的事情要忙、别的bug要改，当场不一定能马上改UI，这也只会影响开发的时间进度。

问题六：让开发去找设计稿、看标注

有时候，设计师发现了设计问题，会让开发自己去找设计稿，看标注的正确数值或位置。但这样依然容易出现返工，开发很可能看了但没看对，或者看了但看错页了。


举个例子，设计稿上标注了某个位置的间距是10px，开发第一次没写对，写成了15px。第一轮验收后，设计师告诉开发你这里的间距不对，去看设计稿标注。开发区看了，可能看差了，这个位置间距改成了8px，让你再验收。你一看怎么还不对呀，让开发再去看设计稿，开发说我看了啊，就是按照你设计稿来的。这时，沟通和修改就十分低效了。

我们要理解开发不是设计师，没有像素眼，对一些细微的设计感知不清楚，也不是很在意。此时，我们需要直接告诉他们具体数值，就能避免这种问题。

三、体系化的验收机制

针对以上问题，对应的解决方案，在短期内能解决单一的问题。但是，要想设计验收长期少出问题、提升整体验收效率，还是需要体系化的验收机制。


体系化的验收机制，可以规范流程、规范人的行为来从根本上提升效率。为此，我们需要在整个项目流程的五个阶段做出调整和改变，分别是：设计中、交付前、验收前、验收中、验收后。

3.1 设计中

3.1.1 建立设计规范

在设计产品时，有完整的设计规范十分重要。设计规范可以让界面遵循相同的规则，有助于不同设计师设计同一产品时，设计稿到线上页面有一致的设计语言。开发也能按照相同的规则去写页面，不用思考每个细节又和之前相似的页面有什么不一样，提升开发效率和界面还原度。在文档中，可以展示字体、颜色、组件等等在页面中的实际示例，方便其他设计师和开发理解规则。


设计时，需要了解有哪些开发组件可以调用，尽量使用现成组件，避免重复造轮子。如果没有，则需要重新设计组件，并评估设计新组件的成本，预留足够时间去制作组件，避免延期风险。

3.1.2 输出完整的设计稿

我们在向开发交付设计稿前，需要准备完整的设计文件，包括：切图标注、页面的多状态，适配规则、动效文件和标注、视频文件等等。尽量避免在开发过程中临时补充、调整，开发还要重新评估开发量，影响开发同学的时间进度。

下面，举例一些输出设计稿时常常被忽略的问题，看看你有没有出现过：

1、点击区域没有标注

下面是app中常见的一种模块，有3个功能入口。每个如何包含图标、标题、副标题这些元素。一般设计师画完模块都会直接给开发。

问：开发会怎么写点击区域（热区）？
A、开发可能把点击区域写在：图标上
B、开发可能把点击区域写在：图标和标题上
C、开发可能把点击区域写在：图标、标题和副标题上


想一想，哪种是对的？


其实都不对，以上选项都会因为点击区域过小，导致操作不流畅的问题。像这种模块，一定要扩大点击区域，且向开发标注明确具体热区范围。不然，遇到一些经验不足的开发，就会按照自己的想法加热区，出现以上ABC三种情况。在设计验收时，也会增加不必要的验收成本、降低验收效率。


虽然现在我们都是用各种自动标注工具，但是点击区域的位置和大小，还是要专门手动标注一下的。

2、文案布局规则不清晰

下面是一种常见的文案列表，有标题和辅助文案两个元素。标题一般较长，是两排文字，设计师就按两排文字出了设计稿交付开发。但偶尔也可能有一排文字的情况，这种情况设计稿并没有展示。

问：如果只有一排标题文字时，辅助文案的位置开发会怎么写？
A、位置始终固定
B、和标题保持固定间距，跟在标题下方

如果没有和开发说清楚的话，开发A和B选项都有可能写。这就导致开发实现的效果，有可能和设计预想的不一致。如果是有多个开发负责多个相似的模块，则相似模块会出现不同的布局样式，降低产品统一性。

3、样式兼容性考虑不足

在某个视频播放页，网络不好是会出现网络报错的提示，这时下方有一个刷新按钮，按钮使用了半透明黑色作为按钮的底色，按钮文字使用白色，设计稿使用了线上亮色视频作为默认图。


乍一看，设计没什么问题，但是视频的颜色在实际线上可是多种多样的。设计验收时，发现测试上传了一个暗色视频，半透明黑色按钮马上就消失了，看起来只是“刷新”两个字。验收时，又让开发去改样式，十分低效，而且开发会觉得你不专业。


这种因为样式兼容性不足，导致显示效果出现偏差的问题一定要避免。

3.2 交付前

前面我们聊完了设计中的注意事项，现在设计稿已经很完善了，设计领导、产品经理都已确认ok，就可以直接交付开发了吗？还不行。设计师还得对开发进行设计宣讲，或者叫设计评审。

3.2.1 设计师对设计稿进行讲解

在设计宣讲这一环节，设计师要亲自对自己的设计稿进行讲解，帮助开发理解设计意图。此时，需要着重讲解自己期望的交互方式、适配要求、动效样式、布局方式等等。开发同学在听宣讲时可能会有一些疑问，设计师也需要一一解答。


比如，由于成本问题，开发希望某些复杂交互能否用简单交互代替，问设计师能否接受。

这样，一些可以提前预料到的开发问题，都能够在实际开发前期被解决，不用等到设计验收时，发现开发的和自己预想的不一样，才开始困惑，导致重复返工修改。

3.2.2 让实际开发人员参与评审

由于一个项目可能涉及多个开发，开发不同的模块。每个人负责的又不一样，不同人对页面实现的难易程度理解不一致。如果有的实际开发人员没有到场，会导致部分模块会上其他人说能实现，后来对应开发由于各种问题却实现不了，导致修改设计、浪费时间。

3.2.3 询问开发问题

一般设计师讲解完自己的设计需求后，可以询问开发还原设计稿是否存在问题。主动提问，防止有的开发有问题，自己感觉问题不大又不说，但这有可能对设计来说是比较重要的问题。


如果开发有较大问题，通常会是：实现的技术难度较大；能实现，但是投入的时间成本过高，性价比不高；设计稿涉及全局组件改动，是否整体都改，可能会出bug。


如果开发觉得实现不了，或者无法理解某个效果。可以用线上的app效果进行展示，或者举例之前做过的类似页面，帮助开发理解和实现，以达到自己的期望效果。

3.2.4 记录未定问题

一些没有明确答案的问题，或者没有达成共识的地方，都需要记录下来找领导或相关业务方沟通，以确定最终结论。确定所有结论后，大公司一般以邮件形式通知所有相关人员，小公司以群公告形式通知，保证所有人员都能得到最终结论，并达成共识。

3.3 验收前

3.3.1 开发发现问题要及时沟通

有的开发，在开发阶段只会闷声写代码，还以为他能力很强，一点问题都没有，结果设计验收时发现写的错误百出，浪费大家时间。


面对这种问题，我们需要在开发前就和开发同学约定好，遇到还原问题、实现问题一定要及时和设计沟通，设计决定最终实现方式。而且有的特殊问题，可能只在开发时才会出现，这时就需要开发同学积极沟通反馈，切勿自作主张，影响项目进度。

3.3.2 开发自查还原度

在开发同学完成自己负责的页面开发后，可以先进行一轮开发自查。这就好像我们考试在交卷子前，自己检查一遍试题答案有没有错、有没有没写的题，减少整体错误。


可以让开发自己先参照设计稿检查一遍，也制作《简易验收表》发给他们，参照此表做初步筛查。《简易验收表》是专门为非设计人员准备的验收表，帮助设计师在设计验收前，过滤掉部分问题，减少负担。此验收表较为简单，不适合展示过于专业、复杂的验收项，编写时需考虑使用方的理解程度，尽可能减少非设计人员的学习成本和使用成本。


当然，开发不太能在此阶段找到绝大部分问题，并完成修改，但至少可以初步过滤掉一部分问题，减少后续验收的负担。

一些小公司，开发人数不多。设计师也可以尝试着给开发做“基础自查培训”，宣讲需要注意的设计细节，提升开发对界面细节的感知力。

3.3.3 测试同学需保证还原度在70%左右

有的测试由于不知道设计师需要多少时间进行验收，有时只给设计师1~2天时间完成验收，造成时间过短、问题改不完。针对这种问题，我们可以在排期阶段预估设计验收所需要的时长，然后填在排期表上，同步给测试和开发。此处的时间，可以考虑适当宽松一点，以防特殊情况。

另外，需要测试同学在测试产品时，同时需要确保界面还原度达到70%左右后，再交给设计师进行验收。为什么这么做呢？因为我们可以通过测试，将大部分还原度问题再次过滤一遍。如果，不要求测试顺带看一遍还原度或提非常早期让设计师开始验收，设计师会在界面里发现大量问题，甚至的流程都没法走通，这等于是让设计师在做测试的工作，帮忙找bug，而不是做验收工作。

设计师不像测试同学可以轻松地设置各种配置项方便测试，反复验收都会消耗双方大量的时间。让测试提前确认一遍还原度，也是为了避免发生此种情况发生，提升效率。


那么设计师在什么时候开始设计验收最合适呢？最好应该在，产品整个流程都跑通了，测试也对视觉和交互的还原度问题有所处理，依照《简易验收表》保证还原度大致在 70% 左右，没有明显的硬伤后，设计师再进入设计验收。当然这是非常理想的情况，具体还是要和测试同学沟通商量。

3.3.4 了解每个模块的开发人员是谁

需要提前确认每个模块的开发人员是谁。这样在设计验收时，可以针对每个开发的问题进行一对一地跟进，保证验收效率。

3.3.5 制定规范的验收流程

我们在开始验收前，我们需要提前制定规范的验收流程，保证验收的效率和效果。比较完善的验收流程是：建立验收文档--填写验收问题，确定问题优先级--沟通问题原因并提交问题给开发--跟进开发修改情况--上线前再复查一遍。

3.4.1 避免验收遗漏

验收时千万不要有遗漏，导致开发越改，问题没有变少反而新问题越多。设计师一定要完整、全面地验收开发产出的界面，找全所有问题。


下面，举例一些验收中容易忽略的细节问题：

1、分割线

在设计师验收时需要注意分割线问题，大多数界面上分割线都是1px，由于颜色较浅又细，有的开发很可能没有清楚注意到界面上有分割线，导致没有写，或写的颜色不对。有时分割线设计的是两边不通栏，开发可能写成通栏。

2、适配问题

设计师需要关注不同设备的适配问题，保证界面呈现效果一致。包括关键信息是否超出屏幕，是否有覆盖、拉伸等情况。


比如为了适配ios的全面屏，如果页面有吸底按钮，需要移到 Home Indicators 的上方，有的开发可能就没有去做调整。

3、特殊情况未验收

有些设计师在验收主流程之后就觉得大功告成了，但界面中的一些特殊情况往往会被遗漏，导致功能上线后用户碰到特殊情况，使用体验大打折扣。这些特殊情况主要包括：网络异常、内容较多/较少、空状态等等

4、投影

界面中的投影最好少用。一方面实现技术成本过高，即使写出来和设计稿的样式都会有一定偏差，和开发调投影，真的很浪费时间。再来安卓不同款式机型、不同新旧机型，显示的投影的效果都可能千差万别，会带来非常多的问题。所以为了节约时间，最好少用投影。

3.4.2 建立问题验收表并填写

大家在工作给开发提界面问题，是不是下图这种样子，直接发消息给开发。有的甚至发现一个问题，发一条消息。这种方式非常不好，一方面，开发自己也有其他bug要改，不能一次性处理所有设计问题，降低他的效率。另一方面，设计师做复验的时候找起问题来特别麻烦，没法跟进每个问题的修改的进度。

所以建立验收表可以帮助设计师和开发，在找问题时减少遗漏、减少理解不一致的情况。提前建立验收表十分有必要，而且以后的验收工作也可以重复使用此文档模版。


验收表需要按照一定的规则进行命名，方便以后查找。比如按照“功能-模块-时间 ”这样的规则。另外随着需求的增多，不可避免对应的验收文档也会越来越多，此时我们需要提前建立一张“验收文档管理表"，记录每个文档的基础信息（比如遗留几个问题没有改）。以便我们管理文档，以及后期有空时，针对遗留问题再逐一解决。


那么怎么制作验收表呢？


一般来说，验收表一般包括以下几个内容：负责开发、问题优先级、问题序号、问题类型、问题描述、问题截图和正确示例、原因和解决方案、跟进状态。

1、对应负责人

很多验收表第一项写序号，但这其实不是最方便的， 我们平时设计产品，服务的目标是用户，是为用户而设计。那么，这里的验收表也是一样的道理，它的用户是谁呢？一般主要是开发。验收表的第一项要写负责的人员，这样不同的开发在验收表上，先区分哪些问题是自己的，可以提升他们找问题的效率。如果第一项是序号，开发还得一个问题一个问题去确认，是不是自己负责的的部分，十分低效。

2、问题优先级

第二项需要写明问题的优先级，在时间有限的情况下，开发可以优先解决高优先级的问题，如果还有多余时间再解决低优先级的问题，这样就非常高效。


优先级一般可以分为三个等级：P0 最高优先级、P1 一般优先级、P2 低优先级。如果问题类型过多或过少，优先级数量也可根据实际情况进行增减。

3、问题序号

标明问题序号，可以在沟通时方便定位问题，提升沟通效率。同时也能判断此次项目，开发还原设计稿的质量如何。


比如，这种对话就很高效：
设计师：第8、12个问题没有改是怎么回事？第20个问题改的不对。
开发：8、12太复杂了时间不够，20我再看看验收表。

4、问题类型

我们在设计验收过程中， 问题类型可以帮助对应问题的负责人快速判断问题情况，高效处理。通常问题类型可以分为以下几类：视觉问题、交互问题、技术问题、运营问题、产品方向问题。

5、问题描述

问题描述一定具体，这样对应负责人才能明白到底是什么问题，以及判断可以怎么改。千万不要使用类似“不对”、“不好看”、“不一致”、“不符合”等模糊性词语，对方也不知道到底出了什么问题。

6、图片描述

图片描述主要指问题位置的截图和设计稿的正确示例。图片能更直观的呈现问题，方便开发确定问题位置并进行对比。


问题截图需要标注出问题的具体位置。如果单截整个页面的图没有标注位置，开发也得慢慢找问题在哪，也有可能找错位置，降低解决问题的效率。


有些问题可能截图说明不清楚，比如一些动效实现不对。可以录制视频或gif发送给开发，帮助定位问题。

7、原因和解决方案

一些改不了的问题需要写明原因。比如：一些难以改动的全局组件、由于历史原因改不了的问题、修改问题的时间不够等等。如果设计方案有调整，也要在这里写明调整原因。


问题的解决方案需要写具体。如果是样式问题，不要直接写“参照设计稿”，需要具体给出正确尺寸、增加多少、减少多少、具体用哪个色值等等。这样可帮助开发提高修改效率，避免开发自己去看设计稿，看错又要返工的问题。

8、跟进状态

主要描述要解决的问题怎么样了。通常可以分为：跟进中、已解决、未解决。

3.4 验收后

3.4.1 跟进修改进度

之前，某个开发的领导和我聊过，有的开发就是比较懒、比较慢，你得盯着点他们干活。所以，设计师需要及时督促开发完成问题修改，如果开发长时间没动静，主动问问是什么情况。

3.4.2 记录遗留问题

工作中不太可能每次提出的问题全部都能改完，遗留的问题需要在验收表中有所记录，是实在改不了，还是时间不够等等。一些可以改，但是来不及改的问题，可以下次开发时，提醒开发同学一并改完，让他们排期时多预估一些改遗留问题的时间。

四、总结

以上，就是我总结归纳的一些设计验收经验。如果在整个流程早期，比如设计阶段，做得越好、越细心，后期验收就会越轻松，大家可千万不要懒呀。希望本次的验收方法能帮到大家，谢谢~