Should Designers Code

Published on November 23, 2018 (↻ June 14, 2024), filed under Development and Design (RSS feed for all categories).

It’s a recurring question: Should designers code?

As I have views on, well, much, I want to give my own answer right here: No.

Yet before we look into the “why,” what are we actually talking about—that designers should be required, that they have to code? That they be able to code? That they be allowed to code? (And should they code, or rather develop?) My reading is that in most cases, people wondering about whether designers should code mean whether designers should be able to develop. So when this question is brought up, let’s assume what’s really meant is some ability to do software and web development.

So why would I respond, “no”?

Two reasons:

One, developing is simply not part of designers’ work, not if one applies the view that in order to design, one doesn’t also have to implement what one designs. This is similar to how we don’t expect developers to design (it’s rarely part of our education and training), or how we don’t expect marketers to also create products, or car salesmen to build automobiles, or farmers to come up with recipes, and we’re probably talking about the definitions of our professions and separation of concerns here. That it’s possibly useful to do such related work, does not make it compulsory.

Two, and as I hope to show much more importantly, asking designers to code seems to limit them, and limit them in a dangerous fashion: How can a designer be truly creative if everything needs to happen within the bounds of technical feasability—bounds that are even narrower when we consider that even developers aren’t clear about what’s actually possible to build, and how to do so?

Perhaps a spontaneous graphic can illustrate the problem:

In other words, what we can with our own knowledge and research abilities develop (individual technical actuality) is in almost all cases less than what one could practically do (overall technical potentiality); and that, then, is also less than what one could design (overall design potentiality). By requiring designers to code we don’t only end up limiting them to those technical potentialities—we effectively limit them even further, to technical actualities: their own, and probably at first very limited technical skillset.

Although the basic idea, that designers who code would understand developers better and with that make the whole development process faster, is a nice and certainly tempting one, it’s easily just one more example of focus on the developer, improving the developer experience. Not focus on the user, not focus on the design(er), focus on the developer—indeed, that’s also where the question comes up most frequently.

What I instead like, now, is to give designers all freedom in the world to design what they believe is most appropriate in the work in question. That’s what they’re specialized in, and why would anyone want to limit that. Developers may or may not then need to stretch to build whatever design they end up being asked to implement—and this stretching and any resulting friction, the friction that the “designers should code” side likes to reduce, is something I personally deem useful, and am indeed not worried about: Design and code will and must then all converge in a useful way, which is the task of communication as well as other parties involved in the process.

Although an understanding of adjacent fields is always useful, designers “should,” in the normative, imperative sense of the word, not be able to develop. May—but not should.

Thanks to two sum.cumo colleagues for contributing valuable last minute input in a related conversation.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)