6）图标的尺寸是否合理

不管是在C端产品还是B端产品中图标的也是高频出现的一个元素，图标本身的意思就是简化文字信息，通过图形去高效地传达一个固定的文案信息。

对于图标的设计走查大致分为两点。

① 大小

我们在设计icon图标时候，会根据不同的场景进行图标尺寸的规范输出，但是在真实的开发环境当中，开发在使用我们提供的插件（蓝湖）进行icon下载时候，会提供3种icon的尺寸下载。

前端开发在使用切图时候往往会忽视掉图标的尺寸问题，对于图标的设计走查，图标使用的尺寸是否是我们设计使用的规范，所以第一个就要看大小是否能清晰地展示。

② svg格式开发

因为pc电脑的屏幕尺寸、分辨率往往是高于移动端的屏幕尺寸、分辨率，图标的切片做得太小，上传到屏幕上会出现模糊的展示效果，如果图标不能清晰地展示图标所呈现的图形，那就会造成用户一定的识别障碍。所以一定要保证图标不要有模糊的情况出现，尽量使用svg格式图标切片给到开发。

四、如何减少视觉校验的工作量

设计校验工作不能说难，但是有耐心有细心的设计师都可以完成，一遍视觉校验需要1—2天的时间，相对来说比较耗费大家的精力。

换个角度思考，如果我们从项目开发的前期就控制设计走查的工作量，那我们可能会减少了走查的工作量。接下来我们就聊一聊怎么减少设计校验的工作量。

1. 了解需要视觉校验的原因

前面我们一直讲的是做视觉校验需要校验的维度，我相信更多的设计师还是希望把精力放在做设计效果图阶段，毕竟如何做只能单纯地提高我们的校验的效率，想要在开发过程中减少对项目的设计校验的工作，我们需要清楚两个答案，一个是“在开发过程中为啥需要设计走查”和“开发不愿意修改的原因”。

1）谁负责实现样式

开篇我已经讲了设计走查的意义（原因），为啥要做视觉校验，其实和设计走查的原因差不多，但是我想从开发流程再聊一聊。在一个产品开发中，设计师下游需要对接人的人员角色统称为开发工程师。

但是在这类角色中其实也是会细分为三种角色：前端工程师、后段工程师、测试工程师。而前端工程师是我们主要对接工作内容的对象。

因为做项目多数情况是多人协作共同完成的工作，可以从上面图片可以看出，前端工程师是实现我们效果图样式的主要人员。

2）前端工程师心里所想

前端工程师的工作内容需要一一查看设计师提供的标注，然后再一一去实现，所以难免不了心里会这样所想：好麻烦，不如我自己按照感觉写。

在真实的工作中，前端开发按照规范进行项目开发这种思路是对的，但是设计师强硬地要求前端开发工程师按照规范进行开发，是过于“理想化”的一种表现。

所以我们还是要先从自身出发，循循渐进地要求前端工程师按照我们的设计规范进行开发，这就来到我们下一个话题。

2. 如何避免呢

那么接下来我们来聊一聊身为设计师我们要怎么做，才能避免进入过多的设计校验呢？

1）了解开发的实现原理

如果想成为一个高端进阶的设计师，我们要给自己增加筹码，那最为直接增加筹码的方式就是——站在开发者的视野看待问题，了解开发思维。

国内前端写样式的代码基本上是HTML+css，jacascript，注意这不算是编程，只是一个写样式的语言，简单的理解就是盒子模型（css语言）

① 盒子模型

CSS盒子模型 又称框模型 (Box Model) ，包含了元素内容（content）、内边距（padding）、边框（border）、外边距（margin）几个要素。如图：

举一个图文模块的例子：图（1）是设计师输出的设计稿， 图（2）是开发需要的标注信息（我们实际给到开发的标注），开发需要查看的就是色块的尺寸和色块之间的间距。

② 用框架化的思维做设计稿

了解完前端制作咱们效果图的原理后，我们就要用这个盒子模型的概念，像是搭建房子的原理去制作效果图，所有的组件之间都是有理有据的，这个专业术语就叫做框架化ui。

前端开发工程师通过一个个盒子填充来将我们的组件元素放入其中，最终形成前端展示的页面。

注意：标准的框架化就像前面的盒子模型是一块一块制作的，考虑到开发同学开发阶段组件的嵌套逻辑。

