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 coding is 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 offers him. 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.
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 be rationalized, 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 instead 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, therefore 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 a valuable add-on to the design process and offending coworkers.