工程师谈与设计师合作：价值立现但一队不宜多配

我很喜欢和设计师合作，部分原因是（不同于经理和产品经理）他们在文化上与工程师截然不同。不过，一个团队里超过一个设计师就是自找麻烦，而且我对设计系统有着复杂的负面看法。

设计师能立刻展现他们的价值。在做某个功能时，我通常会先拼凑一个自己还算满意的占位 UI。然后拿给设计师看，对方摸摸下巴说“嗯，我有些想法”。接着他们离开一阵子，做出一个 mockup UI，不仅明显更好，而且好在我根本想象不到的地方。在科技公司里，没有任何其他角色能让你一眼就看到价值。

设计师在其他方面也是个不寻常的角色。工程经理、产品经理和工程师基本都来自同一类人：技术型、注重细节的计划者。我们都是和电子表格打交道的人。事实上，很多经理和产品经理曾经就是工程师：这是很自然的转型。设计师则不然。我相信肯定有例外，但我从没见过哪个设计师是从工程师转行过来的。

正因为如此，设计师在文化上与工程师距离很远。根据我的经验，这是很大的优势。我以前就抱怨过，曾经做过工程师的产品经理往往更差，而不是更好。一旦你开始试图自己做秘密的技术评估，而不是想办法信任你的工程团队，你就完了：你做不到足够好，而且你这种尝试本身就会让你无法建立所需的信任。设计师完全没有这个问题。

到目前为止，我把设计师说得像中土的精灵：神秘的生物在科技公司里飘来飘去，施展魔法。实际上，他们更像斯拉夫家庭中的家神，或者说 Domovoy。如果一个家庭里有一个 Domovoy，它会保护你的家免受灾祸。但如果你有不止一个，它们就会激烈争斗：“制造各种噪音、伤害牲畜、把主人从床上拖下来、趁人睡着时掐人等等”。同样，一个设计师能把你的粗糙产品变成真正美丽的东西——但你最好只有一个设计师，否则就是自找麻烦。

我和设计师合作最糟糕的经历，是在一个产品上有三个设计师：一开始只有一个，后来轮换离开，由两位非常资深的设计师接替。据我判断，最初的设计相当不错。不幸的是，新来的设计师不这么认为。他们做的第一件事就是把产品彻底重新设计，这意味着我不得不重写大部分前端样式。然后他们开始互相意见不合。我记得产品的每个页面都来回改了三到四次：一个设计师让我改 X，另一个又改回去，如此反复。与此同时，我还在拼命让产品能跑起来。

理论上我知道自己该做什么：把所有人叫到一个房间里互相沟通，敲定一个决定。也许在需求更稳定的产品上这能行得通，但在这里不行。品味上的差异虽然在我看来难以察觉，但实在太深了。似乎设计师 A 产出的每样东西在设计师 B 眼里都稍微有点不对，反之亦然。最后我们只能硬着头皮把每个新版本都实现出来，直到截止日期前大约一周，我才请了两层管理层作为空中掩护，把设计冻结在当时的状态。

这些设计师真的非常优秀！他们在设计上远比我强得多，而且人非常好，我很乐意再和他们合作。我只是觉得，同时和超过一个设计师合作本质上就是糟糕的。我在不同的团队和公司一遍又一遍地经历过这种情况。至于原因，我只能猜测，但有两个理论：

公司试图扩展设计工作的一种方式是制作“设计系统”：一个前端组件库，所有组件都符合设计规范，理论上可以像乐高积木一样拼装成与公司其他部分风格一致的页面。我讨厌设计系统。不过，就像民主一样，它比我见过的任何其他方式来强制实现一致设计都要好。

设计系统的第一个问题是激励问题。拥有设计系统的工程团队被激励去产出优雅的组件，让它们任何时候看起来都漂亮。使用设计系统的工程团队则被激励去产出满足不优雅或丑陋客户需求的系统。于是你就有了这场永久的拉锯战：产品团队要求某些东西——比如能够把任意图片嵌入下拉组件——设计团队则反对，因为他们担心会难看。

我上面描述的那种动态（设计师之间倾向于意见不合）让情况更糟。通常，工程团队里嵌入的设计师会推动某种与设计系统略有不同的设计，这（a）让设计系统的所有者非常不满，（b）让工程师不满，因为组件必须被折磨成一种非常细微不同的外观。

这个问题的结果是，工程团队永远在绕过设计系统：重新实现自己版本的组件，用 CSS 伸手进去调整现有组件的样式（然后每次组件更新时这些调整就会失效），等等。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）