Should designers code?

Should designers know how to code? This is probably one of the most frequently asked questions in the design industry, and one that’s certain to spark a feisty debate among peers or colleagues.

But what if we started with the question, “Should engineers know how to design,” first? Does that reframing change the often discouraging perspective that designers should code — especially for those who are just starting? A broader examination of the topic might lead to more relevant questions like; What (or who) would benefit? What value would that bring to your team? Would you trust an engineer to design a solution from the ground up? What kind of designer would they be? Product designer? UX designer? UI designer? Interaction designer? Graphic designer? Production designer? Interior designer? Would they have the ability to solve a problem from a users perspective rather than a technical one? How deep would their knowledge of design-thinking go? What would be their process? So why are designers often feel pressured into learning how to code? Design is complicated enough.

The same is true for engineering. If the expectation is for designers to know how to code, then what kind of code is the most appropriate? CSS, HTML, Javascript? Objective C, Swift, Java? Python, machine code? What (or who) would benefit? What value would it bring to your team? Would you trust a designer to engineer a solution from the ground up?

I think deep down; the question is intended to be more divisive rather than constructive — It’s a way for designers to ‘level-up’ in the eyes of their peers or employers, but offers very little in the form of practical or tangible skills that can be applied in a real-world situation.

So, why should a designer code?

Speaking from experience, I can tell you categorically that knowing how to code doesn’t make a difference in the long-run. Sure, there are benefits to understanding a little bit about coding (designing within constraints, learning the jargon, appreciating how things are built), beyond that I would argue that being able to code offers diminishing returns for designers. I would even go as far to say that designers who can code demonstrate a lower-level of design aptitude, ranging from an inability to work in a cross-functional team (because they prefer doing everything themselves), a lack of discipline when it comes to design-thinking, lateral thinking, and conceptual thinking (often settling on the first idea that comes to mind), and will almost always underestimate the value of visual design — a skill that requires finesse, sensibility, and restraint when executing at a high-level.

Let’s take a moment to break down the pro’s and con’s:

  • Does it make you a better designer? Maybe (depending on how you define ‘better’). It certainly doesn’t hurt to know how things are built, and it’ll possibly give you the skills to build things yourself.
  • Does knowing how to code make it easier for you to work with engineers? Maybe (depending on what code you learn).
  • Does learning how to code take time that could be spent improving your design skills? Absolutely.
  • Is CSS and HTML classified as code? Most engineers would say no, it’s styling.

So to my mind, the question isn’t about whether a designer should know how to code, but rather, how well a designer can understand and work within technical constraints? How well can they collaborate with engineers? Some of the best designers I’ve worked with have no idea how to code, and yet they produce the most inspiring ideas and ship the best features because they have great relationships with the engineers they work side-by-side with. They place equal value on their collaborative process as they do their output.

Knowing how to work with engineers as opposed to knowing how to code is a much more valuable skill-set, and one that is far more transferable.

By all means, poke around

Designers are curious by nature, and given the opportunity would happily jump into a code repo and poke around. I remember when I first started as a designer, I would download flash files (.Fla’s) to inspect the ActionScript inside. I’d spend hours trying to reproduce the effects and interactions. I taught myself how to author CD ROMs using LINGO. I learned the basics of HTML by writing tables in a notepad file. I discovered CSS, SASS & LESS. I designed and built simple websites and portfolios from scratch using JS frameworks. I also took a leap of faith and embedded myself in an Agile software team where I learned SCRUM, project prioritization, systems-design, quality assurance (QA), and how to work incrementally in sprints.

Fast forward a few years, and I still find myself being just as curious about emerging technologies as I was when I started. But I’ve given up on ‘trying’ to code, instead, I focus more on relationships with engineers and the processes we design for efficient, productive collaboration. My design skills have matured over time not because I know (kind-of) how to code, but because I stopped trying to do everything myself and focused my energy solely on the role and responsibilities of a designer in the context of a team environment.

Focus on design instead

One thing to keep in mind when you’re asked “should designers know how to code?” or, if you’ve been asked to improve your skills by learning to code (from an employer or manager for example), is that first-and-foremost you’re a designer. And being a designer requires an array of dynamic-skills that are in constant flux — especially with the rise of design-thinking at an organizational level. Your responsibilities as a designer are continually changing and are being challenged depending on the problem you’re solving. The opportunities within these problems require a certain level of foresight to spot and skill to execute successfully. The constraints you embrace and the solutions you propose expand paradoxically — The more complex something is, the more simple it should be. Ask yourself if learning how to code would really benefit you as a designer, or are there ten other things you should focus on instead.

My recommendation would be to channel your curiosity into other areas of your discipline. Understand what design-thinking can do for your process as well as your team. Refine your craft with design-principles and understand the power of visual communication. Expand your empathy to help solve more complex problems. And collaborate as a partner — work together, break things, and learn.