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.