这个分类在我这个域名的博客下第一次启用，之前是单独开了个域名写博客，该博客主要用来收藏一些阅读类文章或者一些英文类文章的学习，由于时间的关系，内容荒废了很久，再到后来空间被黑，所有数据丢失。

这次博客重新启用，于是把之前的那个博客合并到当前这个博客上来，做为一个分类存在，这样博客我就只需要维护一份，时间也比较容易把控。今天刚好看到一篇文章，于是先转来给这个分类热热场。

这是一篇很有意思的文章，产品、开发、设计师间不得不说的故事。

原文地址：http://www.gv.com/lib/design-details
翻译过来的名称就叫：《为什么你不把按钮往左边移3px》

以下是我用蹩脚的英文做的“翻译”。

当一个产品接近上线的时候，我做为一个完美主义者，每个错位的元素或者不合适的交互都像是我身边的刺。每当我运行它时，就像是有一堆实现的小错误在数落着我，每件事看起来都是不正常的。

但在团队中的其他人都认为这个产品看起来还行！从功能上！他们问我“就算我们把按钮移了3个像素就真的能改善我们的产品？”他们辩论，“最后一次我们修复了一些设计上的小问题，但产品经理没发现有什么不一样。”，然后团队就全部进入下一个大想法和下一个功能的实现。

如果你有些像我，这种处境是相当让人沮丧的。作为一个设计师，我们肩负全部体验质量的责任。而且，在团队中我们还很可怜，我们能设计出漂亮的、复杂的、令人愉快的界面，但我们却无法实现、测试、发布它们。

我们应当怎么去说服我们的工程师、产品经理或者同等岗位的人去适应、配合并完成设计？我为这个问题努力想了好久，以下是我所学到的。

不为设计而设计

设计师关注功能与实现间的差异，这就是为什么我们会困扰这些小细节。但是需要更多权衡细节设计的完美与功能之间的关系：获取了细节权利通常意味着进度更慢。“这种方式看起来更好”是不够的，设计师应当需要关心为什么团队需要花时间去配合并完成。

当我们获取到细节设计的权利时，会增加信任度

客户是通过评估视觉设计、文案和交互来在线评判可信度。如果这个信任关系到你的业务，那设计的细节也会被关注。可以看看《Interface design and trust》（界面设计和信任）中学术文献的条目，或者看看《Stanford's Web Credibility Project》（斯坦福的Web可用性项目）。

Mint, Square和Simple都有完善的细节设计方案，并是赢得客户信任的。他们也都是开始于未验证的产品，但是客户相信他们的财务细节，支付流程和保护帐号。

细节好了的时候进行可用性改进

MailChimp&trade的LOGO每次都让我笑！杂乱无章的内容在Google homepage上是那么的协调。苹果那种有光泽的完美像素是令人愉快的。他们都有设计细节的权利，并且创造了主动的情绪化状态，但为什么有问题呢？

有一个奇怪的大脑黑客在这里工作。我们的想法是深度地研究情绪化状态。沮丧或者高兴改变方式能让我们接近问题。让我反复的砸一个按钮却没有效果，我当然会心情不好，并感受到产品带给我的困扰。在我的沮丧的时候，尝试着同一件事情很难，他不能帮助我实现我的目标。

当我们开心的时候，使用界面的时候感觉像玩游戏。世界看起来像是一个迷，不是一个战争。所以当我困扰，我们更多的去寻找和发现其他通向成功的路径。有一本书都在写这个话题：《Emotional Design by Don Norman》（情绪化设计，由Don Norman著）。但是这里有一个重要的点：获取设计细节的权利可以创造主动的情绪化状态确实可以让产品更容易使用。

批量提升工作

如果你的产品需要大量适应的帮助来完成，修复一个问题来取悦你或你的用户，不需要做多少工作。填一个坑不需要各种崎岖，而是圆滑地渡过——你根本就感觉不到变化！

这里有一个窍门：在一个冲刺里批量处理UI的问题。如果你的团队经常花一天修复问题，然后习惯性的把这些问题也捎上一并处理。做为一个设计师，你可以提前把一些需要变动的工作或者问题跟踪放到表格里并且设定优先级。在冲刺的那天，每个人都可以关注并且通过列表来处理。或许你不需要做任何处理，那就很好了。一些小变动你可以合计，这样一天结束之后，你的产品就会明显好转。这样会让每个人都感觉不错，并且，更容易让大家关注在配合和将来完成的功能。

你来修饰

我第一次真的搞砸了，我尝试在开发功能的时候保持高质量。开始都是美好的：一个工程师和我同意开始设计，我把一些模型发给他们，第二天他会把进度告诉我。我看到了：一个我设计的粗糙版本，啊……

我呻吟、抱怨并指出所有的问题，这是没有任何乐趣可言。所以下次他也不喜欢向我要反馈，质量进一步下滑，然后我开始心烦，经典的死亡旋涡。

我开始意识到，一个功能的90%是从工程学的角度完成的，还有剩下的10%是由设计师来完成。现在关于功能我很兴奋并庆幸，在需要一点点的表面细节完成之前，该功能是完美的。

我也尝试在工程师的会议中去反馈问题。我会说，“我抢你们的权利之前，先把这些问题过一下”，这样，我们就可以把一些细小的问题过掉，而这些文件都是公开的而且可取。

避免定制的冰山

在Photoshop中设计一个自定义的按钮是很容易的，这个是我们可以看到的冰山一角。表面之下就需要有很多努力来获取细节的权利：创建按下及活动状态，防止双击文本高亮显示，添加从右到左的支持，测试可用性及其他。

当我偏离本地控件的时候，我经常把这个冰山的一角敲掉。例如，Ajax交互界面比基本的网页更加需要修饰，自定义的移动端菜单比内建版本的更加需要修饰，如果团队没有时间去打磨这些自定义UI，通常继续使用那些枯燥的本地控件会更好。

以上这些是我这几年来对获取细节设计权利时学到的一些心得，并且我发现一些团队围绕着质量这个文化有很大的不同。一些团队迷恋这些细节，以至于花掉了很多时间。而又有些团队却早早的推出粗糙的版本。

我对一些团队为质量所做的规范很感兴趣，如何创建一种文化，可以让一个团队可以快速得出是否要花费更多的时间在设计细节中达成协议？还需要为你做什么？还有什么？欢迎在下面的评论里与我讨论。