资讯详情
开发毕竟不是设计师，对很多的视觉元素与间距没有那么敏感。所以，设计走查不但可以快速帮助开发找出与设计稿的差异所在，而且还能给到开发细节与差异的调整方案与建议，大家一起来完成最终产品的高质量交付。本期茶会话，我们一起来聊聊 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、论坛等收集反馈；日常中要把自己培养成产品的忠实用户，站在用户的角度对产品进行持续使用、发现问题、进行思考；并持续关注数据变化。
其实，在整个开发过程中，在走查与后期细节调整这个环节最能体现设计与开发之间的相爱相杀了。
期望跳过设计走查，通过开发直接保证产品最终达到非常高的还原度这种比较理想化的状态几乎是很少存在的，因为这不但需要开发有着不错的设计功底与设计敏感度，而且还要求对实现方式与开发过程也要非常精益求精。所以，任何时候，都不能忽略设计走查这个环节，它是保证最终上线产品高质量的必须工序。当然，随着开发方式的日益改善，现在整体产品的开发还原度也在逐步提升，不是全新大改版，产品迭代的组件化运用，走查的差异总量与成本也已经不像之前那么高了。不管是设计走查，还是开发调整，其实大家的一致目的还是希望最终呈现给用户的产品质量尽可能的好，所以，设计与开发相互之间的沟通、配合、理解都非常重要。
当然，这次的讨论内容还有很多我们并未探索到的地方，未来我们也会去持续研究更加科学与高效的走查方式与方法！
