Should Designers Code
It’s a recurring question: Should designers code?
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”?
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:
Figure: Design and technical actualities and potentialities.
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.
I’m Jens, and I’m an engineering lead—currently manager for Developer Experience at LivePerson—and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
Have a look at the most popular posts, possibly including:
- Highlights from “Flatland” (Edwin Abbott Abbott)
- On Visions for Performance, or: Performance Optimization Is a Process
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.