③ 开发者模式

如果还是不太了解盒子模型具体是什么的同学可以在线上使用下图的方法自己去查看。

设计师在视觉校验时使用浏览器就可以看到开发写的盒子，了解盒子也可以方便我们走查时知道问题在哪。具体操作步骤：

2）检查自己的设计稿

在给前端开发工程师提供设计标注的阶段，需要提前保证自己出的效果图是有效的设计方案，符合基础的视觉需求，保证模块设计的可扩展性及规范化，避免定稿后在反复修改设计方案。

比如，当我们设计产品中的搜索条件模块时候，我们需要考虑在一行展示3个搜索条件、一行展示4个搜索条件或者一行展示6个搜索条件并且放不下的情况下，效果的展示样式都应该是什么样式的这类问题。

再比如，我们设计完一个场景的设计稿之后，还要考虑不同屏幕尺寸下，这套效果图的布局是否能满足产品需求。如果不满足，那设计稿需要调整成什么样式的设计稿。

3. 做好标注文档

除了确保设计稿的可行性之外，还要做好设计稿的标准文档。如果项目是小版本的迭代，只需要进行简单的描述即可。如果是组件库的升级，那需要给前端工程师的标注文档，尽量是详细的、准确的。

包括设计稿、切图（规范的切图命名、压缩好的图片文件）标注、设计规范以及交互文档（包含字体标注）。

1）描述到什么程度

那细致描述到什么程度呢？这里我简单的说几个点。比如：

侧边导航栏在正常模式下、缩紧模式下，导航栏的宽度是如何变化的；

如有有图片信息的上传，是什么图片比例是什么，是21：9、16：9、4：3.1：1？

如果出现文案超长的信息场景，可展示的文案信息是什么样的展示？是文案后面是省略号展示？还是鼠标滑上去有气泡弹窗的展示样式？

2）图标命名的规范

随着业务增多，团队内对图标的随意命名的习惯也开始凸显出弊端，这种不好的习惯会造成同一类功能的图标会出现不同样式尺寸，所以我们在搭建图标规范时候，就可以把切片的命名规范好。

在图标规范中，图标需要有着单独的后缀，这样可以让公用图标与业务图标更方便地溯源。值得注意的是我svg格式的图标可以不用写切片的尺寸，而png的图标我建议写上切片的尺寸。

有些公司习惯于去icon进行英文的格式命名，左侧是我整理的比较高频使用的命名。

3）图标的上传

可以在开发前在与前端开发沟通达成共识。图标制作完成确认后，将图标上传到阿里巴巴图标库中，更方便前端调用图标大小和调整颜色。

如果开发需要自己去找到相关图标，也可以给予权限让开发从蓝湖上传图标（前提是得整理好图标到蓝湖上）。

4. 和前端开发工程师的沟通

虽然很多时候项目到发版本时间，验收标准在团队内部都是有明确的规划和标准，但是有些问题还需要特别分析、特别对待。这里我就列举几点我在项目有几个比较重要的点。

1）进行设计宣讲

设计宣讲最大的意义就是加深他们的印象，大家提前心里都有一个预估，把一些规范标准类的问题暴露出来，把关键核心点、规则讲清楚，为了后面减轻设计走查的工作量，开发也轻松一些。

① 用认知对齐，目标一致

如果团队内部四个角色成员大家的认知都是一致的——提升用户体验是我们公共目标。

如果不一致，那就要说服其中一个角色，最好是项目负责人，说明校验影响发版时间，如果大家都按照规范去完成自己工作内容，可提高效率。

确保大家理解一致：设计师要和开发、测试确认视觉表现层的验收内容、确保内容大家理解一致。

② 做有效的沟通

认真是前提，尊重是法宝。

在部分开发团队中，设计师也不能太过于教条地对待自己的设计标准，毕竟开发生气请假不修改了，那就真的没有人可以进行代码的修改了，设计效果更是显示不了了。在开发之前，就要和开发沟通，目前这些界面的效果在技术层面上是否能实现，针对比较复杂的界面场景，实现出来的代价有多少，权衡利弊后再确定是否按照效果图进行开发。

