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.

(I’m currently writing a chapter on recruiting and hiring designers. The following passage is about the debrief after The Day of Interviews, and how to proceed if the the interview panel is split. Essentially, make sure that it’s not just because the candidate is somehow different.) 

The challenge is when a candidate splits the panel, where some are strongly positive, and others are inclined not to hire. Navigating this proves to be among the most heightened and sensitive tasks for a design leader, because there is nothing more damning than a mis-hire, especially where there’s evidence that not everyone was on board.

In most situations where there’s a split, the easiest decision is the same as the right decision–do not hire. Given how costly it is to make a hiring mistake, this is where better-safe-than-sorry is an appropriate strategy. BUT. It is not a universal, and how this is handled is one of those areas that distinguishes design leaders from design managers. If a design leader deeply believes in the potential of a candidate, and can identify flaws in the rationale of those who object, the design leader should make the case for why an offer ought to be extended to the candidate.

There are reasons for rejection that design leaders need to be wary of, and call out if they are the only impediment to hiring.

Unfamiliar background or approach. Designers, particularly those with less experience, can be quite orthodox in how they evaluate other designers. They may be suspicious of any designer who doesn’t share their background or approach. An atypical background (maybe they didn’t study design in school), or unfamiliar approach (perhaps they don’t use typical design tools, or they’re unfamiliar with industry standard methods), can make panel members uneasy, because it’s not how they do it, and they don’t understand how other ways can be successful. The design leader’s role is to remind the panel of what is most important – results. If an unorthodox approach leads to great design work, the onus is on the team to figure out how they might be able to incorporate such different ways into their team. In fact, a willingness to consider people with atypical backgrounds provides two benefits: there will likely be less competition for that person (because other companies will also be hesitant with the unfamiliar); and the incorporation of new ways of working will increase the team’s diversity of perspective, and enable them to do better work.

Awkward communicators. If the interview process has one crucial drawback, it would be its reliance on conversations as the primary medium of understanding. The portfolio review mitigates this somewhat, but one of the things any candidate is being tested on when talking to people over the course of a day is how well they communicate. Many talented designers are not good oral communicators, and many are quite introverted. It might even be part of the reason they got into design–they may be more comfortable with pictures than words. People who are awkward communicators (and good designers) often process the world differently than others, and that difference can actually make for a stronger team by bringing in uncommon ways of working and thinking.

Candidate is a little weird. Maybe they talk fast or loud. Maybe they have some uncommon obsessions. Maybe they demonstrate unbridled enthusiasm or a lack of social graces. Whatever it is, you will interview candidates that are a little weird. Don’t let that weirdness be a turn-off. In fact, lean in to your team’s weirdness. If a design team can’t bring weirdness into a company, who can? If people on the interview panel grow wary when candidates’ let their freak flags fly, reorient their thinking to the quality of that candidate’s work, and whether they think the candidate will be truly disruptive (and not just a little strange).

[I just wrote the following passage for my book on building in-house design teams. It needs work, but I still felt it was worth sharing.]

Realizing the benefit of diverse perspectives requires a supportive environment where people are encouraged and comfortable sharing their work, spurring collaboration that makes the final output better than what anyone would deliver on their own.

Every member of the team must demonstrate respect to every other member, or the openness required for successful collaboration will not emerge. Dismissiveness, insults, cattiness, and behind-the-back gossip lead to people feeling shamed and shutting down, and cannot be tolerated.

Earning one another’s respect is necessary in order for the team to “get real”, because frank and candid critique and feedback are essential for upholding the high quality standards. Greatness comes from the tension and collision of different perspectives, addressed openly and honestly. Design teams that favor politeness over respectful candor will rarely produce great work.

Organizational hierarchy can stifle the free flow of ideas within a design organization – when senior people speak, it often stops the conversation. It’s now become cliche, but it’s worth repeating – great ideas can come from anywhere. Great design leaders encourage everyone to speak up, and, for themselves, wait to speak last. These leaders must also place their work alongside others, and accept others’ critique with grace and humility.

The collaborative environment referred to so far has been figurative, but it also should be made literal. Great design work takes space – places to collaborate, whiteboards for sketching and ideation, walls to show work. And those spaces should be permanent, places where the team works and sees their work all around them. Not only does this encourage continual engagement from the team itself, such spaces enable people outside the team to quickly connect with the work. It literally demonstrates openness and transparency. And instead of having occasional big share-outs (that require preparation that takes time away from productivity), these spaces support frequent lightweight check-ins that ensure the work is on track, because if it’s beginning to veer off-course, it is quickly corrected.