2023年B端设计师如何做好还原度走查

B端设计师，如何做好还原度走查写在前面

作为设计师，你肯定遇到过这样的状况，自己做的设计稿，被开发出来后却完全换了一个模样。不仅视觉上有问题，交互上也有错误。而要想避开这样的状况，我们就肯定要重视还原度走查这个阶段。

它是我们产品上线前的必要保障。虽然测试同学会关心我们验证一些流程上的问题，但更多的还原度细节问题，比如交互和字号间距等，则更多依靠我们设计师的来检查。而在还原度走查的过程中，个人认为主要分为以下几个部分：

一、还原度何时开头

经过对比验证，发觉还原度在测试进行第一轮测试后进行，效率和时间能够最大化。

缘由如下：

第一轮没结束前，许多功能性bug会存在，假如介入过早，很难跑完全部流程，加大还原度介入难度。一些明显的交互和视觉问题，测试团队在第一轮是能够发觉的，也能削减一部分工作量；假如等bug解决得差不多，可能都二轮后了，这时候才开头走查的话，那么留给设计师的时间就会特别少，由于结测的时间已经固定，这可能导致开发可能没有足够的时间修正问题。

二、还原度检查内容

当我们拿到开发提测的版本后，应当针对于哪些内容进行检测呢。本人认为可以整体检查可以分为以下3个部分：

2.1整体流程

当我们拿到产品后，第一时间可以看下我们的整体的流程是否有遗漏，整体流程是否能够跑通。

首先需要确保我们的产品没有大的流程问题后，这个时候就可以开头细节的部分。避开某些大的流程被忽视，这往往需要更多的开发量，越早提出来开发就越早介入修改。

虽然这个过程基本都会被测试团队在第一轮的时候查验出来，但为了避开有遗漏，我们最好还是先把全流程跑一遍以避开发生问题。

2.2交互内容

当流程跑完，这个时候我们就可以进入到交互细节的检查。一般来说我们在检查时主要留意以下几个方面：

A.结合交互说明进行逐条验证

一般我们的交互说明已经特别详尽，包含各类特别状态和细节交互。因此我的建议是在验证的时候可以结合我们之前的交互说明进行对比验证，避开某些部分被遗漏或者忽视。

消失问题有可能是我们的交互阐述的不够清楚或者说研发没有了解设计的规律，这些状况都是有可能发生的，因此我们在还原度验证时更需要细心验证和沟通。

B.交互说明未提及的特别状态

这其实是许多设计师常常遇到的问题。我们在写交互说明的时候不行避开会忽视某些细节点。这个时候假如消失交互说明漏掉的特别状态，就需要和开发团队进行沟通。

假如是重要且影响体验的问题，可能就需要拉着开发团队进行沟通，评估下时间进行修改；

假如是不重要且不影响的体验的问题，就可以等下个迭代或者后续再进行对应修改；同时对问题做好记录，避开下次再消失类似问题。

这同时也反向要求我们在交互说明中尽可能考虑得更加全面，才能避开多次返工。关于这块有个小建议，可以将平常遗漏的交互记录下来，形成关于自己薄弱交互环节的自查表。通过建立专属的交互自查表来强化自己对于各类状态的认知，从而将说明写得更加详尽和完善。

2.3视觉内容

视觉的还原度检查可以说是占据了整体检查的大部分内容。究竟功能或者交互还有测试团队帮忙验证，但视觉细节只能靠设计师本人来进行走查了。在这里我将其分为以下几块内容：

1.「像素眼」观看法

由于习惯问题，设计师对于字体的大小，元素的对齐有一种天生的敏感，因此对于某些比较明显的还原度问题，设计师是能够通过直接观看发觉的，比如某些元素没有左对齐。

但这种只适合许多明显偏差的元素，在大部分时候，设计师还是需要借助帮助工具来帮助进行还原度走查。

2.检查元素（F12）帮助走查

