原文作者：quora Xiaoji Chen
原文链接：From：http://www.quora.com/Why-dont-more-designers-code/answer/Xiaoji-Chen#
翻译：刘文彬
由于程序员和设计师并不总是能够沟通顺畅，这导致了软件中很多问题的发生。那么，为什么大多数设计师们不自己编程或者让工程师们为他们建设更适配他们的架构呢？
而且相比之下，为什么这个现象在交互设计领域要比工业设计、通讯设计或者别的什么领域更严重呢？在其他的分支领域，设计师们知道如何使用工具或者拥有可以用来创造终端产品的工具。
xiaoji' answer：
在回答这个问题之前，我想把这个问题阐释为：为什么大多数设计师本应该会敲代码而他们却不这么做？
前边的各位答主说得都很好。我理解为什么大家会有这些反应——上边这个问题本身听起来就像是在傲娇控诉，这样的讨论会很快演变成“开发者VS.设计师”式的撕逼。不过无论如何，我还是准备从我的角度向我的设计师同行们喊喊话。
——为什么设计师们应该编程
大多数在互联网领域工作的专业设计师们会告诉你说他们从来不知道怎样编程也干得很好。事实上，大多数我每天打交道的那些设计师们也不敲代码，跟他们合作起来也挺愉快的。不过，正如他们的经验告诉他们自己不敲代码显得有逼格一样，我的经验告诉我，会敲代码会好一些。
很多通用编程教育的拥护者们认为，对于设计师来说，学习敲代码有助于设计师理解设计的可能性和约束。其实事实并非如此。我压根不能算一个好的开发人员，也从来不写高质量的产品代码，我所参与的产品的复杂性也远远超出我的知识范围。不要想着是为了团队而学习编程，要想着是为了我们自己。代码是我的草图。对我来说，编程是我自己设计过程中的非常有必要的步骤。
想象一下如果一个艺术家不画画会是怎样的一种体验。每天早桑，他把自己的想法告诉助手。然后，助手尝试着把艺术家脑袋里的想法破译出来，再在画板上重现出来。一天结束后，艺术家看一眼最后的成品，要么满意要么不满意，然后给出新的指示。在这个过程中会有以下几个问题：
- 效率极低。整个过程十分痛苦，关键是几乎不可能有效率的产出。不会有太多的机会试错，艺术家要费好大的劲才能最终实现想法中的细节。
- 艺术家对产品的控制力非常弱。他只能从助手提供给他的几个有限选项中进行选择。他指望找到个聪明绝顶的助手可以准确理解任何想法，但是优秀的画家会拥有非常强的个人风格，这绝对会让艺术家抓狂。
- 画笔和画板上接触方式以及湿度的些微不同会带来怎样微妙的差别，艺术家无从知晓。他的预见能力可能在精妙和平庸之间摇摆不定。最终他会越来越倾向于简明直白地表达自己的想法，因为没有太多的机会让他们试错。
尽管看起来挺荒谬的，但类似的情形在大多数的软件团队中时不时地发生着，也包括很多特定领域的设计团队。
作为一个交互设计师，我做的事不仅仅是设计软件的样子，我更多地是保证软件如何表现。触摸的压力、速度和加速度会让我的UI有不同的反应。它会让人觉得自然还是感到困惑？应该有多大程度的反馈？我可以多快地重复操作？除非我在一个功能原型上自己动手忙活，否则我压根没办法搞定上边的一连串问题。如果我就是等着别人帮我整，那就会严重拖慢进度，我也没有什么可以调整的空间。
此外，我还希望自己的设计能达到像素完美。就像在PS中微调对象，我希望能实时地看到改变后的呈现效果，因此我有时会一个小时内试验上百个版本效果。我不知道别人是怎么做的，但我会各种可能性中尝试一堆的的垃圾效果。这甚至让很多开发人员都无法理解。
不过，让题主失望的是，我敲出来的代码跟开发者们写的代码有很大差别。我的代码不关心兼容性、（某种程度上的）呈现效果以及可扩展性和保真度。然而，只有我知道我的设计中哪部分好还是不好。我可以代码中发现问题并沉浸其中好几个小时。我还会顺手学习那些帮助我理解的工具。我现在已经在在工作中频繁地使用Flash, Processing, HTML/JavaScript, WPF/C#了。我选择的工具往往跟产品最终的运行平台没什么必然关联，但他们对于展现我的想法相当有帮助。
功能原型使我做出更好的设计，也使我更有效地和工程师团队进行沟通以及更好地进行可行性测试。毫无疑问，得益于可以快速地建模、测试以及调整设计方案，我可以更好地优化它们。现在原型设计已经成为我设计流程中的重要部分，我已经难以想象只用故事板做设计会是怎样的一种体验。
——为什么大多数设计师不敲代码
这得先从劳动分工说起。
在进入软件工程领域之前，我在建筑学校读了6年。精通设计简直就是个神话。尽管不少老师宣称设计可以按部就班地实现，但在大家的理解里，设计更多地还是靠天分和灵感。设计师们从来不愿干别人已经干过的事。我花了好几年的时间批判和研究哲学而不是老老实实搬砖。这种教育在想法创造者和执行者之间画了一条清晰的分界线，分界线另一面的世界神秘而又危险。
我遇到过很多持不同准则的设计师和工程师，他们一旦察觉到有人越界，就会强硬地保护属于他们自己的领地。他们声称没有接受过完整训练的人不可能全面地理解他们的特权领域，因此那些越界者活该被无视。同样是这批家伙，他们不愿意学习新东西，也对那些不符合他们心中准则的东西嗤之以鼻。那样的态度，吓退了一些对编程有好奇心的设计师，因为他们听到了诸如“你干嘛不把时间用在更有生产力的事情上”“要想学出点门道得花上好几年时间”“要想学编程要先学编译原理”之类的评论……有朋友称之为“不安全感”。
其次，现在很多科技公司的运行模式也不鼓励在工作上越位。令人感到讽刺的是，我知道有不少相当有创造力的会编程的设计师找不到工作。一个技术大牛级的设计师朋友来自一个相当之名的设计机构，在多个平台上写过应用，项目能力非常突出，但在面试几个知名的科技公司时都失败了，原因竟然是那些公司的职位都跟她想做的事不匹配。因为那些团队不知道该将她安插在产品链的什么位置上，他们甚至问她问题时都问不到点子上。
在我的实际工作中，在我写任何产品原型之前，我总是向产品经理保证我不是要提交代码，也不是要指挥他们如何搞定工作。同时我还会向那些不敲代码的设计师同事询问每一个步骤，以免让他们觉得自己被挟制。在向设计步骤提供附加值和冒犯同事之间，有一条微妙的界限。
在一个已成型的系统中中改变设计实现方法并非那么容易，但是变化已经正在进行。刚从学校出来的年轻设计师们会写JavaScript, Processing, open Frameworks等等。这是“我会做任何事情为设计实现铺路”精神的起点。随着大众化编程工具的流行，我期待这个产业中会有越来越多跨界和更深的碰撞。
当更多的想法被实现，这个世界会变成更美好的人间。
附原文（来自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
