作为设计师，我们费尽心思做出了自己满意的设计稿，结果 Dev 实现出来的版本完全不是一回事。文字颜色没有调整，设计稿中的阴影不见了。什么，居然没有对齐？……好多设计中的细节，被 Dev “选择性忽视”了。
日常工作中，我们都或多或少的遇到过这样的问题。我们也不止一次的看到设计师同行们在说，这是因为 Dev 关注的点和我们设计师不一样。他们关注代码的优雅，代码的重用性，代码的性能，代码的一切…… 就是没有包括设计稿中的那些细节。
这并不是因为 Dev 主观上不在意那些细节，而是客观上他们对这些设计细节完全不敏感。为了弥补这个 gap，我们被建议提供详细的设计 Specification，很大程度上可以减少 Dev 随意发挥带来的各种 UI 问题。
实际情况，再详细的 Specification 也不能避免实现的版本出现各种各样的 UI 问题。处理这些问题时，我们需要考虑 Dev 的情绪。消极的情绪要注意规避，积极的情绪注意放大。
1. 提交 UI 问题
提交 UI 问题时，要考虑对 Dev 造成的压力，以及在修复过程中的可能引发的情绪。
我把 UI review 中发现的问题大概分为两类，非正式的反馈 和 正式提交的 UI Bug。
1.1 非正式的反馈
- 对每一个 user story，Dev 完成功能开发之后，设计师一起 review，非正式的给出 UI 方面的反馈。（字体、字号、颜色、按钮位置、留白大小等）
- 建议的反馈形式：在
便签上列出该页面需要修改的点。具体每一个点要改成什么样，之前一起 review 的时候以口头的形式已经沟通过了，不需要很详细的整理。 - 这种非正式的反馈给 Dev 的心里压力较小，并且关注的问题多是很容易调整的小细节，Dev 不会太多抗拒。
1.2 正式提交的 UI Bug
- 一些影响较大的 UI 问题，以
书面形式正式提交到缺陷管理系统，并设定优先级。 - 一般我们会以
截图+标注的形式，告知 Dev 这个页面有哪些地方存在问题需要修复，期望的 UI 是什么样的。通常情况下，这样的做法是没有问题，而且高效的。 -
如果页面存在问题较多呢？
Dev 看到的截图会有很多红色的色块。Dev 会怎么想？“你妹，老子做的东西被你画得千疮百孔。是说哥做的东西一无是处么？”
为了避免这样的抵触情绪，建议在截图上用最小的色块标明什么地方有问题需要跟进。具体是什么问题和怎么修改，建议另外以 to-do-list 的形式提供。
2. 修复 UI 问题
怎么修复这些问题，也要考虑 Dev 的情绪。建议每个迭代指定一天作为 UI Bug Fixing Day，批量修复 UI bugs。
这一天，负责这个功能的 Dev 专心修复各种 UI bugs。在这个过程中，Dev 可能有两方面的成就感。
- UI bug 相对而言修复成本较低，这一天 Dev 可以完成很多的修复任务。
“嗯，今天效率很高，爽~”
- 虽然不一定能修复跟踪范围内的所有 UI bugs，但是经过一天的修复之后，产品的整体表现更好。
“嗯，确实这些 UI 的细节改进之后，产品看上去更好了 :) ”
