写给设计师：如何与工程师一起工作

Julie Zhuo（ Facebook 产品设计总监）：多年前，我曾当过产品经理，然后是工程师，过去七年从事的是设计工作。每天我都跟担任这些角色的人一起工作，每一天，我对产品开发背后的责任、挑战和艺术都有新的体会。工程师是团队的魔术师，他们拿到开发计划、图像素材后，只需轻轻舞动手指，Voila（看哪）！产品就动起来了。身为一个设计师，妳要如何跟上他们精明、喜好自嘲却又按部就班的做事节奏呢？请继续读下去。

工程师就是那个将点子化为现实的人

工程师可以让好的提案变成真的，永远、永远不要忘记这件事。不管妳的公司有 5 个、500 个还是 5000 个工程师，工程师都不是一种「资源」。他们是打下基础、让产品动起来的守护者。他们使产品得以运作，而且运作起来速度飞快；他们使产品坚固、耐用、可靠，还能让产品规模化，使数以亿计的人受益。

我说这些的意思是：工程师超厉害！
这表示……

想让神奇的事发生？妳只需要说服一、两个工程师

这是真的。许多传奇性的产品故事都是这样开始的：几个朋友、一个周末、几罐啤酒、一起「骇」一下，产品经理和主管加入都是之后的事。他们会从基本的东西开始——一个想法、一个设计、一个实作。这就是为什么公司要付钱来换取与工程师之间的紧密联系。

或是，想象一下这个情境：妳发现产品有一个小小的部分令人很不舒服，真的很受不了的那种。妳觉得那个设计根本就不对。妳该怎么办？

1. 下次团队开会时提出来，让负责安排任务优先级的人放入列表，留给之后某个新进工程师「练习一下」以适应环境。
2. 紧盯着某个工程师，走到她的桌边，问她是不是可以花个五分钟处理这个问题。看着她交出成果（也许必须用 80 年代知名乐团设计一件 T-shirt 之类的作为交换，反正妳对 Illustrator 很在行）。

猜猜看哪个选项可以最快解决问题？
这样说吧……

如果合作的工程师也欣赏设计的价值，那么事情就容易多了

当妳所合作的工程师，不必问妳每一项细节也知道该如何填补模拟画面的不足之处，即便妳忘了在模拟画面标出网页边界距离是几个像素，她自己也会打开 Photoshop 测量——这是多么美妙的事。特别是她还能给出一些让设计变得更好的意见，这简直不可思议。更惊人的是，这样的工程师完成第一个版本后，妳会几乎分辨不出她做的东西跟妳给的模拟画面有何区别，一切的细节是那么的精准到位。

要怎么样才能跟这种等级的工程合作呢？Well，妳可以雇用他们。如果可以的话那妳真的很幸运，因为 UI 设计导向的工程师可是大家抢着要。

或是妳可以协助合作的每一位工程师学会欣赏好设计。该怎么做？别只是把仿真画面丢给工程师——好好地跟他们解释妳的设计。与他们分享妳的价值，告诉他们为什么妳的设计提案值得被开发出来。协助他们学习如何判断实作出来的成品与妳的设计是否相符。当妳说某个东西看起来不好的时候，告诉工程师妳是怎么想的。

建立关系很重要

人们价值观与优先级的移转都建立在与他人的对话之上。这很老派，但用来做事非常有效。

很多工程师或许不注重设计上的细节，但是他们大部分都很在乎使用者体验，而且会想要把它变得更好。我不是说每一个设计师都很享受设计细节的工作，但工程师那份为了让产品变得更好的心，有助于我们对他们解释设计背后的理念。

因为工程师越是喜欢设计，他们越能够理解背后的思维，看见设计的价值，进而让设计越快完成实作，而且还会做得更好。

尽早了解工程上的限制，也为自己节省时间

身为设计师，很容易栽进「如果」的世界。如果我们可以读懂妳的心思，明白妳想要、想看的是什么，并且呈现给妳呢？如果你点了这个按钮之后画面就爆出一阵火光的特效呢？

