Should Designers learn code?

April 27th, 2015

I wrote this while at Myplanet. They're a great product design shop, check 'em out!

I hate the word should. Designers should do whatever the fuck they want. Learn code, don't learn code, do what you want. However, saying, "Designers should learn to code," a topic that is often seen as difficult, is a great way to scare Designers away from ever touching code, and that would be a real shame. A Designer can't just jump in and start "designing in the browser," nor should they be expected to. The idea that a Designer can go from a sketch to HTML & CSS in the browser to create their intended design is utterly flawed and totally out of context.

Resetting expectations

The debate as to whether Designers should or shouldn’t code has been going on for a long time now, at least as early as 2008. Listening to some people, you’d be forgiven for thinking that, "Designers should learn to code", means you’ll stop using Photoshop altogether, create all of your designs from scratch using HTML & CSS and from this point on, be deemed a programmer – as if that were a bad thing. It does not mean any of this stuff. Photoshop is not dead, nor should it die. You don’t need to throw away everything you’ve learned about Photoshop or other tools you’ve used and go all-in on HTML & CSS.

If you’re like a lot of Designers, you start your design by loosely creating parts of it and then arrange them into a layout that works best, further refining over and over until you have something that works the way you want. If you tried that with HTML & CSS, you would want to kill yourself within 10 minutes. You have to be amazing and have equally amazing tools to pull that off. That kind of work is much better suited to a tool like Photoshop. Just not for more than the "Minimum Effective Dose"[1] of a few screens and some isolated UI components. Beyond that, you are creating waste that compounds as you produce more of them (more on that, coming up).

Designing with HTML & CSS is hard. While it is possible to be good at both, it’s really hard to do both at the same time. As Josh Seiden puts it in "'Designers shouldn’t code' is the wrong answer to the right question":

If you are paying attention to how a software system will be built, you will be influenced by that need; if you don’t do something to counter that influence, you will end up with software designed around what Alan Cooper calls the "implementation model." Cooper argues that Designers who are doing a good job are making software that is designed around a user’s "mental model."

It requires stepping back from what you are doing on a regular basis and getting feedback from your peers. I believe this is where arguments against designing with HTML & CSS, or lack of belief that one can be good at both, stems from. It requires the discipline and skill of not getting caught up in the tools.

The value of learning to code, or any other new tool, mostly depends on what kind of design you are doing.

What kind of Designer are you?

I have noticed a pattern amongst the people voicing their opinions over the years, which is that there tend to be two camps where the opinions are coming from — Production Designers and Non-production Designers.

For the purposes of this article:

Production Designers are those responsible for creating artifacts, whether that be the end product itself or something that looks like it (i.e. mockups or prototypes), using digital tools. Generally speaking, the more detail your tool of choice allows you to create, the closer you are to doing production design work. Non-production Designers are those responsible for directing or overseeing the production (i.e. product strategy).

The production camp is all about efficiency, the details, speed, process, and tactics. They like their tools and are sometimes "geekier" or "tech-focused" in nature. These types have been advocating for Designers to learn code.

The non-production camp is more focused on the strategic and high-level, or "big picture", aspects of design. They are advocating for Designers not to waste their time learning code and instead focus their efforts on non-production work – aiming for higher-level positions like VP of UX, for example. That's a valid opinion, although the same should also be said for learning Photoshop, but it never seems to be.

Both camps have valid points, but the choice isn’t really, "learn code" or "don’t learn code," the distinction that needs to be made is that it’s more about a choice between whether or not you want to do production or non-production design work.

If you choose to do non-production design work, then learning HTML & CSS really is a waste of time, as is learning Photoshop if you don’t already know it. If you choose or have already chosen, to do production design work, then the value of learning any new tool whether that be Sketch or HTML & CSS depends on a lot of factors. The type of projects you’re working on, the people you work with, or the type and size of organisation you work for, and probably most importantly, what stage of your career you're at.

Whether it’s HTML & CSS or Photoshop, both are just tools used by people doing production design work to achieve the outcome that is unique to their situation. That being said, when designing for the web, there are enormous benefits to using HTML & CSS as your design tool that blow Photoshop out of the water. Particularly for Interaction Designers.

Manage complexity with flexibility

Consider this: there were around 12,000 distinct Android devices on the market in 2013 and even Apple’s lineup consists of 18 different screens. Now, go and start a new "Web" document in Photoshop:

