说真的，我们不需要「会写程式的设计师」
photo credit: Trevor Grant
英文原文：We Don’t Need More Designers Who Can Code
设计师究竟该不该会写程式？把这个问题丢到 Google，可以得到数以千百万计的结果，可见许多设计师都有这样的迷惘，因为市场上对于「会写程式的设计师」的需求也极饥渴。但在 Gaiam TV 产品设计总监 Jesse Weaver 心中，这是个天大的迷思，他在 Medium 发表文章表示，我们不该强求设计师「会写」程式，而是「了解」程式。
市场上对于「会写程式的设计师」的需求有多热切？在 Google 上针对「should designers learn to code（设计师该学写 code 吗）」的搜寻结果多达 2500 万笔。
话说前头，我不是不同意设计师应该学写程式的说法，但是我认为这个主张扭曲了真正的问题。
身为产品设计团队的领导者，我的确会写前端跟后端程式，我理解程式加上设计的技能组合价值有多不菲。做出原型的能力，随时转换跨界的能力，了解功能、调整启用的能力。但我也知道我的能力有限。我不是个开发者，而且我也不希望我写的程式被放在规模化的 app 底层。
设计师该学程式的说法，形塑了一种意识，无论是谁所有人都得提交 commits 到製作环境（production environments）。更甚者，设计团队与开发团队理所当然应该合体变成超人，化身成为 full-stack 的网路怪兽。
承认吧，设计与开发都是高度专业化的职业，两者都分别需要耗费无数心力与时间，才能焠鍊出问心无愧的职能。指望某个人能够同时精通两门专业，无疑是痴人说梦。
我们真正迫切需要的是：能够在设计上出神入化的设计师，能够在开发上登峰造极的开发者，两者能够默契十足的并肩合作。
达成这个目标的关键要素：同理心（empathy）。
我们应该宣导的观念应该是，这个世界需要更多「了解（know about）」程式的设计师。
设计师应该了解程式，开发者也应该了解设计。并非要你真的跑去学程式或设计，而是双方应该设身处地的为彼此着想。就以「了解设计」的开发者来 说，他们懂得以设计师的语言与之对话，他们理解设计师的考量以及思考过程，To know just enough to be dangerous, as they say.
这是冰山融解的时刻，开启对话，携手协作。但重点是，彼此理解的过程，不会成为双方在各自的专业领域精进的绊脚石。
photo credit: Edgar Pierce
如果有个人说他需要「会写程式的设计师」，在我耳中听来就像索取一把瑞士刀，螺丝起子、剪刀、刀子、牙签、锯子，什么工具都有，什么工具都不堪 用。专业的木匠不会使用瑞士刀上的螺丝起子撬开螺丝，专业的裁缝师也不会用瑞士刀上的剪刀裁剪布料。瑞士刀可以行使最基本的作用，但是难以替代真正各司其 职的工具。何况，因为它太想当全能者了，导致连本来作为主角的小刀，锋芒也称不上锐利。
专业的工作者需要专业的工具，如同专业的团队，是由专业的成员组成。
我不需要团队中的设计师花时间追赶最新的跨浏览器 CSS 解法，或者学习怎么使用 javascript closures；当然，开发者也毋需绞尽脑汁钻研色彩理论。
如果非得熬夜，我期待我的设计师思考的是行动介面标准，积极追上最新的易用性原则，他们的责任是研究使用者，辨识出尚未被满足的需求。我要他们专心琢磨产品，尽可能臻至完美。当然，他们最好也抽出一点时间了解程式，以增加效率，对不那么熟悉的开发者伙伴，产生同理心。
了解程式，或了解设计的真谛是，把双手弄髒吧。开发者要学着从使用者中心的角度，审视设计概念，设计师则该知道，在程式的支撑之下，他们的设计 会怎么被实践。如果两者能够同心协力做个原型出来，最好。不过我们必须抛开「设计师应该成为开发者，或开发者应该成为设计师」的主张，那是束缚双方的压力 来源。
神人也许存在，但不能要求所有人都技能满点。
如果你能激发团队成员淋漓尽致发挥专才，并且鼓励他们培养同理心，那你根本不需要瑞士刀。相反的，你已拥有一箱由不同专长组成、却又能够并肩合作的顶尖专家。
这才是我们真正需要建构的团队。