[译] 设计师与工程师协做的 5 项准则

• 原文地址：5-rules-for-designer-engineer-collaboration: Tips to Improve Quality and Productivity
• 原文做者：Andrew Yang
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：Starrier
• 校对者：PokerF、NoName4Me

设计师与工程师协做的 5 项准则

提升质量与生产率的小贴士

设计师 vs 工程师，源于 society6。

设计师和工程师被看做是彻底相反的。设计师被描绘成敏感的创造者，工程师被描绘成冷酷的后勤人员。然而，做为一名前软件工程师出身的产品设计师，我认为这些对立面能够在工做场所中有效地协同工做。只要多了解一下对方的角色，设计师和工程师之间的关系就会大大改善。如下是设计师在与工程师一块儿工做时应遵循的五条通常准则，其次是从工程师的角度来看的另外五条准则。

给设计师的 5 项准则

图片来自 Upslash，做者 William Iven。

1）避免自定义样式

实际上，全部前端工程团队都使用某种类型的库或 CSS 框架来实现跨应用程序使用的样式。这些库一般包含一些通用样式，如预约义的边距、颜色和其余类，这些工具是工程师用来使开发更快速、更一致的。这意味着，若是您决定添加自定义页边距、字体大小或组件，工程师必须从头开始编写自定义 CSS 以覆盖基本样式。偶尔这样也不错，但很快就会变得单调乏味了。仅在特殊场合或绝对必要时保存这些自定义样式。毕竟，在一个框架内设计能够简化咱们的许多决策，这每每是好事。

2）尽早与工程师沟通

让咱们现实一点，除非您正在为一个初创公司工做，或者您是工程副总裁，不然工程师们不会获得多少产品的发言权。设定产品愿景在必定程度上一般取决于高管、产品经理和产品设计人员。然而，即便工程师在设计方面没有太多投入,他们仍然感受正如他们本身在设计同样。当您和产品经理开会时，请一位工程主管参加。此外，与您的工程团队一块儿设置一些设计评审来检查您的设计。向他们解释您作出设计决定的缘由，并征求他们的反馈。若是工程师以为他们对设计过程作出了贡献，他们在实现设计时天然会更加用心。

3）听取工程反馈

信不信由你，工程师一般都是至关不错的设计师。特别是在 UX（译者注：用户体验） 方面，我曾和许多有很强设计意识的工程师一块儿工做过。这些工程师想要被倾听，他们的反馈是很是有价值的，并且每每是准确的。当你信任的工程师针对你的设计给你反馈时，倾听。更好的方法是，拿出笔记本并记下他们的想法，让他们知道你在听。你没必要使用全部的想法，但要给予他们应有的尊重，有些建议是必定要坚持的。

固然，并不是全部来自工程师的设计反馈都是好的。以怀疑又开放的心态来对待它，你总会有所得，并且又有谁不喜欢被聆听呢。

4）了解基础的 HTML/CSS/JS

当我仍是 SalesforceIQ 的软件工程师时，和我一块儿工做过的最好的设计师之一能够和我一块儿直接进入 Web 检查器，并在控制台中直接使用 HTML/CSS 快速原型。做为一名工程师，知道与你一块儿工做的设计师理解你正在使用的技术，而且在设计时考虑到这些限制，这是使人难以置信的安心。要成为一名优秀的产品设计师，彻底没有必要拥有完整的前端开发技能，但一些基本的前端知识会发挥很大做用。得到您最亲密的同伴的尊重 -- 学习一些代码。

5）批量小修正

心流是工程师最有生产力的一种状态 -- 它在很大程度上意味着『在区域内』。工程师须要大量不间断的时间才能实现流程。这就是为何会议最好安排在一天的开始或结束，而不断的干扰是工程师生存的祸根。是的，这意味着你今天早上洗澡时想要用更深的蓝色来作按钮的想法能够暂时搁置。设计是一个迭代的过程，产品无疑会不断的变化。然而，在向工程师询问以前，先让这些小的变化积累起来。例如，在接近工程师进行修复以前，设置五个小的更改的基线。没有什么比打破他们的流程更让工程师烦恼的了（仅仅改变按钮的颜色七次）。

---

给工程师的 5 项准则

William Iven 经过 Upslash 拍摄。

1）理解用例

做为一名工程师，您有大量权力能够用指尖进行创造，并且它真的很容易用代码实现。然而，巨大的权力带来了巨大的责任。退一步说，了解您正在构建的产品或特性的『缘由』。去和您的产品经理和产品设计师谈谈。理解为何要构建这个特性，以及为何它是按照这样的方式设计的。没有这种洞察力，你的工做只是做用在产品边缘。另外，经过对产品的理解，您将可以在实现中考虑全部不一样的用例和边缘案例，并将您的代码水平提高到下一个层次。

2）先实现 UX

在敏捷环境中，设计是基于用户测试和反馈不断迭代的。您昨天刻意实现的一个具备5个像素的 border-radius 和 box-shadow 蓝色按钮而如今倒是一个有着平面设计和尖锐边缘的绿色按钮。搞砸了。可是，不要气馁：接受这是产品开发过程的一部分。首先实现 UX - 设计的流程、功能和整体布局。得到总体效果，但不要疯狂于像素的完美实现。一旦设计经历了更多的迭代测试而且版本稳定下来后，栩栩如生的元素会逐渐融入其中。。

3）回退

还记得上次设计师要求您实现一个改变颜色并每隔一分钟翻转一次的自定义组件吗？是的，别那么作。设计是双向的行为。不要惧怕回退，给出技术约束和限制的反馈。在大多数状况下，即便是最好的设计人员也不会拥有您的技术能力或对系统的理解。然而，与其一味地说“这是不可能作到的”，不如提供一个替代的解决方案。试试看，“这个解决方案的实现成本很高，我能够建议您使用…吗？”。请记住，大多数事情都能够用咱们现有的工具来完成，但这并不意味着全部的事情都应该完成。做为工程师，你的工做就是帮助设计师找到最好、最经济有效的解决方案。

4）与设计师保持联系

沟通确实是本文的主题。 在您实现设计时，务必始终向设计师展现您的进度。 设计师喜欢看到他们的做品变得栩栩如生，因此对每一个人来讲这真是一件有趣的事情。 让设计师及时了解您的进展状况将有助于确保您的实现符合预期，而且不会出现任何意外状况。 这也是一个很好的机会向设计师询问任何关于设计或将来任务的问题。

5）填补空白

在实现设计时，总会有一些地方须要您用本身的最佳判断来填补空白。您实现的设计不会彻底相似于交给您的设计 --  这只是底线。您确定有遇到过这样的状况：您以为在某些屏幕上须要更大的外边距，或者在实际应用程序中某个特定的颜色看起来不太合适。不要每次都带着问题去找设计师。把你的设计师帽子戴上，告诉本身你有解决它们的能力。你有这个本事。

但也不要太过疯狂，作重大决定的时候记得要和你的设计师沟通。用您最好的判断力 :)

---

如今你明白了吧！这是我为设计师和工程师改善他们工做时的协做而编写的 5 项准则。这些准则都是彻底主观的，来自之前我做为软件工程师时的经验，以及如今我做为产品设计师的经验。请告诉我，您是否赞成个人观点，这样咱们好在下面继续讨论！

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。