![Photoshop’s idea of the web](../../images/articles/should-designers-code/photoshop-new-doc.png)

Yeh, exactly. How do you design for something that is not constant and always variable?. You can’t document that in any sane way. The alternative is to prescribe the "Minimum Effective Dose" of a few key screens in Photoshop then move on to HTML & CSS.

Designing for the multi-screen world with HTML & CSS is faster than Photoshop by order of magnitude. Have you ever had a client ask you to increase the font size used in over 60 Photoshop comps from 10px to 11px? I have. You could charge your client for that, but I prefer to create value for them in the form of something they can use. That change would take seconds, with CSS, not days.

Brad Haynes, in, "Designing Products That Scale" puts it well:

A few years ago at Salesforce, that mostly meant hours upon hours of creating static redline specs. I didn’t go to school for this stuff but burning the midnight oil to label CSS attributes across hundreds of screens seemed really, really broken.

Each time a minor change was made to a component in the system, you threw back a shot of whiskey, cursed your existence on the planet, and started the process of combing through every sheet to update outdated elements. Then you’d recreate the PDF and tell everyone that the new one labeled final-final-v2.pdf is the version that they should start using.

I believe that the strongest case for using HTML & CSS over Photoshop is for a design system – things like pattern libraries and style guides. Creating a design system is impossible using PhotoShop unless you have unlimited budget and time. Even then the result will always be inferior to one built with HTML & CSS due to the latter's ability to globally change parts of the system in seconds, regardless of how big it gets. In HTML & CSS, the effort required to make changes to screens and components is almost entirely disconnected from the amount of them, whereas in Photoshop, it's inherently linked – the more of them there are, the more you are weighed down when you need to make changes.

Presentation vs demonstration

Why describe a product when you can use it.

A Designer's role and the environment within which they work can come in all shapes and sizes. You could be a Junior Designer within a team at a large client-service company, a solo Senior Designer at a small product company or any combination of either extreme and everything in between. Depending on where you sit, you will have varying levels of commitment to existing methods and processes and/or resistance to new ones.

With this in mind, I argue that the reason why HTML & CSS isn’t used by more Designers stems mainly from one place: how the design is being presented to the stakeholder. A design is usually shown to other people to get buy-in or approval, and that happens in the form of a presentation, when it should, in fact, be a demonstration.

How do you get feedback from the ultimate stakeholder – the user? You’re not going to sit them down, do a long explanation of what they’re about to see and then show them your beautiful digital paintings, explaining to them how it will work when it’s built, are you? No. You will tell them to visit a URL so they can use and experience it. There is literally no good reason for why the same shouldn’t happen for your clients.

Dan Mall hit the nail on the head:

Let’s change the phrase "designing in the browser" to "deciding in the browser."

The next time you are presenting to a client, try demonstrating instead. Put those mockups or wireframes on a web page. Better yet, use one of the many tools available or work with a front-end developer to build a prototype. Gasp! Web designs in a web browser? In my experience, clients love it. It’s not as polished in the beginning, but it’s progress and, as a bonus, month-long email threads of attachments and disjointed feedback give way to versioned URLs where they can use the design straight away.

Do what you want

In my experience, you will likely become a better Interaction Designer if you learn the language of the medium you are designing for – HTML & CSS. It certainly won’t have an adverse impact on your work, providing you don't get caught up in the tool.

There’s no need to build an entire design using HTML & CSS on your own. An excellent way to start is by working with a front-end developer to take 2-3 of the screens you created in PhotoShop and creating a pattern library and style guides. You will have a much easier time and a ton of flexibility. You can then work iteratively on the design with them in HTML & CSS moving forward.

You'll then be in a position to minimise the creation of waste and to be able to demonstrate your design sooner in the browser, where it belongs.

Resources

Don’t Fear the Internet is a great starting point for beginners, as is Learn to Code HTML & CSS and The Magic of CSS.

Update: December 6th, 2016

Want to learn how to create your designs using HTML & CSS?

I'm considering putting together a course that would teach Designers how they can bring their designs to life in the browser in a way that is approachable and tailored specifically for Designers. Enter your email address and I'll let you know if there is enough interest.

Other articles on this topic

References

1 "The smallest dose that will produce a desired outcome" ↩