原文作者：quora Xiaoji Chen
原文鏈接：From：http://www.quora.com/Why-dont-more-designers-code/answer/Xiaoji-Chen#
翻譯：劉文彬
由于程序員和設(shè)計(jì)師并不總是能夠溝通順暢届垫，這導(dǎo)致了軟件中很多問(wèn)題的發(fā)生聪全。那么微酬，為什么大多數(shù)設(shè)計(jì)師們不自己編程或者讓工程師們?yōu)樗麄兘ㄔO(shè)更適配他們的架構(gòu)呢？
而且相比之下橄务，為什么這個(gè)現(xiàn)象在交互設(shè)計(jì)領(lǐng)域要比工業(yè)設(shè)計(jì)幔托、通訊設(shè)計(jì)或者別的什么領(lǐng)域更嚴(yán)重呢？在其他的分支領(lǐng)域蜂挪，設(shè)計(jì)師們知道如何使用工具或者擁有可以用來(lái)創(chuàng)造終端產(chǎn)品的工具重挑。
xiaoji' answer：
在回答這個(gè)問(wèn)題之前，我想把這個(gè)問(wèn)題闡釋為：為什么大多數(shù)設(shè)計(jì)師本應(yīng)該會(huì)敲代碼而他們卻不這么做棠涮？
前邊的各位答主說(shuō)得都很好谬哀。我理解為什么大家會(huì)有這些反應(yīng)——上邊這個(gè)問(wèn)題本身聽(tīng)起來(lái)就像是在傲嬌控訴，這樣的討論會(huì)很快演變成“開發(fā)者VS.設(shè)計(jì)師”式的撕逼严肪。不過(guò)無(wú)論如何史煎，我還是準(zhǔn)備從我的角度向我的設(shè)計(jì)師同行們喊喊話。
——為什么設(shè)計(jì)師們應(yīng)該編程
大多數(shù)在互聯(lián)網(wǎng)領(lǐng)域工作的專業(yè)設(shè)計(jì)師們會(huì)告訴你說(shuō)他們從來(lái)不知道怎樣編程也干得很好驳糯。事實(shí)上篇梭，大多數(shù)我每天打交道的那些設(shè)計(jì)師們也不敲代碼，跟他們合作起來(lái)也挺愉快的酝枢。不過(guò)恬偷，正如他們的經(jīng)驗(yàn)告訴他們自己不敲代碼顯得有逼格一樣，我的經(jīng)驗(yàn)告訴我隧枫，會(huì)敲代碼會(huì)好一些喉磁。
很多通用編程教育的擁護(hù)者們認(rèn)為，對(duì)于設(shè)計(jì)師來(lái)說(shuō)官脓，學(xué)習(xí)敲代碼有助于設(shè)計(jì)師理解設(shè)計(jì)的可能性和約束。其實(shí)事實(shí)并非如此涝焙。我壓根不能算一個(gè)好的開發(fā)人員卑笨，也從來(lái)不寫高質(zhì)量的產(chǎn)品代碼，我所參與的產(chǎn)品的復(fù)雜性也遠(yuǎn)遠(yuǎn)超出我的知識(shí)范圍仑撞。不要想著是為了團(tuán)隊(duì)而學(xué)習(xí)編程赤兴，要想著是為了我們自己。代碼是我的草圖隧哮。對(duì)我來(lái)說(shuō)桶良，編程是我自己設(shè)計(jì)過(guò)程中的非常有必要的步驟。
想象一下如果一個(gè)藝術(shù)家不畫畫會(huì)是怎樣的一種體驗(yàn)沮翔。每天早桑陨帆，他把自己的想法告訴助手。然后，助手嘗試著把藝術(shù)家腦袋里的想法破譯出來(lái)疲牵，再在畫板上重現(xiàn)出來(lái)承二。一天結(jié)束后，藝術(shù)家看一眼最后的成品纲爸，要么滿意要么不滿意亥鸠，然后給出新的指示。在這個(gè)過(guò)程中會(huì)有以下幾個(gè)問(wèn)題：
- 效率極低识啦。整個(gè)過(guò)程十分痛苦负蚊，關(guān)鍵是幾乎不可能有效率的產(chǎn)出。不會(huì)有太多的機(jī)會(huì)試錯(cuò)颓哮，藝術(shù)家要費(fèi)好大的勁才能最終實(shí)現(xiàn)想法中的細(xì)節(jié)家妆。
- 藝術(shù)家對(duì)產(chǎn)品的控制力非常弱。他只能從助手提供給他的幾個(gè)有限選項(xiàng)中進(jìn)行選擇题翻。他指望找到個(gè)聰明絕頂?shù)闹挚梢詼?zhǔn)確理解任何想法揩徊，但是優(yōu)秀的畫家會(huì)擁有非常強(qiáng)的個(gè)人風(fēng)格，這絕對(duì)會(huì)讓藝術(shù)家抓狂嵌赠。
- 畫筆和畫板上接觸方式以及濕度的些微不同會(huì)帶來(lái)怎樣微妙的差別塑荒，藝術(shù)家無(wú)從知曉。他的預(yù)見(jiàn)能力可能在精妙和平庸之間搖擺不定姜挺。最終他會(huì)越來(lái)越傾向于簡(jiǎn)明直白地表達(dá)自己的想法齿税，因?yàn)闆](méi)有太多的機(jī)會(huì)讓他們?cè)囧e(cuò)。
盡管看起來(lái)挺荒謬的炊豪，但類似的情形在大多數(shù)的軟件團(tuán)隊(duì)中時(shí)不時(shí)地發(fā)生著凌箕，也包括很多特定領(lǐng)域的設(shè)計(jì)團(tuán)隊(duì)。
作為一個(gè)交互設(shè)計(jì)師词渤，我做的事不僅僅是設(shè)計(jì)軟件的樣子牵舱，我更多地是保證軟件如何表現(xiàn)。觸摸的壓力缺虐、速度和加速度會(huì)讓我的UI有不同的反應(yīng)芜壁。它會(huì)讓人覺(jué)得自然還是感到困惑？應(yīng)該有多大程度的反饋高氮？我可以多快地重復(fù)操作慧妄？除非我在一個(gè)功能原型上自己動(dòng)手忙活，否則我壓根沒(méi)辦法搞定上邊的一連串問(wèn)題剪芍。如果我就是等著別人幫我整塞淹，那就會(huì)嚴(yán)重拖慢進(jìn)度，我也沒(méi)有什么可以調(diào)整的空間罪裹。
此外饱普，我還希望自己的設(shè)計(jì)能達(dá)到像素完美运挫。就像在PS中微調(diào)對(duì)象，我希望能實(shí)時(shí)地看到改變后的呈現(xiàn)效果费彼，因此我有時(shí)會(huì)一個(gè)小時(shí)內(nèi)試驗(yàn)上百個(gè)版本效果滑臊。我不知道別人是怎么做的，但我會(huì)各種可能性中嘗試一堆的的垃圾效果箍铲。這甚至讓很多開發(fā)人員都無(wú)法理解雇卷。
不過(guò)，讓題主失望的是颠猴，我敲出來(lái)的代碼跟開發(fā)者們寫的代碼有很大差別关划。我的代碼不關(guān)心兼容性、（某種程度上的）呈現(xiàn)效果以及可擴(kuò)展性和保真度翘瓮。然而贮折，只有我知道我的設(shè)計(jì)中哪部分好還是不好。我可以代碼中發(fā)現(xiàn)問(wèn)題并沉浸其中好幾個(gè)小時(shí)资盅。我還會(huì)順手學(xué)習(xí)那些幫助我理解的工具调榄。我現(xiàn)在已經(jīng)在在工作中頻繁地使用Flash, Processing, HTML/JavaScript, WPF/C#了。我選擇的工具往往跟產(chǎn)品最終的運(yùn)行平臺(tái)沒(méi)什么必然關(guān)聯(lián)呵扛，但他們對(duì)于展現(xiàn)我的想法相當(dāng)有幫助每庆。
功能原型使我做出更好的設(shè)計(jì)，也使我更有效地和工程師團(tuán)隊(duì)進(jìn)行溝通以及更好地進(jìn)行可行性測(cè)試今穿。毫無(wú)疑問(wèn)缤灵，得益于可以快速地建模、測(cè)試以及調(diào)整設(shè)計(jì)方案蓝晒，我可以更好地優(yōu)化它們∪觯現(xiàn)在原型設(shè)計(jì)已經(jīng)成為我設(shè)計(jì)流程中的重要部分，我已經(jīng)難以想象只用故事板做設(shè)計(jì)會(huì)是怎樣的一種體驗(yàn)芝薇。
——為什么大多數(shù)設(shè)計(jì)師不敲代碼
這得先從勞動(dòng)分工說(shuō)起胚嘲。
在進(jìn)入軟件工程領(lǐng)域之前，我在建筑學(xué)校讀了6年洛二。精通設(shè)計(jì)簡(jiǎn)直就是個(gè)神話慢逾。盡管不少老師宣稱設(shè)計(jì)可以按部就班地實(shí)現(xiàn)，但在大家的理解里灭红，設(shè)計(jì)更多地還是靠天分和靈感。設(shè)計(jì)師們從來(lái)不愿干別人已經(jīng)干過(guò)的事口注。我花了好幾年的時(shí)間批判和研究哲學(xué)而不是老老實(shí)實(shí)搬磚变擒。這種教育在想法創(chuàng)造者和執(zhí)行者之間畫了一條清晰的分界線，分界線另一面的世界神秘而又危險(xiǎn)寝志。
我遇到過(guò)很多持不同準(zhǔn)則的設(shè)計(jì)師和工程師娇斑，他們一旦察覺(jué)到有人越界策添，就會(huì)強(qiáng)硬地保護(hù)屬于他們自己的領(lǐng)地。他們聲稱沒(méi)有接受過(guò)完整訓(xùn)練的人不可能全面地理解他們的特權(quán)領(lǐng)域毫缆，因此那些越界者活該被無(wú)視唯竹。同樣是這批家伙，他們不愿意學(xué)習(xí)新東西苦丁，也對(duì)那些不符合他們心中準(zhǔn)則的東西嗤之以鼻浸颓。那樣的態(tài)度，嚇退了一些對(duì)編程有好奇心的設(shè)計(jì)師旺拉，因?yàn)樗麄兟?tīng)到了諸如“你干嘛不把時(shí)間用在更有生產(chǎn)力的事情上”“要想學(xué)出點(diǎn)門道得花上好幾年時(shí)間”“要想學(xué)編程要先學(xué)編譯原理”之類的評(píng)論……有朋友稱之為“不安全感”产上。
其次，現(xiàn)在很多科技公司的運(yùn)行模式也不鼓勵(lì)在工作上越位蛾狗。令人感到諷刺的是晋涣，我知道有不少相當(dāng)有創(chuàng)造力的會(huì)編程的設(shè)計(jì)師找不到工作。一個(gè)技術(shù)大牛級(jí)的設(shè)計(jì)師朋友來(lái)自一個(gè)相當(dāng)之名的設(shè)計(jì)機(jī)構(gòu)沉桌，在多個(gè)平臺(tái)上寫過(guò)應(yīng)用谢鹊，項(xiàng)目能力非常突出，但在面試幾個(gè)知名的科技公司時(shí)都失敗了留凭，原因竟然是那些公司的職位都跟她想做的事不匹配佃扼。因?yàn)槟切﹫F(tuán)隊(duì)不知道該將她安插在產(chǎn)品鏈的什么位置上，他們甚至問(wèn)她問(wèn)題時(shí)都問(wèn)不到點(diǎn)子上冰抢。
在我的實(shí)際工作中松嘶，在我寫任何產(chǎn)品原型之前，我總是向產(chǎn)品經(jīng)理保證我不是要提交代碼挎扰，也不是要指揮他們?nèi)绾胃愣üぷ鞔涠Ｍ瑫r(shí)我還會(huì)向那些不敲代碼的設(shè)計(jì)師同事詢問(wèn)每一個(gè)步驟，以免讓他們覺(jué)得自己被挾制遵倦。在向設(shè)計(jì)步驟提供附加值和冒犯同事之間尽超，有一條微妙的界限。
在一個(gè)已成型的系統(tǒng)中中改變?cè)O(shè)計(jì)實(shí)現(xiàn)方法并非那么容易梧躺，但是變化已經(jīng)正在進(jìn)行似谁。剛從學(xué)校出來(lái)的年輕設(shè)計(jì)師們會(huì)寫JavaScript, Processing, open Frameworks等等。這是“我會(huì)做任何事情為設(shè)計(jì)實(shí)現(xiàn)鋪路”精神的起點(diǎn)掠哥。隨著大眾化編程工具的流行巩踏，我期待這個(gè)產(chǎn)業(yè)中會(huì)有越來(lái)越多跨界和更深的碰撞。
當(dāng)更多的想法被實(shí)現(xiàn)续搀，這個(gè)世界會(huì)變成更美好的人間塞琼。
附原文（來(lái)自Quora）：
Why don't more designers code?
So many problems in software occur because programmers and designers don't communicate well all the time. Why don't more designers learn to code themselves or have engineers build abstractions better suited to them?
Also, why is it that this is more true ofinteraction design than industrial, communication or otherwise. In otherbranches, designers know how to use tools or have ones they can use to createthe end product. Is it a matter of time before the right software abstractionsare written?
xiaoji' answer：
I would like to begin my answer by elaborating the question: why don't more designers code (when they should)?
The answers above are great. I understand where they come from - the question itself sounds like an accusation, and the discussion can soon escalate to a developer vs. designer standoff.Nevertheless, I am going to challenge my fellow designers a bit on my end.
Why should designers code
Most professional designers working in software / service tell you that they don't know how to code and do their jobs just fine. In fact, most of the designers that I interact with everyday cannot code, and it's been a pleasure working with them. However, just like their experience tells them that not coding is cool, my experience tells me that codingis better.
Many advocates of universal programming education argue that learning it is for a designer to understand the feasibility and constraints of design. That is not true. I am nowhere near a good developer, I never write production quality code, and the complexity of the products that I work on are way beyond my knowledge. Instead of learning for the team, think more about learning for ourselves. Coding is my sketching.It is an essential step in my own design process.
Imagine an artist who does not draw. Every morning he talks to an assistant about his ideas. The later tries to decode what he has in mind and reproduce it on canvas. At the end of day, the artist will be able to look at the outcome, be happy or unhappy about it, and give new instructions. The problems of this process are:
Very low efficiency. The cycle is so painfully long that fine tuning is almost impossible. There cannot be many trials and errors; the artist will eventually learn to let some details go.
The artist has very weak control over the product. He can only choose from a range of options that his assistant offer shim. He wants to hire a brilliant assistant that can realize anything, but good painters also comes with strong opinions of their own, which greatly annoys him.
The artist is not aware of certain subtle differences it makes how the brush touches the canvas, the humidity, etc.Sometimes his vision turns out great; sometimes it is flat. He eventually incline to propose very loud and explicit ideas only, because there's less chance they will come out wrong.
Absurd as it sounds, the same dynamic is common practice in most software teams, as well as many design shops that involve heavily specialized domains.
As an interaction designer, I don't just design how things look, I design how they behave. The pressure, speed and acceleration of touch makes my UI respond differently. Does it feel natural or confusing? How much compensation is required? How fast can I repeat the task?There is no way for me to know unless I have my hands on a functional prototype, use it, hate it, and change it. If I had always waited for someone else to implement them for me, it would have been too late in the process and left me little space to turn around.
I also want my designs to be pixel-perfect.Just like nudging objects around in Photoshop, I want to see the change live,so I can try out a hundred iterations in an hour. I don't know about other people, but I try a lot of crap when I mess around the possibilities. There's no developer that can understand me while put up with me as well as I can do with myself, 24/7.
To the disappointment of the owner of this question, the code I write is quite different from what the developers write.It cuts away the concerns about compatibility, (some level of) performance andscalability, sometimes fidelity. However, only I know best which is the point of my design and which is not. From scratch I can get something to play with in a few hours. I pick whatever tool that realizes my vision fast. I have used Flash, Processing, HTML/JavaScript, WPF/C# heavily in my work. My tools ofchoice mostly have nothing to do with the platform my final products run on, as long as they are sufficient to showcase my idea.
Functional prototypes enable me to better make design decisions, communicate my proposals to the engineering team, and run usability studies. There is no doubt that I deliver more polished design solutions by rapidly building, testing and tweaking them. Now that prototyping has become part of my design flow, I cannot imagine doing my job with click-through storyboards only.
Why don't more designers code
It starts with division of labor.
I went to school of architecture for 6 years before heading into the software industry. The mastery of design is largely a myth. Although most teachers claimed that design could berationalized, part of it was always described as relying on talent and inspiration, even spiritual experience. Designers don't do things that have been done before. I spent years criticizing and developing philosophies in stead of laying out bricks by hand. The education draws a clear line between the people who generate ideas and the people who execute them. The world on the other side of the line is mysterious and dangerous.
I have come across many designers and engineers, of all disciplines, who violently protect their territories when they detect someone trampling the border. They claim that an untrained person can never understand the full extent of their respective area, there fore his/her opinions and efforts ought to be ignored. Those also happen to be the same people who are not willing to learn about new things, despise other disciplines, and rule everything not compliant with their ways as impossible.That attitude, from both sides, scares away a lot of designers who are curious about programming, with comments like "why don't you apply your time to something more productive", "it takes years of training before you can do anything meaningful" or "you will never understand code unless you study compiler theories." A friend calls that insecurity.
Secondly, the way that many tech companies structure today do not encourage working out of the box.
In spite of some employer's pursuit after the Unicorn Designer [The Myth of the Myth of the Unicorn Designer by David Cole], ironically, I know quite a few creative coders who have difficulty even getting hired. A hacker-designer friend who came from a famous design institution, had written applications on multiple platforms and demonstrated her capabilities with strong projects, failed in interviews with some of the biggest tech names, because what she wanted to do didn't fit in any of their job descriptions. Since the hiring teams didn't know where to place her on their production chain, they couldn't even ask the right questions.
In my full time job, where I luckily enjoy doing both, before I write any prototype, I always need to assure the PMs that I'm not committed to shipping code, nor trying to tell them how to get their job done. I also remember to ask the non-coder designers for opinions every step of the way, so that they don't feel hijacked. There is a thin line between being avaluable add-on to the design process and offending coworkers.
It is not easy to change how design is done in an established system, but it's under way. More and more young designers coming out of school today write JavaScript, Processing, open Frameworks etc. It is the start-up-like "I'll do whatever it takes to make my ideas happen"spirit. With thriving tools that democratize coding, I expect more and more crossover and deep collaboration in the industry. How fast has the web UI patterns evolved over the last decade, partly because it is so easy to implement and deploy for? The world will become a better place when more ideas are made happen
