I’m writing a book on building effective in-house design teams. I recently completed a draft of the chapter on professional development for designers. The following is inspired by that.
Design is so much more than what most people think it is. Even than what most designers think it is. As someone who has worked in design for 20 years, perhaps the most frustrating industry conversation revolves around “should designers code?”The idea that a designer who codes is a “full-stack designer” demonstrates the shallowness of most thinking about design as a practice, and a skill set. It speaks to a technical fetish that undercuts the full potential of design.
There is opportunityÂ for design to be woven through every aspect of a customer’s interaction with an organization. In order to do that, a variety of skills need to be brought to bear, many of which are typically neglected in discussions about what designers should learn to do:
- User research. Conducting user research sessions (in-home, in-office, user testing, diary studies), and deriving meaningful insights through analysis.
- Information architecture. Structuring content, developing taxonomies, crafting navigation, and other activities that make information accessible, usable, and understandable. Â
- Interaction design. The structural design of a software interface, supporting a userâ€™s flow through a system, and ability to successfully interact.
- Visual design. Color, composition, typography, visual hierarchy, and brand expression that present the product or service in a way that is not only clear and approachable, but appropriately exhibits personality.
- Writing. Clear written communication that, like good design, guides the user through an experience. Much of the time, written content is the experience, and far more valuable than the design dress around it.
- Service design. Systems-level understanding of all the piece parts (technical systems, front-line employees, touchpoints, etc.) that go into delivering a service, coordinated to support customer journeys.
- Prototyping. Quickly simulating proposed designs in order to better judge their user experience. Could be deeply technical (writing code) or a more patchwork use of tools like AfterEffects, Keynote, and Quartz Composer. Â
- Front-end development. Delivery of production-ready front-end code. Valuable in ensuring that designs are implemented as proposed. Â
It’s easy to argue that user research, information architecture,Â and writing are design skills every bit as important as coding. In fact, those practicesÂ better support strategic efforts, and so may have greater impact than the execution orientation of coding.
The range of skills demonstrates the foolishness of the idea of a “full-stack designer.” No one person can practiceÂ all these skills with any real mastery. In my experience, folksÂ become expert at one, maybe two, strong in a couple others, and competent in a couple more (and this is after 10-15 years of work).
Given this variety, how a team member grows their skills is variable, depending on the designerâ€™s desires, mindset, and inclination. There’s no set path for designer growth. Some will learn to code. Others will learn to research. Others will map systems (of information, of relationships between people). All are necessary, and no particular pathÂ should be encouraged over others.Â
This range also points out the folly of having a single designer embedded on product teams. As no one designer can deliver across this set of skills, no one designer should be expected to act alone. Designers work best, and deliver best, in teams, where their skills are complementary, allowing the whole to be greater than the sum of the parts.
The variety of skills also changes who is typically thought of as part of “the design team.” Too often we get caught up in roles and titles, when what matters are the skills that are being brought to bear, regardless of who is doing them. Content strategists (who excel at writing, are strong in information architecture and user research, and can do competent interaction design and service design) or UX Researchers (who may excel at user research, be strong in writingÂ and service design, and competent in interaction design and information architecture)Â could (should?) be considered part of the design team.
I guess what frustrates me most about “designers should code” is that it demonstrates how designers can get in their own way.Â Fetishizing code is fetishizingÂ production, at the expense of strategy. It keeps designers in a subservient mode, receiving requirements from others, happy just to execute. There is a broader and deeper opportunity for designers and design practice to drive the definition of those requirements and weave through an entirety of a customer’s experience. Yes, code is part of that, but only one part.
Great argument. An additional point: The folly of the question assumes that the output of design is a digital product. The ability to code is irrelevant for many design outcomes.
It’s a good point, the frustration you share RE: “should designers code”.
To make counterpoint… Learning code isn’t just about execution. As you say, the content is often the experience, but understanding markup is more than just execution. Semantic meaning, responsive design, progressive enhancement… these are important constraints on decisions certain designers make. To be a “more complete” interaction designer, you need to have a strong functional understanding of the technology. Performance, especially. It’s well and good to provide gorgeous feedback animations in After Effects, but it’s largely uninformed guesswork if you don’t understand how it’s implemented or unable to effectively communicate with the “executors” (your team). My point being that these requirements you talk about driving are likely better informed when a designer understands “the code”.
You don’t have to code like a rockstar, but applicable knowledge with HTML, CSS and JS will always (for me) make most of those other skill areas stronger too. Agreed it’s for certain flavours of design, and call it fetishizing or whatever you feel, but ignore the underlying technologies and implementations of web/mobile/touch/app design and you risk an opportunity to cost to your strategy, your team’s efforts and your users.
Well said. As you point out, the “designers should code” mantra is only applicable to UX/UI/Visual designers closest to the point of digital development. Even then, I typically see it framed around two issues:
1. Designers should have empathy for/with developers. If we learn at least the rudiments of coding for a platform we can better design, prep, and spec for hand-off to developers
2. Static screens are gone, UX/UI/IxD is inherently fluid, so static designs are an incompletely considered deliverable.
Both are being addressed by new tools; Sketch (plus Zeplin or Craft) for production-ready designs and specs. Principle, Framer, Origami, et al for prototyping.
Nice write up Peter. While I agree that the idea of designers learning everything about everything is unrealistic, the designers I’ve been talking to tell me their interest in learning to code stems from a desire to better understand the constraints they design for – as you say, code is one piece of the pie. There is no one size fits all.
I think the whole ridiculous topic came about due to a long-simmering fear/shame that digital designers don’t actually make anything real (nearly all our deliverables are short-lived, quickly glanced over). Clients can’t be convinced to get excited about user flows and wireframes, though they do clamor for the pretty comps, but once they’re approved, they just want an actual, working site.
And so code *felt* real — an actual thing that could have outcomes, and effects, as well as a way to stay involved in a project longer.
Insecurity — professional and personal — is the crazed heart beating behind this undying argument. The unfortunate side effect, however, is that it’s bled into actual job descriptions. So, good job, insecure designers: this is what your fear hath wrought.
I’m not discouraging folks from writing code. I’m saying it’s just one of many ways for designers to develop their skills.
The most common criticism of this piece is that designers need to learn the material they work with. I would argue that “information,” “content,” and “people” are material that is as, if not more, important for them to understand.
Thanks for this post Peter. Wherever I see this question coming up, I usually reply “Do designers need to be able do their own user research?” 😉 However, this reminds me of the discussions heard when I was educated in Industrial Design “How can you design a chair if you’re not a carpenter / a vase if you’re not a glassblower / dishes if you’re not a potter / any maschine if you’re not a metalworker, etc.?”. Well, you can and btw most of the big names in Industrial Design don’t have a formal education in these fields. So coming back to the question “does a designer need to code?” here are three things I learned:
– You can become good in something by finding a partner who’s able to compensate your weaknesses and willing to learn from your strengths. So as a Designer you might just want to find a Developer who’s willing to have an open discussion without putting the “making” over the “thinking”.
– You can learn about something just by looking at other people doing it and listening to them. E.g. “Don’t have big images in an app, it will have an impact on the performance.” is a good rule of thumb and I don’t need to be able to write code to understand it.
– If you just know a bit about a skill like coding, it can be as well quite limiting as you might not be good enough to develope the effective “secret paths” or shortcuts that experts know, eventually making you mediocre in both, Design and Coding.
I wrote a post a while ago trying to drive home a similar point, but it also compares it a bit to the “other” designers who are not in the digital world and what’s expected of them. Feel free to have a read here instead of me trying to reiterate the point:
Funny how this topic emerges every few years.
Also, hi 🙂
Lovely version of this argument. Better than I have said it, but I still think a bunch of comments are missing the point.
Any project I work on that is A Web Site or A Mobile App is almost destined to fail. Everything has data storage in the background, posters and brochures for marketing, password reset or sharing emails, and more. Coding, prototyping, or Sketch drawing the Screens Of The One Digital Interface misses the point, intrinsically.
We need to get higher level and design for users, designing systems and products with whatever tools we need. I almost never get even a simple sitemap/task-flow from vendors, unless I make them do it. No one designs data storage, or emails, or the relation between profile and account at all unless I do it. Too few places have even writers, so content is an afterthought. Most “UX Design” I encounter in the wild is UI Design, full stop. And we wonder why experiences are terrible all over despite being pretty.
Coding everything as your design and delivery solution is just the worst of these narrowing your focus tools. I work not just to create specs (for reasons I have said before many times), but I work in PowerPoint presentations and spreadsheets, and meetings and whiteboards. And in code. Yup. I build prototypes and help development do what I asked. But none of these /exclusively/.
Maybe I’ve been missing the point. Maybe the point has narrowed. I’ve always understood “should designers code?” to mean “should designers understand the systems they are working with?”.
Should information architects understand the databases that structure the information they dealing with and how that information is passed through systems?
Should visual designers understand CSS so they can talk about tricky UI problems with front end devs?
Should UX designers understand the various APIs of the systems that enable and limit and consume particular user journeys?
“Fetishizing code is fetishizing production, at the expense of strategy.” In real-world non-greenfield projects, code – from changing established databases to choosing frameworks – is strategic. Things have already been built : your design needs to work with them and understand their limitations. This means understanding code, or at least the principles of the code.
If you want to create a design and the off-shore developers say “no” and you can’t talk about the code then the design is dead in the water.
If you want to create a design and the off-shore developers say “no” and you can talk about the code and ask why and work with them to find a compromise then your design stands a fighting chance.
it’s all about perspective — to me, coding is a necessary evil.. to my coworkers, design is that same evil.. the struggle is real. peterme, when will your book be published, I must read it!
Always good articles and ways of seeing things, Thanks Peter.
Let me start my input like this:
– I have seen way too many designers knowing absolutely nothing about engineering, mechanics or coding (I have in many years worked with mobile phones where UX was implemented in more than just SW, so that is why I call them “engineers” instead of coders). Such design people can be a true pain in the a… for the entire organisation and they tend to give the “design guys” a very bad reputation in the rest of the company. Many of these designers believe they are pure artists – which in my mind does almost never work in a “real” company that also need to sell products.
– I have on the other hand also seen too many “Front end” developers (and for that matter PMs, managers etc) believing that they know much more about a good user experience than the UX team does. Many of these “engineers” end up thinking like this after they have met too many of the first mentioned designer types..
Both types of employees are in my mind destructive and I have seen the results can be that they stop listening or even communicating with each other.
I believe that a good UX’er does NOT need to be able to code, but he/she certainly needs to understand the challenges and limitations of the “engineers” (SW, mechanical etc) and be able to compromise with the “engineers”.
In the same way, the “engineers” need to understand the designers more, and understand the underlying thinking in their design or ideas.
My favourite solution is to work together on an almost daily basis. I have seen too many “designs” being made in what the engineers called the “ivory tower” of the designers, without even consulting the people that should “build it”. For me that is like an architect that designs a skyscraber with no or little understanding or consulting with the people who should eventually make the building possible.
I myself came with an engineering background into the UX field some 23 years ago, long before the term UX was even invented, and one of my key reasons for being successful has been that I could talk both to the “designers” and the “engineers” (and of course the empathy that all UX’er should anyway possess). I have at times seen the fights from the engineers to make all UX’er part of engineering (due to the ivory tower element), and I have also too many times seen the UX/design team fight back to defend their position – none of this ever helped the company…
When working together, the question is how deep do you need to understand each other, and there is no easy answer. As suggested, the “engineers” should often be involved in the design, and likewise, sometimes a UX’er may need to sit together with the implementer when doing (essential) parts of the code.
Best regards, Christian
I started in the world of print graphic design. It was important to grasp HOW a printing press turned your design into a book or brochure, to the level that you would know a design you could execute in Photoshop might not be printable, for a bunch of reasons. Production managers would handle working with the printer to spec a job, figure out cost saving techniques to modify a design, etc.
But no one in those days would have required a designer who could burn plates and run a printing press.
I think the analogy is apt. If a designer really has an inclination to become a front-end developer who is immersed in JS libraries, frameworks, SASS vs LESS, css animations, Gulp, etc etc., more power to her. But to require designers to code to the standards of today’s multi-device world seems like folly to me, and using up head space that might be of more value for solid IA, UX, strategy, etc.
My two cents.