针对复杂的页面需要把标注标记得更加详细，并且明确告知他们，我的栅格在哪里说明、布局规范在哪里说明。在这个交涉过程中，设计师需要尊重他人工作成果，明确自己需要做的事情，把问题描述清楚就好，不可要求开发同学100%还原设计稿、过多地干预别的开发团队的开发步骤和内容。

③ 不必焦虑

前端开发工程师找我们沟通他们的疑问点时，我们要积极回应他们，并且和他们一起处理问题。比如某些复杂的页面，避免不了实现效果图不好的情况出现。这时候不要一口咬定就是开发的原因，先沟通具体原因，然后找出解决办法。

不必焦虑，遗留问题下一版再解决：开发人员在修改代码的阶段，开发人员的效率是有限的，而且大家都是身兼多条业务线，在这种开发的场景中可以在不影响正常发版日期的阶段，把不太重要的视觉问题，放到下一个版本中再进行修改。

④ 规划时间节点

而且在工作项目中也要注意分配自己的精力，我建议对需求等级进行划分。自己把问题的界面标记优先级，定期（每天定时）跟程序员沟通，跟他一起制定解决方案和时间。如果时间允许，可以慢一点修改，只要改对了就可以，毕竟完成比完美更加重要。

五、使用校验工具提高工作效率

对于设计校验的工具就一个原则：你开心就好，工具的最大作用就是提升工作效率，只要你觉得能提升你工作效率，你喜欢用啥就用啥。

如果还在迷茫用什么工具进行设计校验的同学，我把我使用的工具主要分两类介绍一下。

第一类是发现开发问题和效果图的不符合的工具；第二类是针对如何高效记录、追踪问题的工具。重要目的就是提高设计师在设计走查中的工作效率。

1. 四款发现问题的工具

我在工作中发现很多时候开发不愿意检查自己代码样式的一个原因就是不知道以下四种工具，在很多公司里面，前端开发工程师都是多条业务线并行开发的局面，没有更多的工作时间自己做设计审查，觉得又繁琐又麻烦。

这时候我们可以提供工具给予开发，帮助他们提高工作效率。设计师同学也可以借助以下4款工具进行校验：

前三款都是Google Chrome浏览器的，具体操作步骤可以看下面的图片，如果还有不懂的地方可以在评论区给我留言，我看到后会为大家一一解答。

至于“他山石”这款软件大家有兴趣的话可以在网上直接打名称就会出来软件信息。

2. 记录追踪问题的工具

介绍完发现问题的工具后，咱们再聊一聊记录追踪问题的工具。

有的人会问了，你前面讲了视觉校验都要看哪里，又推荐了视觉校验的工具来发现问题，我直接把需要修改的地方告诉前端开发工程师不就可以了吗？为什么还要知道这个记录追踪问题的工具呢？

1）进为什么要使用记录追踪问题的工具

在一些设计团队稍微成熟的公司里面，由于项目的规模比较大，涉猎的模块多，参与的人员相对也多。

面对这种体量的项目如果不进行问题的记录的话，这周做项目里面的1号模块，下周做项目里面的2号模块，大下周要对项目里面的1号模块进行修改，然后自己就会发现忘记了1号模块当初的修改问题是什么，更有甚者都忘记一起协同工作前端开发工程师的名字了。

这时“记录追踪问题的工具”就显得尤其重要了，因为这种工具的出现可以帮助我们回忆起当初具体的修改问题和修改的进度，从而降低上线安全性的风险度。

2）TO DO LIST 思维模式

to do list是一种实际走查阶段使用的一种走查模式。

在设计走查阶段，主要由设计师发现问题、记录汇总递交到前端工程师这里进行修改和跟进，主要的优势是在于协助走查可以顺利地开展，不遗漏掉任何信息。

在输出的表格比较注重3点，问题需要逐条记录、需要截问题图片及描述修改正确内容、相关对接人员的名称和处理进度。

六、结语

一个优质的项目落地是各部门协同合作的成果，视觉校验是设计师必须掌握一项技能，我们本着“认真是前提、尊重是法宝”十字真言去校验开发输出的真实页面，希望这篇10407字的文章可以帮助到你在校验的工作上少走弯路。

参考文献：

《设计师如何做体验走查》

《五大模块解析产品设计中的视觉走查》

https://mp.weixin.qq.com/s/caeeDXpoepEQXz7PEs0q5g 《4张表格助力协作效能提升》

https://www.datiyi.cn/article/472303.html 《答题翼》