UI设计师,交互设计师如何做好走查

工作中，因为各种各样的原因，开发最终完成的视觉还原离设计稿还是会有一些偏差，特别是在全新改版时甚至会有较大的偏差，这是一个客观存在的问题。要保证最终上线的版本能达到较高的设计还原度，那么，视觉与交互走查是整个开发环节中必不可少的一步。

开发毕竟不是设计师，对很多的视觉元素与间距没有那么敏感。所以，设计走查不但可以快速帮助开发找出与设计稿的差异所在，而且还能给到开发细节与差异的调整方案与建议，大家一起来完成最终产品的高质量交付。本期茶会话，我们一起来聊聊 UI、交互设计师如何做好设计走查的问题。

视觉：首先根据任务流程测试大的功能、交互、状态、空页面是否缺失，保证设计的完整性；走查页面还原：位置、间距、大小、颜色、文字易读（大小、自重、行高、段落等）；组件化页面，检查组件使用；检查图标、按钮可操作区域操作可行性；点击区域的反馈是否有正确的 Toast 提示和正确的跳转；图标、图形、插画的清晰度和阴影的还原度；动效的使用；颜色差异等。

交互：组件控件的各种交互操作的各种状态；各个业务状态；走查分两个阶段——第一阶段：自我内部自查（开发、其他人员会在开发过程中会再发现问题）；第二阶段：上述的测试验收走查，这个阶段就是要去平衡开发时间和上线效果时间；提示文字、输入框引导文案、键盘调用效果、操作类内容展示、用户感知度、流程结束后操作、点击返回引发的操作提醒、同类操作入口的统一性；特殊情况走查等。

注意点：覆盖不同状态下的页面走查；根据业务流程走查，避免遗漏。

发现问题：要想达到最高质量的设计还原，就需要得出精确的各类差异参数，相对传统一点的方法，就是把设计稿中的页面与对应 App 全部截屏，然后通过 Ps 或者 Sketch 等设计工具与设计稿叠加对比；走查间距、位置、大小时，设计稿放在下层，截屏页放在上层，截屏层的透明度调成 50% 左右，查看重合度；走查颜色主要靠像素眼，一般感觉色差不对，对截屏页进行吸色对比。

走查报告：首先列好走查的页面，每个页面下面记录好存在的问题，比如：写明页面与设计稿不符的具体位置，按自己的判断与理解应该如何调整才能达到设计还原，并放上对应的设计稿进行标注；标明出问题优先级、测试机型。

常用设计稿比对软件：Ps、Sketch、他山石等； 记录软件：Keynote（推荐）、Zeplin（标记已解决、待解决） 、Mac 自带 Pages 文稿  、有道云笔记 、印象笔记等。

截图比对的方式比较传统，熟练起来通常会比较快速；现在网上也有一些辅助的走查软件，比如他山石，我们团队也进行过试用与研究，这类工具更加适合用于开发自查，对 Android 版本还算比较友好，iOS 版并不支持。

Keynote 示例

Zeplin 示例

首先设计稿做好注释及特殊情况的说明沟通并提供正确的切图尺寸；做好走查报告的编写，一份高效报告应完整地包含：xx 页面、xx 模块、xx 视觉问题、如何调整与修改、调整后是否可以达到设计还原；备注需调整部分优先级，需要优化调整与精确调整还是不必精确。

将走查报告文档与测试版本对应，例如，标注: 1.0、1.1 版；走查报告用 Keynote 图文对照，标注测试机型并清晰列出问题及意见方便开发准确地找到问题；开发修改后，进行二次确认。

特别重要的一点，就是要注重与开发同学沟通的态度与技巧。

如果时间充足且开发配合，可以坐在一起 1 对 1 进行指导调整，优点是可以快速帮开发找出视觉的差异所在并给到调整方案，如果出现问题方便及时修改与优化调整方案，及时掌控调整进度。

