我們並不需要更多會寫代碼的設計師！

 　　在這個變革速度前所未有的時代，我們會聽到各種各樣的聲音。有人說設計師得懂編程，程序員要懂市場規律，不會寫文案的交互設計師不是好產品經理，等等等等。但是在這些叫囂跨領域強調多技能的人群中，我們依然能聽到一些不一樣的聲音。今天這篇短文來自Gaiam的產品設計總監 Jesse Weaver，作為一個資深的專業產品人，他有著不一樣的考量。

　　越來越多的招聘條件上，明確要求需要懂代碼的設計師。有的是需要設計師精通HTML、CSS和JS的，比較奇葩的是要求設計設計師懂JAVA，深入理解C++的，至於要求設計師精通Android和iOS開發的一看就是想把開發的錢給省下來的雞賊團隊。如果你使用百度和Google搜索“設計師是否需要懂代碼”，搜索結果可能多達幾十萬條，看來被這個問題困擾的人真的很多，迷茫的設計師真的不少。

　　坦率的講，在這個設計與開發愈來愈緊密的時代，我並非完全不同意“設計師懂代碼”這件事，但是在“我們需要能寫代碼的設計師”這件事情上，我覺得大家存在著相當的誤解和歪曲。

　　作為產品設計團隊的領導，我同樣可以多少寫一些代碼，前端和後端的都可以，我自然也很明白擁有多技能的重要性。我能畫原型，擁有跨學科的背景和能力，了解各種技能的特性，也擁有調整優化實踐的技能。但是，我明白事情的界限在哪裡。專業的事情，應該讓專業的人來做。我不是開發者，更加不希望我寫的代碼被作為基礎，被大規模地應用到一個專業程序中去。

　　說設計師應該去寫代碼，給人一種感覺：團隊中所有人都應該全身心參與到產品的開發和生產上來。或者說，設計團隊和開發團隊應該從某種程度上合而為一，組成某種無縫的全功能多棲超級開發團隊。

　　咱們還是實在點兒的好。設計和開發(不論是前端還是後端)，是高度專業化的職業，有著清晰的定位和分工。每一個這樣的職業都需要若干年的時間來掌控，想在一個領域中成為專家是無法一蹴而就的。

　　我們真正需要的是，能真正能做好設計的設計師，能寫好代碼的開發者，並且設計師和開發者能夠無縫地協作。

　　要實現兩者的協作，需要一個關鍵的因素：移情。移情能力是設身處地理解他人感受的一種能力，這才是關鍵。

　　我們需要設計師能夠了解代碼和開發的流程和原理。這和會寫代碼是兩回事。

　　我們希望設計師能了解開發了解代碼，就像我們希望開發者能了解設計師的工作流程和原理。設計師希望開發者能用設計語言跟他們溝通，希望開發者能了解設計思考和思維過程，而不是讓開發者自己打開PS給綠色的界面加一個紅色的圖標。

　　真正意義上的相互了解，深入到位的溝通，這樣才能讓孤立的環節有序地整合起來，在協作中打造偉大的產品。這樣協作的關鍵點在於，了解和分工的程度要把控好，讓真正的專家在他的領域自由馳騁，不要讓其他人成為阻塞。

　　當有人說他們需要“能寫代碼的設計師”的時候，我想他想要的應該是一名“瑞士軍刀式的設計師”。他們想要的這個角色功能很全，就像瑞士軍刀一樣，自帶多種工具，剪刀、牙簽、螺絲刀、锉刀、鋸一個都不少，干啥都能上。不過電工不會選用瑞士軍刀上的螺絲刀，木工也看不上瑞士軍刀上的锉刀和鋸，裁縫更不會指望其中內置的剪刀，至於士兵嘛，他們喜歡匕首，軍刺，而且也玩得一手好工兵鏟，然而工兵鏟這種神器通常是不會出現在瑞士軍刀上的。

　　瑞士軍刀只是提供了最底層最基礎的工具以及相當有限的功能，以至於在很多時候很難真的將其劃歸到“刀”這個品類中。

　　專業的人事需要專業的工具。同樣，專業的團隊需要有專業的團隊成員。

　　我不希望我手底下的設計師，每天刷網站關注最新的跨浏覽器CSS樣式解決方案，或者到處找JS教程“充電”。同理，我也不希望我手下的開發者在配色理論和配色方案這樣的事情上耗費時間。

　　我希望我的設計師能在移動端界面標注上鑽研得更深，在可用性設計上有更好的實踐，期待設計師們能深入研究用戶習慣，能挖掘未曾被滿足的用戶需求，讓產品設計和體驗更上一層樓，這是設計師的工作。同時我也承認，了解代碼是他們工作的一小部分，但是僅僅是一小部分，這一部分工作必須是高效的，並且是基於合作需求而進行適當學習和了解。

　　如此一來，設計師對代碼有所了解，開發者對於設計有所涉獵，那麼開發者能夠基於用戶需求對設計師的構想有所評判，設計師也能夠對設計如何實現為產品深入認識，如果雙方在產品原型設計上深入溝通，說不定能拿出更有說服力的方案。但是不論如何，都要規避讓設計師“成為開發者”，或者讓開發者“成為設計師”這樣的 想法。

　　融合是存在的，並且有它獨到的意義，但是此處並不合適。

　　如果你希望你的團隊發揮它真正的優勢，做專業的事情，通過移情效果達成協作，那麼你的團隊不需要瑞士軍刀式的成員。真正能在專業領域深入挖掘的成員——設計師、開發者——才是你需要的人，讓他們走到一起，組成你的工具箱。

　　這才是我們要的。