“Should Designers Code?” fetishizes tech over other crucial design skills

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.

Hiring: reject a candidate for the right reasons, not just because they’re different

(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).

Thoughts on fostering a collaborative work environment

[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.

My Design Organization Design Talk, Slides Plus Audio

At IA Summit 2015, I spoke about “Shaping Organizations To Deliver Great User Experiences.” Here are the slides:

Now, here is the audio of my talk:

Press play on the audio file, and then guess when it’s time to advance the slides. That way, you can RELIVE THE MAGIC.

If you go to The IA Summit page for my talk you can download the audio, read a complete transcription (!), all captured thanks to Jared Spool and UIE.

Hot Take Part 2: McKinsey jealous of Frog?

Another quick thought about McKinsey’s acquisition of Lunar. I am guessing that McKinsey sees all the press about Disney’s My Magic +, and how they spent a billion dollars on it (so far), and how Frog was deeply involved from beginning to end, and thinks, “Wow, we’re leaving a lot of money on the table by not being able to see these things through” and saw Lunar as a piece that allows them to win business that they would otherwise not even be considered for.

Hot take: The Bifurcation of Design Services (McKinsey acquires Lunar)

[This is a ‘hot take’ hastily scribed while trying to get my household moving in the morning. Forgive typos and other lapses]

Management consulting firm McKinsey has just acquired Lunar Design, an industrial design firm that had been attempting to broaden its capabilities with product strategy and interaction design.

After my post on “San Francisco Design Agencies Feeling The Squeeze,” I was lumped in with the “design consulting firms are dead” bunch, because people are poor at reading comprehension. Design consulting isn’t dead, but it’s definitely morphing, and doing so in an interesting bifurcated way.

At one end you have the big management consulting firms either establishing or acquiring design practices (McKinsey had been growing one organically in-house before the Lunar acquisition, Accenture acquired Fjord, Deloitte has Deloitte Digital). These firms had seen companies like IDEO and Frog get big billings for projects of the sort that used to only go to them. They realized they needed a design competency to stay relevant in the 21st century. And now these firms are deploying design practices at the highest levels of global corporations as a tool for creating strategy. This is actually a really big deal for design as an industry and a practice, and one that hasn’t yet been at all sufficiently appreciated.

At the other end you have design firms who are positioning themselves as partners in the development and launch efforts. This is design for execution, often embedding with product teams, and focused on the detailed work of interaction, interface, and visual design and front-end development. This is typically a ‘gap-filling’ role — augmenting a client’s lack designers in-house.

And the middle? Historically, that was Adaptive Path’s sweet spot. There were multiple times we came in after someone like McKinsey had supplied a client with a Big Idea of where to go, and we would use our design practices to put shape to that existing strategy and suggest offerings and experiences they could deliver. Then we’d leave as the client would take our suggestions and implement them.

As companies have been staffing in-house design teams, that is where this middle work has moved. It hasn’t been worth hiring in-house designers to be the strategic dynamos a la McKinsey, and you can never hire enough designers for all the execution to be done. So, there seems to be plenty of work for design consultants in those regards. The middle bits? Not so much.

There is no such thing as UX Design

Provocative statement: The entire “field” of user experience emerged for one reason — to accommodate, and overcome, poor (or non-existent) product management practices.

Product management’s responsibility is to identify opportunities in the market, specify new offerings, and see these through development and distribution. Originally, product management was seen as a business function, and MBA’s were placed in that role. As such, it was about sweating the market, assessing opportunities, crafting business plans, establishing requirements, and the like.

In Silicon Valley, most notably at Google (where Larry felt it inappropriate for non-engineers to tell engineers what to do), a more technically oriented product manager emerged, essentially a flavor of engineering management but with some business savvy.

The rise of software, and particularly networked software, lead to products of immense complexity. It was in these environments that some designers realized that a significant perspective was being neglected–drawing from customer empathy. Designers, who are typically the most empathetic folks in a product organization, knew that many of the requirements they’d been given were foolhardy–that no one would use the thing. So, they pushed back, incorporating first usability and then up-front user research methods, and developing systems-level design practices around architecture diagrams, interaction flows, wireframes, and the like.

This work was called “user experience,” a term originally coined by Donald Norman to acknowledge that the totality of a user’s experience should be intentionally addressed.

The problem is, Don should have never had to say something so obvious. It was due to the shortcomings of the MBA and computer science mindset that product management had not yet considered this.

So, the field of user experience emerges, typically within design teams, in order to fill this gap. It makes for an awkward organizational fit, because, really, product managers should be the ones driving these efforts, as they are best suited to weigh these inputs alongside the business and technical concerns.

The dissolution of “UX Design”

User experience is an emergent property of an entire organization, not just one group. When user experience is so closely associated with design, it allows non-designers to feel like user experience isn’t their responsibility. This association also sets up designers to fail, because they are given a charter they cannot deliver on.

There is another issue around the job title, and career path, of “UX Design.” The use of the term is so broad as to be meaningless. Instead, let’s unbundle the components of what people think of as UX Design and place them where they make more sense.

Much (most?) of what people mean when they say UX Design is around the structural and interface designs of complex, software-enabled systems. And we already have a name for that: interaction design.

There are strategic aspects of UX Design — user research-informed product strategy, using design and storytelling to help figure out what we should do. We also have a name for this: product management. As in, product managers need to consider this empathy-driven understanding with equal weight to the business and technical concerns.

Do not interpret this as me suggesting designers should not be included in product management — far from it. Design is a key input, and oftentimes, driver of product management. In fact, I am seeing more and more senior “UX Designers” reframing themselves as product managers, because it better explains what they’re actually doing. This is progress.

“User experience design” served a purpose when it was necessary to shine a light on a glaring gap in the ways we were working. That gap has largely been addressed, and I see no reason not to retire that term.

A key challenge in delivering great user experiences

In my last post, I suggested that ,ost of us work in markets where products and services have matured out of “technology” and “features” and into “experience”, and so design should be driving the conversation, because delivering on experience is what design does best. Instead, we find design hamstrung into organization models that are still “features”-driven.

The more I’ve thought about it, the more I’ve realized that there is a potentially intractable issue “experience design” faces. When you study how people behave, and propose design interventions to support better experiences, you’re engaging in a holistic and continuous activity. Human experience is continuous. It flows seamlessly.

However, in order to deliver products and services to people, we must break up this continuous experience into discrete pieces that are achievable by teams. So, to use the example from the last post, the Shopping Experience becomes a series of features (Search, Browse, Product Page, Checkout, Gifting, etc.) Working in producible chunks inevitably means losing the holism that defines human experience, and the thing I struggle with is figuring out how to manage this liminal shift so that what we deliver doesn’t become defined by the features (and the teams dedicated to the features), and it maintains its more subtle, nuanced, integrated qualities.

How could we/should we reorganize development teams and processes to achieve this experiential holism?

STEM into STEAM into STREAM

STEM is the acronym for Science, Technology, Engineering, and Mathematics, and is used when talking about what we need Our Young People to study in order for the United States to Stay Competitive in the world.

John Maeda, formerly president of RISD and now a design partner at KPCB, popularized the idea of turning STEM into STEAM — adding Arts (and design), because it’s clear that inventions that turn into innovations are often not just driven by the hard sciences.

However, this strikes me as insufficient. Because in my experience, the greatest source of insights for inspiring meaningful product and service creation comes not from the hard sciences, but from the social sciences. To turn STEM into STEAM into STREAM, where R stands for Research on people, their behaviors and contexts.