如果时间不充足，将走查报告发送给开发，每天下班前与开发沟通一下调整进度，让开发在走查报告上对调整的部分进行标明，下载安装测试版对完成调整部分进行再走查，确保调整达到设计还原。

约定视觉验收节点，提前介入；了解开发测试版规划，约定修改后的测试版本。

一般走查时都是测试版，经常会出现闪退、功能不全、数据不全，导致不能完整的走查下去。

如果对开发的实现原理不了解，不能给到有效的调整方案，开发按照调整方案进行调整后，没有效果或者效果有偏差； 或者因为系统或者技术实现问题，一些视觉差异调整不了。

需要调整的地方太多，调整有遗漏、没按反馈报告进行调整；测试版质量太低，需要要调整的部分或者整个页面都与设计稿有严重的偏差；已经调整好的模块或者本来就是正常的模块，因为其他部分的调整引发关联反映，导致重新出现视觉问题。

开发无法实现时处理方法：要求评估工作量和无法实现的原因做好记录。

iOS：走查对比相对方便，因为 iPhone 的分辨率相对固定，系统字体也可与设计稿进行对应。通常，我们都是按 750 宽的分辨率进行设计，所以截屏时用 750 的 iPhone 最佳，用 iPhone X 也是可以的，刚好是 1.5 倍，把截屏图等比缩放到宽度为 750 即可。也要注意在 iPhone X 和 Plus 屏幕下是否有做正确的适配，Plus 一屏无法显示完，可右滑的情况下是否有做可右滑提示，大屏幕下分割线是否有做适配，是否有一像素分割线变成 2 个像素的情况等；针对 iPhone X 等全面屏，针对性走查底部 home 指示器颜色显示规则，顶部间距等。针对产品用户量最高的几个机型需重点走查。iOS 常用机型如下图：

Android：机型较多，各个机型屏幕显示（字体、颜色等）有所差异。因为很难找到与手机等宽的分辨率手机，比如，按照我们现在的差异化设计规范，从成本上来讲，Android 的设计稿通常是从 iOS 进行差异化调整而来，所以设计稿宽也为 750，但 Android 同等分辨率 720P 的宽度一般为 720、768 或者其他等，而且现在大部分 Android 手机的分辨率都达到  1080P，我们通过截屏把等比宽度调整为 720 （注意是720，不是 750）进行对比，对比右间距时，截图层右移 30 PX 就可以了；除此之外，因为 Android 的系统字体并非为苹方，所以，还要考虑字体不同造成的字高与间距差异，通过字体的边沿法进行对比；时间允许的情况下可以多走查几个机型，或者重点看产品数据用户量最高的几个机型。

小程序：小程序的设计与 iOS 基本差异不大，走查与 iOS 基本一样，但实现原理与 App 还是有很大不同，例：Tabbar 样式不可修改。所以在写走查报告时，会有一些差异 。

前端 (Html5)：字体可以设置字重；需在不同机型中进行走查，在 iOS 和 Andriod 中会出现显示差异；公众号内嵌时，需要在 PC 浏览器打开走查 PC 适配。

前端 (Web)：同样采用截图法，如果能够懂一些前端的代码，比如 CSS，可以通过 Chrome 直接进行调试，通过调试达到设计还原，然后把调试参数直接反馈给前端修改；直接用 Zeplin 中的视觉稿调低透明度，直接与线上浏览器中的页面一比一做对比，可谓走查利器；各个浏览器（Chrome、IE 等）下字体用各自的默认字体。

产品正式上线以后，第一时间下载安装，对该版本所有需求页面进行体验与使用，观察页面上是否有新的视觉问题或调整不到位的问题；发现问题后及时进行记录，反馈给开发，一起探讨出现问题的原因与确认调整时间与方案；通过各类网络途径收集用户的反馈，例：丁香园从微博、AppStore、论坛等收集反馈；日常中要把自己培养成产品的忠实用户，站在用户的角度对产品进行持续使用、发现问题、进行思考；并持续关注数据变化。