作为一名有『远大理想』的工程师往往不屑于视觉上的细节，甚至有些抵触。本文以设计师的角度阐述细节对产品甚至生意的影响，以及与工程师沟通的技巧。无论对设计师还是工程师都会有所帮助。本文作者 Braden Kowitz 是前 google 设计师，参与设计了 Gmail, Google Spreadsheets 等产品。虽为旧文，但不过时，原文在此，粗略翻译，正文如下。

每当一个产品临近上线，我都会变成一个完美主义者。元素没对齐，糟糕的交互都会让我如坐针垫。每次运行都有一堆的小问题，一切看起来都那么得烂。

但团队里的其他人还都觉得挺不错！功能都能用！他们会质问『把按钮移 3 像素真的能改进咱们的产品吗？』。他们会狡辩『我们上次修复了设计上的问题，但根本感觉不到产品有任何变化』。于是团队又开始着手下一个牛逼的创意和功能。

如果你像我一样，这种状况会变得非常糟糕。作为一名设计师，我们有责任为整个用户体验负责。然而我们又依赖我们的团队，我们能设计出漂亮的，复杂的，令人愉悦的细节，但是我们不能构建，测试，部署它。

我们如何才能说服工程师以及产品相关人员去重视设计的合理性和完成度呢？我对这个问题苦苦追寻，下面是我所学到的。

不要为了设计而设计

设计师总能注意到『实用』和『有情怀』之间的差距，这也是为什么我们总在细节上纠结的原因(littlebigdetails.com)。但事实上你需要在完美的细节和更多的功能之间作出权衡：关注细节意味着拖慢进度。

因此，一句『这样看起来会更好』是远远不够的，设计师需要拿出观点去证明为什么整个团队应该在这方面花费时间。

相信细节所带来的好处

用户通过评估视觉设计，文案，交互来判断线上的可信度。因此如果信任会关系到你的生意，那么设计细节也会。去看一看这些关于界面设计与信任的学术性文章吧，或者浏览一下斯坦福网络可信性的项目。

Mint, Square 和 Simple 在设计细节上做的都非常棒，同时也获得了用户的信任。他们一开始都属于未被验证的全新的模式，然而现在人们放心的用它们存储财务信息，支付和保护账户安全。

细节提升可用性

每次看到 MailChimp 的 logo 都会令我发笑！Google 整洁的首页如此和谐。苹果华丽的像素级的完美界面让我如此愉悦。他们都恰当地设计细节，并给用户带来正面的情绪。但是这和可用性有毛关系呢？

我们的大脑是神奇的，智力和情绪紧密联系着。有一次我心情不好，当我遇到一个令我困惑的产品时，我发现我只是在不断的敲击着一个不起任何作用的按钮。在我沮丧时，我总是重复一个动作，只是一次比一次用力， 但这对我达成目标没有任何帮助。

当我们高兴时，使用界面就像在玩。整个世界看起来都像一个游戏，而不是一场战争。因此在我们困惑时，更倾向于探索并找到通往成功的路径。这里有一整本书讲这个话题：Don Normal 博士的 设计心理学。不过有一点很重要：正确的设计细节带来正面的情绪，正面的情绪让产品更易用。

批量处理

如果你的产品有大量的地方需要调整，那么修复一个问题不管对于你还是用户都是杯水车薪 — 你仅仅能察觉到那么一点变化而已。

因此我有一个窍门：把所有 UI 上的问题攒到一起处理。如果你的团队习惯定一个『修复日』去突击 bug，那么你就可以利用这个习惯定一个『设计修复日』。作为一名设计师也可以做更深入的工作，比如把所有的问题放到一个表格或者 bug 追踪系统里按照重要性排序。

在『设计修复日』，所有人只关注这个表格。虽然可能修复不了所有的问题，但这已经足够了，所有小的改变累加在一起，到这天结束的时候，产品会有一个显著的提高。这会让所有人感觉很棒，此后我还能更容易得让人们关注到设计上的问题。

随手把关

从前我第一次尝试在构建功能的同时保持高质量，但我彻底失败了。开始时总是好的：我和一位工程师打算做一个设计，我把设计图发给他，第二天他向我展示进度，结果猜猜我看到了什么？一个粗燥简陋版的设计。跟我的设计图差十万八千里！

我愤怒的叨逼叨的指出了所有的错误，这可一点都不好玩。因此下次他就更不乐意接受我的反馈，质量继续下滑，我更加愤怒，恶性循环就这样开始了。

后来我渐渐明白，在工程师眼里一个已经完成 90% 的特征，在设计师眼里只完成了 10% 。现在，我会为一个已经实现功能的特征感到很激动，因为只要再调整一点样式上的问题，它就完美了。

我还会尝试在恰当的时候创造与工程师反馈的契机。我会说：“上线前拉上我”。这样在所有文件关闭前我们可以检查一遍所有小的改动然后再发布。

小心自定义冰山

在 Photoshop 中设计一个自定义按钮很简单，但这只是冰山一角，在海平面下有非常多的细节需要处理：按下和失效的状态，防止双击时选中文字，添加对从右向左文字的支持，测试可访问性，等等等等。

当我拒绝本地控件时经常会撞到冰山。比如，AJAX 比普通页面需要处理更多的细节。自定义移动菜单比原生菜单需要更多的打磨。如果你的团队没有时间打磨自定义的UI，那么选择原生本地控件会是更好的选择。

最后

关于设计细节，上面是我这些年来学到的一些技巧。我知道对于不同的团队有不同的文化，对于质量有不同的处理方式。有些团队会对细节着迷，其他一些则更倾向于提高开发速度。

我对一个团队如何创建质量标准很感兴趣。你们是如何创建团队文化从而可以让大家快速的决定是否在设计细节上花费时间的？哪些措施有用？哪些没起作用？讨论一下。