在这个变革速度前所未有的时代，我们会听到各种各样的声音。有人说设计师得懂编程，程序员要懂市场规律，不会写文案的交互设计师不是好产品经理，等等等等。但是在这些叫嚣跨领域强调多技能的人群中，我们依然能听到一些不一样的声音。今天这篇短文来自Gaiam的产品设计总监 Jesse Weaver，作为一个资深的专业产品人，他有着不一样的考量。
越来越多的招聘条件上，明确要求需要懂代码的设计师。有的是需要设计师精通HTML、CSS和JS的，比较奇葩的是要求设计设计师懂java，深入理解C++的，至于要求设计师精通Android和iOS开发的一看就是想把开发的钱给省下来的鸡贼团队。如果你使用百度和Google搜索“设计师是否需要懂代码”，搜索结果可能多达几十万条，看来被这个问题困扰的人真的很多，迷茫的设计师真的不少。
坦率的讲，在这个设计与开发愈来愈紧密的时代，我并非完全不同意“设计师懂代码”这件事，但是在“我们需要能写代码的设计师”这件事情上，我觉得大家存在着相当的误解和歪曲。
作为产品设计团队的领导，我同样可以多少写一些代码，前端和后端的都可以，我自然也很明白拥有多技能的重要性。我能画原型，拥有跨学科的背景和能力，了解各种技能的特性，也拥有调整优化实践的技能。但是，我明白事情的界限在哪里。专业的事情，应该让专业的人来做。我不是开发者，更加不希望我写的代码被作为基础，被大规模地应用到一个专业程序中去。
说设计师应该去写代码，给人一种感觉：团队中所有人都应该全身心参与到产品的开发和生产上来。或者说，设计团队和开发团队应该从某种程度上合而为一，组成某种无缝的全功能多栖超级开发团队。
咱们还是实在点儿的好。设计和开发(不论是前端还是后端)，是高度专业化的职业，有着清晰的定位和分工。每一个这样的职业都需要若干年的时间来掌控，想在一个领域中成为专家是无法一蹴而就的。
我们真正需要的是，能真正能做好设计的设计师，能写好代码的开发者，并且设计师和开发者能够无缝地协作。
要实现两者的协作，需要一个关键的因素：移情。移情能力是设身处地理解他人感受的一种能力，这才是关键。
我们需要设计师能够了解代码和开发的流程和原理。这和会写代码是两回事。
我们希望设计师能了解开发了解代码，就像我们希望开发者能了解设计师的工作流程和原理。设计师希望开发者能用设计语言跟他们沟通，希望开发者能了解设计思考和思维过程，而不是让开发者自己打开PS给绿色的界面加一个红色的图标。
真正意义上的相互了解，深入到位的沟通，这样才能让孤立的环节有序地整合起来，在协作中打造伟大的产品。这样协作的关键点在于，了解和分工的程度要把控好，让真正的专家在他的领域自由驰骋，不要让其他人成为阻塞。
当有人说他们需要“能写代码的设计师”的时候，我想他想要的应该是一名“瑞士军刀式的设计师”。他们想要的这个角色功能很全，就像瑞士军刀一样，自带多种工具，剪刀、牙签、螺丝刀、锉刀、锯一个都不少，干啥都能上。不过电工不会选用瑞士军刀上的螺丝刀，木工也看不上瑞士军刀上的锉刀和锯，裁缝更不会指望其中内置的剪刀，至于士兵嘛，他们喜欢匕首，军刺，而且也玩得一手好工兵铲，然而工兵铲这种神器通常是不会出现在瑞士军刀上的。
瑞士军刀只是提供了最底层最基础的工具以及相当有限的功能，以至于在很多时候很难真的将其划归到“刀”这个品类中。
专业的人事需要专业的工具。同样，专业的团队需要有专业的团队成员。
我不希望我手底下的设计师，每天刷网站关注最新的跨浏览器CSS样式解决方案，或者到处找JS教程“充电”。同理，我也不希望我手下的开发者在配色理论和配色方案这样的事情上耗费时间。
我希望我的设计师能在移动端界面标注上钻研得更深，在可用性设计上有更好的实践，期待设计师们能深入研究用户习惯，能挖掘未曾被满足的用户需求，让产品设计和体验更上一层楼，这是设计师的工作。同时我也承认，了解代码是他们工作的一小部分，但是仅仅是一小部分，这一部分工作必须是高效的，并且是基于合作需求而进行适当学习和了解。
如此一来，设计师对代码有所了解，开发者对于设计有所涉猎，那么开发者能够基于用户需求对设计师的构想有所评判，设计师也能够对设计如何实现为产品深入认识，如果双方在产品原型设计上深入沟通，说不定能拿出更有说服力的方案。但是不论如何，都要规避让设计师“成为开发者”，或者让开发者“成为设计师”这样的 想法。
融合是存在的，并且有它独到的意义，但是此处并不合适。
如果你希望你的团队发挥它真正的优势，做专业的事情，通过移情效果达成协作，那么你的团队不需要瑞士军刀式的成员。真正能在专业领域深入挖掘的成员——设计师、开发者——才是你需要的人，让他们走到一起，组成你的工具箱。
这才是我们要的。