如果你没有及早搞懂技术或时间上的限制，那就别为了根本不可能实现的设计费心。（就算这是个值得一试的设计也一样，如果你真的明白它的限制，就会知道这有多困难。）最糟的情况是妳投注大量时间和心血去完善设计，倒头来却发现根本不可行。好的设计师已经够少了，要解决的大问题又那么多，我们最不需要的就是这类没效率的事。

所以下次如果有什么好点子冒出来，但妳心中对于是否可行却感到疑虑重重时，别猜，直接问工程师。

另一边也一样……

省下工程师的时间；随时让他们知道最终设计长什么样子

如果妳要工程师去实作一项设计，但是在看见成品之前自己也不太确定设计可以运作得多好，那么请妳一定要让工程师知道很有可能东西还会再修改。对他们而言没什么比熬夜赶工后却拿到一张写着「哎呀，整个设计已经改啰」的便条更困扰，这下子他们只得把自己全心投入、几乎已是产品水平的程序代码给丢掉。

当然，没有哪个工程师不曾把程序代码砍掉重练的。这就是工作的一部分，设计也是。好的工程师知道产品开发过程会是一团乱，东西做出来之前我们不会知道是否行得通。事情会变来变去，设计会改来改去。但是决定出哪些部分仍须继续探索、哪些部分必须就此定下来，可以帮工程师理出程序代码的架构——到底要赶快写出来呢，还是写得弹性一点，之后再行修改。

确保工程师可以把东西做出来的最佳办法，就是极度密切地合作

要像「东西完成的时候妳就坐在他们旁边」那样密切。我不知道该怎么说才不会显得过度强调：确保大家进度一致最容易的办法，就是大家在同一个空间工作。如此一来，问题浮现、被解决的速度会快很多。

最终产品完成后要是得不到大家的爱，批评、责难便很容易纷沓而至。「喔，我的模拟画面好极了，但工程师做得不对。」这是有害的想法。妳，设计师，拥有的是要对用户发表的产品，不是妳计算机里的 Photoshop 仿真画面。如果有什么地方做得不对，妳怎不有所行动？妳怎么不请工程师完工后为妳展示一下，好让你们审视细节？为什么在实作的过程中妳不问工程师对设计有没有疑问？为什么妳看到 bug 后没有立即开票请工程师处理？

对，去拥有它。

工程师最在乎的，是设计要完整

很有趣，人们形容设计师是「细节导向」，但事实上大部分他们给的设计规格会遗漏很多使用上可能遭遇的状况，最后靠着必须将所有情形都实作的工程师去把他们找出来。

想成为工程师心中的设计英雄吗？请确定妳的设计解决方案是完整的、已考虑所有极端情形，像是：

1. 国际化：妳的设计在其他语言下看起来如何？有注意到德文那些很长的字对排版所造成的威胁吗？
2. 错误状态：网络突然中断的话会发生什么事？如果数据库当掉了呢？或是其他类似的情况。
3. 极端的使用者：用户如果没有活动或信息，让这一页空白的话怎么办？或是他有太多活动记录或信息怎么办？
4. 转换：到底 A 画面转换到 B 画面的具体方式是？好的工具或许能帮上忙，请看 〈 How to Survive in Design (and in a Zombie Apocalypse). 〉。

设计上述这些状况不仅能在全面检视过妳的设计后建立起信心，还有助于工程师规划整个系统的架构，对于开发时程给予适当的评估。更不用说完整的设计还可以避免最后一分钟才仓徨拼凑出一堆空白的烂东西——只因没人发觉，此时再来补救也为时已晚。

请当个乖宝宝。确定妳的设计是完整的。别只为理想的使用情形做设计，踏出那个满是模拟画面的太虚幻境。就像每个工程师都知道的，只有把产品做出来才算数。
原文地址：medium.com