Sidebar 这个网站每天都会推送5篇质量非常高的关于设计的链接，从不间断。质量真的很高，基本上只要经常看它的推送，不愁不了解当前流行些哪些设计文章、最近又有哪些好用的工具。
最近在 Twitter 上关注了一个用户，倪爽（@nishuang），他的 bio 上写着：“资深产品设计师，超过15年设计经验，为企业解决设计问题。每天分享5篇一流设计类文章，帮助设计师、PM 、工程师学习最新设计方法”。感觉也挺类似于 Sidebar 的，也基本是英文文章分享，每篇文章都会写上几句文中的提炼，或者是他自己的观点（嗯？有点像湾区日报）。几天前看到他分享的一篇文章，也就是这篇文章的原文，关于设计师和程序员高效合作的。觉得还不错，翻译一下。
接下来是翻译。
设计师和前端工程师通常被视为完全相反的两个面，设计师被描绘成敏锐的创意者，而工程师则是冷冰冰的逻辑思考者。然而，作为一名软件工程师出身的产品设计师，我敢说尽管在工作中有很多的不一样的地方，他们两者也能够非常有效地进行合作。只需要稍微理解一下对方的角色，设计师和工程师之间的关系就会大大改善。
以下是设计师在与工程师合作时要遵循的五个规则，后面接着的是工程师视角的另外五个规则。
实际上，所有前端工程师团队都会使用某种类型的库或CSS框架，用于在应用程序中使用的样式。这些库通常包含一些常见的样式，比如预设的边距、颜色等等，它们可以使工程师开发更快速、更一致。这意味着，如果你决定添加自定义的边距、字体大小或组件，工程师必须从头编写自定义的样式来覆盖预设的样式。偶尔来一次可能没什么问题，但是如果长此以往，这将很快变得非常繁琐而乏味。把这些自定义样式留到特殊场合或绝对必要的时候吧。毕竟，在给定的框架和库中设计，帮助我们简化了许多决策，这通常是件好事。
让我们现实一些，一般来说工程师不会有很多的产品发言权，除非你是在一个早期的创业公司工作，或者你是个开发总监。在一定程度上，制定产品愿景通常由高管、产品经理和产品设计师来决定。然而，即使工程师没有得到太多的介入，他们仍然可以感觉到已经介入足够多了。当你在与产品经理开会时，拉上开发的头儿。此外，可以和你的工程师团队建立一些设计评审来检查您的设计。向他们解释你为什么要做这样的设计决策，并向他们征求意见。如果工程师觉得他们对设计过程有贡献，他们在实现你的设计时自然会更加用心。
说出来你可能不信，许多工程师往往是相当不错的设计师。特别是关于UX，我已经和很多有很好的设计意识的工程师合作过。这些工程师想要被倾听，他们的反馈是非常有价值的，并且经常是对的。当你信任的工程师对你的设计给予反馈时，要注意倾听。更好的做法是，拿出笔记本，记下他们的想法，让他们知道你在听。你不必采用他们的每一个想法，但要给予他们应有的尊重，而且一些建议要实施下去。
当然，并非所有工程师的设计反馈都是好的。对他们的意见采取保留态度，用开放的心态对待它。这样你会经常学到一些东西，而且每个人都喜欢被倾听。
当我还在 SalesforceIQ 当软件工程师的时候，我和一个非常牛逼的设计师合作过，他可以使用浏览器的检查器来和我一起检查代码，直接使用代码编辑器用HTML/CSS来快速制作原型。作为一个工程师，如果知道了一起合作的设计师了解你所使用的技术，并且在设计时会考虑到各种约束条件，这将令人难以置信的安心。要成为一个优秀的产品设计师，你绝对没有必要学会全面的前端开发技术，但是懂一些前端常识会有很大的好处。如果想获得你最经常合作的同伴的青睐，那就学一些代码知识吧。
心流是指一个工程师进入最有效率的工作状态——它更多是指在工作中达到忘我的状态。工程师需要大量的不受干扰的时间来达到心流状态。这就是为什么会议最好安排在一天的开始或结束，持续的打断对工程师来说是非常不友好的。是的，这意味着你在早上刷牙的时想到的，用一个更深的蓝色来做按钮的想法可以推迟一下。设计是一个迭代的过程，而且产品也毫无疑问地会不断地改动。不过你可以做的是，先把这些小改动积累起来，然后再一起提交给工程师。例如，在让工程师帮忙进行修改之前，先设定最少提交5个小变化的基线。没有什么比仅仅改变一个按钮的颜色7次更让工程师们恼火的了。
作为一名工程师，你有很大的在你的指尖上创造的权利，而且直接投入到代码中是很容易的。然而，权力越大，责任越大。往回想一步，要理解为什么要做一个产品或者为什么做一个功能。去和你的产品经理和产品设计师谈谈。了解为什么要做某个功能，以及为什么它是这么设计的。如果连这种洞察力没有，那么你仅仅是像素的搬运工。相反的，通过对产品的理解，在实现过程中你能够更好地考虑到所有不同的用例和边缘条件，并将你的代码提升到另一个高度。
在敏捷开发的环境中，设计总是基于用户测试和反馈进行迭代。可能一个蓝色的、有投影的、有五个像素的圆角的按钮，你昨天才煞费苦心地实现了出来，现在可能又变成了绿色的、扁平的、直角的按钮。非常让人疲惫。但是不要气馁：只要接受这是产品开发过程的一部分的事实。先实现UX——首先是流程、功能和总体布局。先把整体的感觉实现出来，不要一开始就疯狂地沉迷在设计稿像素还原中。一旦设计已经经过了更多的迭代和测试，版本变得更加稳定了，再来逐步地把视觉元素也一起实现出来。
还记得上次你的设计师要求你实现一个自定义组件吗？该组件可以更改颜色而且可以每隔一分钟进行一次翻转。不要这样做！设计是双向的。不要害怕把需求推回去，并给出关于技术上的约束和限制的反馈。在大多数情况下，即使是最好的设计师也不会比你更了解系统中用到的技术。不过，不要直接把需求推回去，然后直接说“这是不可能做到的”，而是提供一个替代的解决方案，试着说 ”尝试实现这个方案将会非常耗时耗力，条件不太允许，我建议……“。要知道，大多数的需求我们都可以用我们今天拥有的工具来实现，但这并不意味着每一个需求都应该被实现出来。作为工程师，你的工作是帮助设计师找到最好的、最有效的解决方案。
不骗你，”沟通“真的是本文的主题。在开发实现的过程中，一定要不断地向设计师展示你的进度。设计师们非常喜欢看到他们的作品被实现出来，所以这对每个人来说都是一件很有趣的事情。让设计师知道你的开发进度将有助于确保你的实现符合预期，而且不会出现任何意外。这也是一个很好向设计师询问你对设计中的疑惑或接下来的功能等问题的机会。
在实现设计时，总会有一些地方需要你用自己最好的判断来填补空白(设计师没考虑到的地方)。你将要实现的设计可以不用和设计师的设计完全一样——那只是底线。当你意识到在某些屏幕尺寸上需要较大的边距时，或者在实际应用程序中颜色有些不平衡时，不要每次都跑去问设计师。你尽管戴上设计师的帽子，在小的设计问题上自己做主。你完全有这个资格。
但是也不要太过于疯狂，当遇到更大的设计决策时，和你的设计师沟通吧。用你最佳的判断力 :)
文章结束啦！这是我为设计师和工程师写的，提高质量和效率的5个合作规则。这些规则都是完全主观的，来自我以前作为软件工程师的经验，以及我目前作为产品设计师的经验。无论你是否同意我的观点，请在下方留言告诉我，让我们继续交流！