Put the “designers should code” debate to rest

Note (September 14, 2015): this post has also been translated into Chinese.

My acting coach in college used to say something to the effect of, “Be. Don’t show.” It was frustrating. He wanted us not to do the things that symbolized what was supposed to be happening in the scene; he wanted us to live the scene. A good example is acting like a drunk person. We see drunk people, and a natural tendency when doing a scene as a drunk person is to act the way you’ve seen drunk people act. But in many cases, that comes across as fake and obvious. Because people who are drunk often try to act sober.

I worked in an art gallery when I was in college, and once a year we would put on an exhibition of children’s art. One thing you notice when hanging hundreds of paintings and drawing by kids, especially the younger ones, is that many tend to draw symbols of what they see. The don’t draw the sun, they draw a circle with lines around it. Or squiggles. Mountains are triangles. Basic forms are used as symbolic depictions of objects.

This often continues into adulthood, unless one learns to draw at least at a basic level. And while perhaps repeated once too often, it is true to an extent that learning to draw realistically is learning to see. Learning to look carefully at what’s really there. What’s really happening. Circles on a wine glass become ellipses. The hard lines of the sun become gradations of color. Are you unable to draw, and don’t think you can? Grab an image, turn it upside-down, and draw what you see exactly. Don’t symbolize the image by thinking about the subject of it. Draw what’s actually there. For those inexperienced with drawing, it will be one of the best drawings you’ve ever made up to that point.

As designers for the web, depending on what type of designer you are, you are researching, structuring, adapting, testing, laying out, wireframing, setting type for, composing, and [fill in the blank]ing something that people will read, interact with, love, hate, tell others about, and perhaps take with them everywhere they go. And the medium is right in front of you, every day, so you as a designer for this medium have the opportunity to use it to prototype what you’re designing.

I’ve gotten my share of criticism for being one of those people to publicly state that it might be a good idea for web designers to learn some code. It took me several years to come to that opinion and it hasn’t changed much, but it wasn’t the coding that was important. It was the movement away from symbolic representations of that which we were designing. It was about not using flat images as a poor proxy for something that’s different for different people on different devices in different browsers. When I wrote Responsive Design Workflow, which describes a content and prototype-based approach to responsive design, people either loved it or hated it. Those who hated it did so because it was outside of their comfort zones, and because it involved learning basic HTML and CSS and getting into the browser as quickly as possible.

You can’t give me a wireframe, detailed as it may be, and tell me that you’ve designed the interaction of a particular product. You’ve just drawn a circle with squiggly lines around it, and you hope that reality will match. Good luck with that. Visual design influences interaction. Typography influences interaction. Content influences interaction. You either work together, as a team, or your bubble will burst at some point. You want to influence interaction? Get the thing into a browser and interact with it. Sculpt it. Shape it. Tweak it. Be, don’t show.

That’s what it’s about. Not about coding for the sake of coding. During the period of time leading up to my book’s publication, a lot of the tools we have available today to get into the browser quickly didn’t exist. I advocated code because I literally could not find tools that would get me to useful and realistic prototypes as quickly as code would. I had to use JavaScript and the command line to automate screenshots. We have tools that do that today. They do the same thing I did in the past, but they do it behind the scenes. There are now tools all over the place that can help get you get your product into the browser quickly. Even two years ago, we didn’t have many of those tools. That’s why many of us advocated learning to code.

Every so often there are articles and tweets about whether designers should learn to code. I think very little of it is constructive anymore; arguments swirl down into sewers of discussions on semantics, like whether coding is a profession or a trade, or whether HTML and CSS can actually be considered coding. It doesn’t matter.

Must designers learn to code? No. Would it benefit them in some ways? Yes. Is the code needed for much of prototyping more difficult than learning something like Photoshop? No. Can it become more difficult than Photoshop if I decide to dive deep? Yes. Are there ways to prototype effectively without learning to code? There are now. Can you still keep using Photoshop (or Sketch, or whatever) even if you learn some code? Absolutely.

It’s not about the code. It’s not even about the tools. Prototyping is about asking reality for feedback.

13 thoughts on “Put the “designers should code” debate to rest

  1. I love that anecdote from your acting coach and how it reflects into design work. “Be, don’t show” is exactly what we should all be doing. Just the other day I told my students (in a basic HTML and CSS class), that HTML and CSS are not just languages, they are *design tools*. That they should think of simple markup and styling capabilities as part of their design tool kit. Markup doesn’t have to reach production code level in the first iterations – and that’s where I think a lot of designers go wrong. They think they need to do production code – but in reality, all they need is low fidelity code to design in the browser.

  2. @Trine: Well said. In my workshops I always say that code is an *addition* to the tools you already have. You’re not losing anything, only gaining. Gaining a better understanding of web technology, but also gaining a new skill that’s super useful and dare I say *fun*. And you’re absolutely right: designers don’t need to write production-ready code.

  3. That’s absolutely right. Many designers nowadays rely on tools instead of coding. Sharing work is just a show-off rather than its practical use.

  4. But the web is successful because of symbols. The share icon doesn’t accurately show sharing, it’s a symbol that is quickly identifiable and universal. The same with the phone icon on mobiles.

  5. Funnily enough I started my career by designing in the browser. It was laborious and slow to make radical changes.

    A more experienced designer showed me how he did layouts in Photoshop and then handed it over to someone to code up afterwards.

    I’ve been doing it that way ever since and don’t think I would ever change. I guess I do have an advantage in that I know how to code as well as design, and unlike some I can do both well.

  6. Great Read!
    As an Fine Artist and Programmer, I can no longer imagine designing a site without using some coding. To be able to envision beyond design is priceless. The ability to see work done in Photoshop and other design tools come alive with a little javascript knowledge helps to complete the vision you are trying to achieve before the pass off.

    I’m so happy that you shared this with the public. My grandson, an graphic artist into web design just doesn’t it. I am forwarding this to him, perhaps he will hear it from you.

Comments are closed.