在许多时候，我们发觉某些元素存在问题，但不确定的时候，我们就需要借助检查元素帮助还原度走查。检查元素如何操作呢，可以通过右键-检查或者直接按F12来调出，通过鼠标选择元素，即可查看该元素的全部属性，包括字号、颜色、宽度等等都可以直观的看到。

利用这种方法我们可以检查得特别细致，比如某些微小的间距是否精确     ，都可以检查出来。

那么在这里我们可以简洁介绍下前端的盒子模型，也就是你在检查元素中可以看到类似盒子的元素。盒子模型是CSS中的概念。全部的HTML元素都可以看作一个盒子，是用来设计和布局时使用。它包括我们常见的边距、边框、填充和实际内容。通过了解盒模型有助于我们理解前端是如何进行页面布局的，同时也关心我们在走查时更直观地看到其中的间距和宽度等。

其实检查元素还能帮助交互状态走查，这可能是许多设计师忽视的一个点。比如我们设定了hover按钮时有灰色底块，此时我们如何验证灰色块的色值和大小是否精确     呢。

其实帮助元素也可以帮忙，如下图所示，我们通过勾选hover这个状态，界面中就会直接呈现当前元素的hover状态：

3.借助工具帮助走查

目前市面上有两种常用的工具，想必许多设计师也已经知道了。分别是CSSPeeper和Copiexl。

首先推举的是CSSPeeper。这款插件其实就是类似于检查元素，只是界面会更简洁，相比于检查元素去掉了许多干扰元素，打开后我们点击页面上的元素就能够直接看到其对应的元素属性和间距等。对于设计师群体来说还是比较友好的。

地址：/

其次款的则是字节出品的Copiexl。其对比方式会比较简洁粗暴，就是将设计稿和开发稿在相同尺寸下进行叠加对比，从而看出来有哪些区域是不一样的，从而快速找出不对的地方。教程官网都有，我这里就不进行具体介绍了。

地址：/

三、还原度如何记录

通过以上几种类型的检查，基本上都可以检查出大部分还原度问题，那么此时如何与进行沟通呢，这个时候避开以下两个做法：

直接当面找到开发，给他说许多还原度问题。由于开发在这个阶段也有许多其他工作，不仅会打断他工作，他也不肯定记得这么多细节；直接将还原度问题在谈天窗口直接发出去。通过谈天记录看还原度，不仅不便利查看，还很简单遗漏掉部分信息。

因此正确的做法是建立一份还原度文档记录表，内容包含：模块，详细问题，问题截图，问题严峻程度，解决状态，对应开发。

在这里需要留意的一点就是面对间距问题不正确时，不要直接跟开发说你去找设计文件对比下，而是直观地在还原度截图中告知他这里的正确间距，这样能够节约双方的时间，也避开开发再次看成错误的尺寸。

这样的话不仅能够清楚记录每条还原度，开发还能够依据重要程度有优先级地改掉问题，同时也可以为我们后续做校验供应支撑。

四、如何让整体变得更好

通过整体流程的梳理，不难看出还原度验证过程其实也是协作过程。因此想要很高的还原度，我们也需要在以下方面做得更好：

团队内部有严谨的设计规范，避开多设计师协作时同一控件用了不同的表现形式；注意设计宣讲和重点标注。在进研发时设计宣讲是必要的，能够让研发人员了解我们的整体设计规律以及我们关注的重点，同时我们在写交互时也可以将重点字段用不同的颜色进行标记，从而让研发人员在写得时候能够引起重视注意信息同步。我们全部的改动都需要将其同步给研发和测试人员，同时也可以在我们的设计稿上标记好更新内容，这样整体的协作会变得更加顺畅，也避开信息差导致的更新不准时。避开频繁修改，不论是谁面对频繁修改都是不太快乐的，因此我们对于已经进入迭代的设计稿，因此假如面对必要的修改时要准时同步信息。假如一些不太重要的改动也可以先放一放，后面再改。写在最终

当我们验证完毕后，记得有一份还原度报告作为最终的检测凭证