终于到三部曲最后一部了，本篇讲述作为设计师，该如何与开发工程师一起更好的合作，这个系列翻了将近有一个月，最近私人时间越来越少，但是我还是会继续坚持把更多更好的文章翻译给大家。
阅读原文请戳这里：How to work with Engineers
欢迎关注我的微信公众号“开卷有译”获得新文章推送。如需转载请注明来自公众微信号“开卷有译”，或译文地址。废话不多说，下面进入译文
------------------我是分割线------------------
如何与工程师一起工作
——给设计师的秘籍
在很久以前，我曾经做过产品经理，之后也做过开发工程师，在过去的7年里，我从事设计的工作。每一天我都和担任这些角色的人一起工作，而每一天，在产品开发中，我对这三种角色相互合作背后的责任，挑战以及艺术都有新的体会。工程师是团队中的魔术师，他们只需要动动手指，执行计划和绘制像素，你瞧！一款鲜活的产品就诞生了。作为设计师，如何才能跟得上他们精明缜密，自我否定又热衷脚本的工作方式呢？往下看吧。
工程师是将创意变为现实的人
是工程师将每个好点子变成现实的，这是个大家需要永远铭记的事实。不管你的公司里有5个，500个或是5000个工程师，都不要把他们当做是一种“资源”。他们是产品基石的建筑师，也是让产品正常运行的守护者，是他们，让产品快速运作起来，变得稳定，可靠，从而拥有数百万记的用户。通常，也是他们在创新，用新的算法在推动技术，将产品团队无数投入变得有意义。
这一切的一切我就是想表明：工程师超牛掰！
这意味着…
想要创造点神奇？你需要做的就是说服一两个工程师
真的，就这么简单。许多传奇般的产品是这样诞生的：几个好友在某个周末，一边喝着啤酒一边敲着代码。产品经理和管理什么的那都是后来的事情，一切都从最基础开始——创意，设计然后实现。这也就是为什么我们需要与工程师保持紧密的关系。
或者，试想一下这样的场景：产品中某个细节部分让你感到十分烦恼，就像瘙痒在你根本挠不到的地方的那种，你觉得这个设计很有问题，你该怎么做？
1. 在下次团队讨论会中提出来，加入到产品改进列表，然后大家一起来排定优先级，之后等待新的工程师加入团队，在他熟悉了产品之后再把它做出来。
2. 和某个工程师保持良好关系然后径直走向他的工位，请他帮个忙，花个三五分钟处理，然后再看着他提交这个改进。（也许你需要帮他做一件印着80年代知名乐团图案的T-shirt或是其他点什么作为交换，反正你对插画也很在行。）
你说哪种办法更快？
也就是说…
如果工程师明白设计的价值，事情会变得容易得多
试想一下，工程师不需要来询问你每个设计细节就知道如何处理页面的空白处，即使你忘了详细标注边距的尺寸，他也会打开PS自己丈量——这是件多么美妙的事情。特别是他还能给你提出改进意见让你的设计变得更好，这简直不可思议。更有甚者，他细致精准到实现出的界面与你的设计完全无二致，这是件多么惊人的壮举啊！
你如何才能与这样的工程师一起工作？如果能招到这样的工程师，那将会是很幸运的事情，因为界面设计导向的工程师是炙手可热的。
或者帮助工程师提高一些设计鉴赏力。如何做到呢？不要只是把你的设计丢给他们——和他们阐述你的设计，告诉他们设计的价值，以及为什么你的设计是值得实现的。帮助他们学会如何鉴别实现是否符合设计的要求。对于那些看起来很糟的东西告诉他们你是怎么想的。
建立良好的关系也很重要。人们总是根据和其他人的谈话转移自己的价值取向和优先级。这听起来很老套但总是屡试不爽。（New Yoker站点上一篇名为“Slow Ideas”的文章就很完美的阐述了这个策略）
工程师大多不会关注到设计细节，但是他们大部分都很关心用户体验而且希望产品有更好的体验。这并不是说每个工程师都会热衷于设计细节的实现工作，但是这样的态度有助于他们理解设计背后的意义。
因为，工程师越是对设计喜欢，他就越能理解这样设计的原理并且看到它的价值，也就能越快越好地将它实现。
尽早搞清技术限制，为自己节省时间
身为设计师，你很容易就会沉浸在各种设计假想的世界中难以自拔。如果我们能读懂用户的心思并且知道他具体想要什么然后再呈现给他？又或是点击这个按钮会产生火焰以及爆炸成颗粒随风飘散的特效？
在没搞清技术或是时间限制前，别沉迷中那种根本不可能实现的设计。（就算是值得你去争取一下的设计方案，提前了解限制也会让你更有底气。）最坏的情况就是你倾注大量的时间试图将某个设计提案做到完美，最后却发现它却根本不可行。好的设计师本来就够少的，而要解决的大问题又有很多，这种毫无效率的事情应该尽量避免。
所以下次当你有个绝妙的主意在你脑海中闪过，而你却对实现难度上感到疑惑时，别猜，直接去问工程师！
另一边也是一样…
任何时候都让工程师了解最终设计会是如何，帮工程师节省时间
如果你对自己交给工程师实现的设计方案并不那么自信，在看到成品前都无法确定它是否能够运作得好，请确保让他们知道设计有可能会有变化。对于工程师来说，没有什么比“通宵完成实现却在第二天早上得知整个设计已经改了”来得更困扰的事情了，因为这样他们要把那些倾注了无数心血、成品级别的代码统统丢掉了。
当然，工程师都有写出废代码的经历。这是他们工作的一部分，设计也是一样。好的工程师理解产品研发的流程是复杂的，东西做出来之前都不知道是否能行得通，需求常常变化，设计也是。但是沟通清楚哪些部分仍然还在探索，哪些部分基本已经敲定，可以帮助工程师想出如何更好的构筑代码，是更快速的编程，还是写得足够灵活为将来的修改做好准备。
确保设计得到完美实现的最好方法就是极其密切地与工程师合作
像是坐在他们的边上看着他们把东西做出来。大家都坐在同一个空间里工作，对于确保大家是否进度一致这件事，则显得异常容易。问题更快浮出水面，也能更快得到解决。
最终产品如果不是每个人都引以为豪的成品，各种指责将轻易出现。“我们的设计很赞的，但是工程师根本就实现得不对。”这种思想要不得。作为设计师，你需要对面向用户的产品负责，而不是那些PS的设计稿。对于实现不对的地方为什么不拿出些该有的行动？为什么你不让工程师给你演示一下他们实现好的东西这样你们就可以一起抠抠细节？为什么不在开发阶段问问工程师们是否对你的设计有任何疑问？为什么不在发现后给工程师提交一个任务让他去修复？
没错，拿出你的担当来！
最快俘获工程师的心的方法，就是提供完整的设计
说起来也可笑，人们总是用“细节导向”来形容设计师，然而事实上许多设计文档遗漏了大量的场景，最终却由执行这些分支开发的工程师找出来。
想成为工程师心目中的设计英雄么？请确保你的设计方案是完整的，考虑到各种边缘场景例如：
1. 国际化： 设计在换了另一种语言后看起来如何？尤其是德语下长文字对排版的影响如何？
2. 出错状态：网络连接丢失时会发生什么？或是数据崩溃？等等。
3. 极端用户： 当用户完全没有任何信息或是活动时，页面是如何的？那当用户有着超级多的信息或活动时呢？
4. 页面转换：A屏到B屏的跳转具体是怎么完成的？好的工具在将给你帮大忙，具体可以参考我的另一篇文章《如何在设计（以及僵尸启示录）中生存》
设计上述的这些场景不仅可以帮你全局的考虑产品从而增加对设计的信心，更可以帮助工程师去计划如何构建系统，并给出时间上给出合适的评估。更不用说完整的设计可以避免临时抱佛脚出来的粗制滥造，因为之前没人发现直到想做得更好却为时已晚。
请做一个合格的团队贡献者，确保你的设计是完整的，别只为理想的情景去做设计，从设计效果图的幻境中走出来。因为每一个工程师都知道，唯一有价值的就是最后发布的那个产品。