The misguided quest for the UX polymath

Experience design for the Web is all about tradeoffs: you have to balance what you can design (which is limited only by imagination) with what you can build (which is constrained based on existing technologies). This delicate dance between design and technology has existed ever since people started wanting Web pages (and experiences) to go beyond something you could create with a crayon. Branded experiences and useful applications need good interaction and information design, solid visual design, and an implementation that is faithful to both and performs well.

The problem is that now a lot of businesses (startups and otherwise) want to have their cake and eat it too; they want to find that magical "UX polymath" that can, in one brain, balance the force: design and implement, and do both really well. Amidst all of this is an ongoing debate in the UX community about whether this is good, bad or even possible (see one example here).

In my opinion, the search for the UX polymath is a misguided and destructive quest, and it’s time to move past the debate.

Why the quest is a waste of time

UX polymaths exist. I’ve worked with them. Unfortunately, of the hundreds of people with whom I’ve collaborated on 50+ UX projects over the last decade or more, I think I’ve met two or three. Maybe.

You need to go way out on the Gaussian distribution of ability to find people who are good at both design and programming; there are very, very, very few who live in that rarefied air. It would be like looking to hire a sharp high-energy physicist who also happens to be a very good general contractor; there are no doubt a few of them, but you’re probably not going to find them on craigslist.

Over time, this situation only gets worse. Technology expands; new platforms and approaches and channels arise. It’s hard to keep up, which can lead to ever-deepening specialization. Design also evolves; new patterns emerge, approaches to usability are refined, dynamism in interaction increases, and aesthetics change. The days of simple HTML markup and static images are long gone, which means it’s harder and harder to be a UX polymath.

So what about generalists? If we give up on polymaths, do we give up on generalists too?

Specialists vs. Generalists: The false dichotomy

Here’s where the semantic debate arises. What is a generalist, if not a polymath? In my mind, the distinction is two-fold:

  • A generalist has a set of fuzzy skills that a polymath may not
  • A generalist would not necessarily be called an expert in any domain of knowledge or practice, though they could be

On the fuzzy side of things, generalists are great problem-solvers who can build bridges of understanding between specialists where they need to be built. They can deconstruct and synthesize information quickly and easily, and feel comfortable in many types of environments. They bring a broad perspective that may elude the specialist whose domain expertise keeps them focused. And the cherry on top? Superior ability to communicate.

Generalists probably have some domain expertise (maybe even in a few areas). The amount of knowledge they need is just enough to build the aforementioned bridges, to break down problems, to see a different path. Of course, there’s nothing to preclude a specialist from having any of these abilities, and this is where I think the problem arises.

The mental model of "specialist vs. generalist" creates a false dichotomy. It’s possible for a specialist to also be a generalist (or rather a generalist can have a specialization). In this sense, generalist is more a role that many people can play in an organization, whereas specialist is a tangible skill in a specific domain of knowledge.

The UX polymath quest is destructive

The suggestion that designers should code and that coders should design denigrates the specialized skills and abilities of each group. It can create friction within UX teams, where each group (design and technology) feels their skills are being marginalized or devalued. It also makes it harder for these teams to communicate, because it can bring ego into the picture (i.e., "You can’t do what I can do"). Finally, it can create a chasm between the expectations of managers and producers (who want to deliver on time and on budget) and the teams trying to hit those marks (but who can’t because expectations about the breadth of responsibilities for individuals are unrealistic).

Products and services suffer in the quest, too, because the more you expect an individual to do, the lower quality their work will be on average. In other words, one designer-coder with decent skills in each arena will deliver decent quality work, whereas two deep specialists can probably deliver higher quality (provided they can communicate).

The bottom line: Move past the debate and accept the reality

The UX polymath (designer-coder) debate has been going on for a long time, but without a whole lot of consensus. The reality is that specialists will continue to exist, whether they be designers or coders or otherwise, and UX polymaths are few and far between. Generalists play a role almost orthogonal to that of the specialists, but that role might be filled by many people. With this reality in mind, businesses should focus on building UX teams matched to their needs and expectations, and then deliver the best possible work or products. Arguing about whether their designers should be writing code or vice versa is just tilting at windmills.

A few words about terminology

Here are my definitions for the key terms used in this post. Your mileage may vary:

  • Specialist: An expert in a single domain of knowledge and practice (e.g., designer or programmer)
  • Polymath: A specialist with deep skills in multiple domains of knowledge and practice (e.g., design and coding)
  • Generalist: A role that someone plays in an organization, with solid problem-solving ability and cross-functional communication as core skills. Generalists are at least conversant in several domains of knowledge and practice, but not necessarily expert in any one

A few words about history

In the glory days of the early Web, where it was really a Wild West of possibility, scrappy startups came along with people who could wear lots of hats, designing and coding and making it all happen like magic without the need for large teams of deep specialists. Specialists who could dabble in other areas ruled the day because expertise was relatively shallow and ill-defined when it came to web design and web programming. It wasn’t unreasonable to think that a designer could pick up some HTML and implement their designs (though the converse was less common).

As things got more sophisticated (both in terms of design and technology), deeper specialization became necessary; it wasn’t feasible to have a few people who could do everything. There was too much to know, and the benefits of deep specialization were clear. As people dove deeper into their specialities, the need for generalists (problem-solvers who could bridge specialist divides) arose. And so it went through the Halcyon days of the Internet bubble, where agencies grew, teams of specialists and generalists sprawled, budgets skyrocketed, and everybody was happy.

And then the bubble burst.

Suddenly, the number of agencies and businesses that could support big UX teams dwindled to near nothing. People retrenched, lost jobs, changed careers. Smaller teams of specialists became more desirable as agencies tried to stretch as far as they could to keep costs down and still design and deliver great solutions (or at least ones that didn’t suck). As time went on, businesses and agencies recovered from the bubble hangover, and it became possible to hire more, which again meant a broader mix of deep specialists and generalists. Things were grand again!

And so it went for a few years…Then the financial meltdown and recession hit and the pendulum swung back the other way, with contraction and the need for lean teams once again. Cyclic economic behavior (with expansion and contraction) creates fatigue for businesses who want some degree of continuity. It also makes it hard for startups who are trying to manage the risks of growing too fast too soon. Despite these challenges, amazing opportunities abound; the proliferation of mobile devices, cloud services and social platforms is fueling innovation left and right.

So now we find ourselves in a situation where everyone wants to capitalize on this opportunity, delivering jaw-dropping products and services with small UX teams. This fuels the desire for UX polymaths who can design and code with a high degree of proficiency; it means less people doing more, which is good for business.

  • While the quest to *hire* a polymath is like charging at windmills, the quest to *be* a polymath is a noble pursuit. Never stop learning!

    • I don’t disagree that breadth is always valuable from an individual perspective, and that learning is essential. It’s something I strive for every day, because I think it gives a greater degree of empathy, and opens us up to extreme possibilities.