在以工程为中心的许多公司里，我作为设计师已经持续工作了大约10年，我花费了大量的时间与工程师们一起工作。从这些协作中，我获得了最实用和最富有成果的工作关系。
设计师们，你们也能同工程师们创建这样的关系——你仅仅需要放弃对设计师和工程师的个人偏见，为有效的伙伴合作关系创造空间。如果你因此成功，那么好处将远大于成功本身需要付出的成长的痛苦和所有微小的调整。
我曾在咨询领域，学术领域，以及世界顶级的工程公司之一工作过。我从诸多方面观察过设计师的行为，并且和许多类型的设计师一起工作过（从非常技术型的，到概念型的，到视觉型的，等等）。
有些一致的糟糕的设计师行为，破坏了我们在工程师中的名声。通过改进我的方法，我在工程公司中的设计，在创造与工程师之间持久的，信任的和高效的关系中，都获得了非常棒的成功，但其他设计师却鲜有成效。一个出色的设计师能够以指数级的速度来扩展他们的工作，只要他们能与工程师有一个好的合作伙伴关系。但是要做到这些，设计师们需要作出少许的微小调整。
关于如何在设计与工程之间创造高效的关系，我这有几点建议。我意在减少两者的偏见，能够帮助设计师和工程师之间形成更加坚固的联合关系，能够一起做出更好的产品。
1.使用他们所使用的工具。（Use the tools they use）
作为一个即将融入新团队或开启新项目的设计师来说，首先要做的是问一个简单的问题：“你喜欢怎样的工作方式？”许多设计师会犯错，他们使用之前已经习惯了的工具和工作流程，或者他们发现与之前的团队相处融洽。但是在软件行业中，事情的发展都比较快，每个团队都是不同的。
我发现通过询问工程师团队是如何工作的以及他们当前正在使用的工具，我能很快的越过这个痛苦的不相容的过程。一些团队可能喜欢使用协作文档来跟踪bugs，有些使用通常的bug跟踪软件。一些甚至觉得使用邮件就很好，一些使用像PivotalTracker提供的敏捷开发流程。
设计师成功的关键不在于他们的模型是多么漂亮，而在于他们如何成功的传递自己的设计，以使工作产品尽可能的趋于完美。一个真正的设计师能够接受任何工具，以高效的传递设计——尽管有时要花费长一点的时间来使用一个新工具，但这对于减少了与工程师间的摩擦，推进工作是很值得的。
2.参与整个工程周期（Pariticipate in the entire engineering cycle）
当设计师等到产品周期的后期（投放市场之前）才活跃起来，那么就很容易弄僵与工程师的关系。对于工作即将投放市场的工程团队来说，突然插进一个外人并提出许多变更的细节，会令他们十分沮丧。如果你在产品投放市场之前仍没有参与进来的话，你实际上就是个外人。
工程师需要设计师参与到一个产品或专题的整个生命周期之中，而不仅仅是在开发前端界面的时候。设计师需要深刻的意识到（如果没有参与过工程）工程师们在构建基础的数据结构，存储结构，检索结构以及UI框架所要面对的严峻的工程挑战。设计师需要和团队其他成员一起庆祝和促进每个工程里程碑——尽管只是在一个半成品的原型中使用了颜色为#00C的漫画字体链接。
我时常看到我的设计师同事们会撕毁早期原型设计的美术作品或交互设计。当一个工程师遭到一个设计师关于问题的批评，并且这个问题工程师甚至都没来得及思考时，那么这位工程师在将来的产品复审中将不会再叫上这个设计师。这也是最后设计师为什么在产品投放市场之前一周提出大量的变更，但几乎不会得到结果的原因。
3.明确要改善什么（Be specific about what needs improvement）
许多设计师认为当他们向工程师提供了一个完整的，“像素级完美的”模型后，他们的任务就完成了。当一个产品或专题即将投放市场，但前端页面看起来尚未明确时，设计师们就开始抓狂了。但是在向工程师的最新实现作品提出“这与我的模型不匹配，为了防止你丢了它，再给你一遍”之前——请明确指明。
设计师练就能够捕捉大多数人从不会注意的那些最细小的细节。工程师不是有意要遗漏这些细节——他们只是不会优先考虑这些，对他们来说基本功能和部署无bug的产品才是首要的。捕获这些错误并尽可能具体的指出它们，这是设计师的工作，因为与你一起工作的工程师们从没有训练去如何处理这类细节。
同时从演示demo和你的模型中截图，来提交bug报告。在这些截图上标明需要改进的细节描述。展示并告之。我提交一个bug时，通常会在截图的前后添加注释，并把需要改进的地方总结成一个无效列表。这样，视觉学习者和语言学习者就都有了其所需快速谨慎推进的格式。
我甚至更进一步，将交互设计改进和视觉设计亮点分开提交bug，因为可能在你的团队中，有些人长于某项领域，而另一些长于其它领域——如果按以上去分类的话，工作则更易进行划分。一般而言，工程师们对于列出的改进要求反应还是很好的，他们能有条不紊的通过，并且一旦完成后会仔细的核实。尽管我会做更多额外的工作，但是从这些小量的外勤工作中，我能得到更多的改变。
4.现实对话很愉悦，但他们没法跟踪（Meatspace chats are lovely ， but they can't be tracked）
我知道的许多设计师更愿意当面和产品经理或设计师去提出设计细节。这非常棒，能够帮助提高团队凝聚力，但是带来的负面影响是，这些没有“书面记录”。除非你是工作在只有两个人的团队中（你和一个工程师），否则所有的东西都需要文档化，以让更多的团队成员来翻阅并提出反馈。
所以尽管与工程师关于改善设计的谈话中，你确实有所成效，但最好返回你的办公桌立刻在邮件中总结下来或提交一个bug报告。这给你的整个团队带来了一个提供反馈的机会，并且也为正在进行的设计做了一个记录。当最终事情变得紊乱时，任何没有文档说明的决定都是待价而沽。
5.和你的工程师一起喝杯啤酒（Drink beer with your engineer）
绝不要低估与团队成员间的社交力量。试着去了解他们，也让他们来试着了解你。如果某些人觉得你把他们最为人（而不是你用来实现设计构思的技术集合）来关心时，你就能够加快你们之间信任和交流。
------------------------------------------------------------
工程师们，你们认为你们也不会轻易的脱离干系，是不是？正如设计师们可以做所有的事情来让你的工作更容易，同样你们可以做几件事，来与设计师们创造更好的关系。
1.不要让你的第一个回答就是“不”（Don't let your first answer be "no"）
作为一名设计师，没有什么比这更令人失望的了——她兴奋于一个想法，开始和一个工程师讨论，但设计师在没有真正的解释这个想法的潜力时，就被告之闭嘴。
我发现许多工程师（尤其是那些我已经多年没有共事的工程师们），对于设计观点和创意的反应是消极的，因为他们认为这意味着“更多看起来无关紧要的多余的工作”。相信我，设计师了解你们正在努力工作于实现那些微小的，从侧面看不会产生任何破坏的东西。
但是一个团队同时需要设计师和工程师是有原因的。我们的工作就是，创造一个直观的，有趣的，有创意的用户体验，大众喜欢使用，并且希望继续回来使用。否则，所有工程师的辛苦工作都是徒劳的。
有趣或新颖的想法可能会让设计师得意忘形，但是与其直接对他们说“不”，不如花一点时间试着了解为什么你的设计师如此兴奋于该想法。考虑和她或其它工程师一起讨论关于如何以更少的工程开销获取同样效果的方法。如果你的设计师认为你是一个热心的、无偏见的合作者，你可能会更快的得到你想要的icon。
2.“合适与完美”不是工程师的工作（"Fit and finish" is not engineering busywork）
不同的学科侧重不同的东西。对于一个优秀的设计师来说，注重细节和创造一个优美的用户体验是最重要的。这些细节问题，它们很难被发现，但通常都会影响用户对于一个产品或专题的潜意识的反应。很多小的细节错误可能累计并导致一个产品给人一种不专业，不可靠的感觉。相反的是，一个精心打磨的应用比起一个工程上完美无缺但用户体验上草率粗糙的应用来说，会产生一种更强的情绪反应。
当一个设计师让你把icon左移三像素，或在同一个基准线上对齐两个文本块时，这样一些改变似乎不重要——但是一组这样的变化真的能够产生不同的影响。
3.产品投放市场之前与你的设计师做一个全面检查（Do a gut check with your designer before you launch）
如果你的设计师在以上我们列出的建议中做的很好的话，请不要发布一个不给她机会来重审的专题，而以此来惩罚她——不论你认为这是多小的变动。要像信赖其他团队成员一样，信赖你的设计师。像其他成员一样，你的设计师对产品的成功也倾注了很多。
当你和你的设计师一起做全面检查时，确保在转化产品之前给她时间进行反馈，提出修改意见，以及迭代。在产品马上就投放市场前才将其“作为参考”展示给设计师，与未被设计师运行就投放市场，是一样糟糕的。
希望我在过去的几年中的经验——所有我提出的方法，能够帮助创造更牢固的设计师与工程师间的联合关系。我相信，最终这真会引导产生更加强大的产品和更好的用户体验。
关于作者：
Jenna Bilotta ：产品体验设计师，自由咨询师。参与YouTube和Google Reader的用户体验设计。
原文链接 请务必保留原作者链接
注：
《关心和犒劳软件工程师》源起于本文
扫一扫
113
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
