In defense of the UX specialist

Image of Tools

I was recently pilloried on Twitter by a Well-Respected UX Personality for asserting that there is a place on development teams for user experience specialists.

In a particularly ugly bit of this exchange, I was even accused by my adversary of not understanding basic logic — because while I agreed with him that specialists aren’t always the best person to take on a task in their area of specialization (because not all specialists are highly skilled at their specialty), they usually are.

If you tell me that not all dogs have four legs, and I say that dogs usually have four legs, I’m not misunderstanding basic logic — I’m differentiating between the words “all” and “usually”. Not understanding that distinction is a sign of not understanding basic logic.

But back to the matter at hand.

The actual substantive debate with this Well-Respected UX Personality (whom I will simply refer to from here on out as “my opponent”) was about the value —or lack thereof — of user experience design specialists. There are some subtleties to the debate that are specific to UX — but most of what I have to say here applies to any line of work — at least in the realm of software development.

The platonic ideal of a development team is one in which every member is great at everything that could possibly need to be done. On that team, no matter what comes up, there will always be a resource available to handle it.

Not even my opponent believed this to be realistic, but his idea of a realistic compromise was much closer to the platonic ideal than mine was.

Flying, fire-breathing, immortal, solid gold unicorns

This next bit is specifically about User Experience design specialization, but will likely resonate with people in other fields.

My opponent’s strident belief is that user experience design responsibilities should be distributed among all members of a development team. I think this is incredibly unrealistic for reasons his own words should make clear (emphasis mine):

Our research showed there are core skills [in UX]: interaction design, information architecture, user research, visual design, information design, fast iteration management, copywriting, and editing. There are also what we call enterprise skills, some of which are: analytics, development methods, design-to-development documentation, ethnography, social networks, marketing, technology, business knowledge, and domain knowledge. […]

On the best teams, every team member has a solid foundation in all of these skills.

In the tech world, people who are good at design and development are often referred to as “unicorns” — because they’re exceptionally rare, to the point of possibly being mythical. This line of thinking isn’t advocating for “unicorns”, it’s advocating for flying, fire-breathing, immortal, solid gold unicorns.

I absolutely believe that the principles of usability and user-centrism should be understood and shared by all members of a development team — as should other key development principles such as security, performance, accessibility, and maintainability. But there’s a difference between applying principles to your work and performing actual tasks.

A security minded developer isn’t usually the person configuring your corporate firewall. That’s the difference between principles and tasks. A developer well-versed in the principles of user experience design isn’t likely going to be the person doing hours of contextual inquiry, persona development, and journey mapping. User experience design isn’t just an aspect of development — it’s a craft involving highly specialized skills and tasks. These activities are so radically different from other development activities that the context switching involved makes it simply impossible for someone to do both of these things very well on a day to day basis in a real world scenario.

So let me say this without any ambiguity: If you’re building a team to make great products, hire a user experience specialist or two. And if you are a user experience specialist, be proud of your work and keep kicking ass. You are valuable — even if one of the most respected minds in UX doesn’t seem to think so.

Skills matter. Therefore, specialization matters.

Back to specialization in general.

“Roles don’t matter, skills do.”

This is another assertion from my opponent that I fully agree with, while disagreeing with his conclusion. This was presented as an argument against specialization. But it only holds up against the most cynical definition of specialization. If I’ve never written any code in my life except for five lines of JavaScript, I could call myself a JavaScript specialist — after all, that’s where 100% of my coding experience lies, right?

That’s the cynical view of “specialization” — which is pretty irrelevant in any real world scenario where people’s skills are actually vetted before they are hired.

That’s not how I define a specialist. That’s not even how the dictionary defines a specialist. In my world, a specialist is someone who focuses on a particular type of work because they are passionate and highly skilled in that field.

Perhaps to avoid any ambiguity between the dictionary definition of “specialist” and the more limited, cynical definition, I should use the word “expert”. But here’s the thing… Every piece of advice I’ve ever encountered about how to become an expert at something says one thing : Follow the pursuit obsessively to the exclusion of all else.

Specialize.

Only one who devotes himself to a cause with his whole strength and soul can be a true master. For this reason mastery demands all of a person. 

— Albert Einstein

Why aren’t baseball or football players interchangeable within a team? Why can’t a shortstop step in and pitch if the pitcher gets injured? The answer is so obvious, it’s feels almost silly to answer: The different skills required for the different positions on a professional sports team require so much specific training that it’s simply impossible to develop expert-level skills for multiple positions simultaneously. There just aren’t enough hours in the day.

Perhaps tech roles are perceived differently because, to an outsider, most roles involve pecking away a computer, so they don’t look radically different. But they are.

What full-stack development really means

You may ask, “What about the concept of the ‘full-stack developer’? Surely that trend is no myth!”

No, full stack developers are very real, but there’s an interesting thing you’ll notice about full-stack developers, if you dig a little deeper.

Full stack developers almost invariably gravitate to (or create) tools that make the stuff they’re not so good at work like the stuff they are good at. This generally breaks down into “front end” vs. “back end” development, and is the root cause of the explosion of web development “frameworks” of the past five years or so.

Ruby on Rails (arguably the first highly successful full-stack web platform) uses technology like HAML and CoffeeScript to make front-end development feel more like backend development. And, coming from the other direction, every damn thing in the world can now be done with JavaScript (originally a purely front-end development language).

Full-stack developers are very good at finding ways to make one skill solve problems which normally require multiple skills. This is in no way an insult. I’m not saying that they use hammers to drive screws. I’m saying they actually invent hammers which really can drive screws. Adapting problems to known solutions is a brilliant way to reduce complexity. In fact, it’s the whole idea behind the fundamental computer science principle of abstraction. And it’s human nature. We map the unfamiliar to the familiar.

Back to UX design for a second. You’re never going to abstract user studies or wireframing excercises into JavaScript or Ruby. There’s no pre-processor or cross-compiler for that. The actual activities of UX design and coding are completely different. There’s a reason “full-stack development” also doesn’t include sales, marketing, or accounting — but aren’t all those things also needed to create a successful product?

…and what about happiness?

Let’s assume for a moment that a team where everyone is good at everything is the ideal set-up for efficiently “shipping product”. If such a team could exist, I would even accept this as obvious. But is being interchangeable cogs in product-shipping machines the future we want for ourselves and our colleagues?

The most interesting people in technology (or in anything, really) are people who are truly great at one thing, or possibly two. These people are interesting because they are following their passion. Everyone is most interesting when they follow their passion. You are most interesting when following your passion. And you are most happy when following your passion. Your team members are most happy when following their passion. And your team members are most productive when they’re happy.

Shipping product isn’t the ultimate goal in life, people. Shipping product makes money. Having money gives you the freedom to do what you love. If you’re not doing what you love, is it worth being part of a product-shipping machine?

We don’t make movies to make money, we make money to make more movies. 

— Walt Disney

Job titles, roles, and specializations don’t matter for shipping product. But they do matter for acknowledging the unique skills and passions of actual human beings, and for making them feel important, accountable, and appreciated. Maybe wanting that type of appreciation is foolish, but then feel free to call me a fool.

So, about that team structure

OK, enough with the happiness talk. You still want to know how to build an effective (and happy) development team in the real world. Well, like with many things, the realistic answer is not the clever, pithy one. It’s the boring, relatively obvious one.

You don’t need everyone on your team to be great at everything. You just need the right skills in the right places so you’re not screwed if someone gets hit by a bus. Try to have at least two people who are experts in each core skill needed to build your product (these people will likely be specialists). Then encourage and facilitate cross-pollination of a base level of fundamental cross-discipline knowledge between everyone. Not everyone will have every skill needed for making the product, but everyone must be able to have conversations with folks in the other disciplines, and know enough about each discipline not to screw the other folks up.

By the way, there actually are people out there who know a lot about a lot of things. We might call these people “great generalists”. But, if you dig further, you’ll find they usually got that way by specializing in a number of things sequentially. At any given moment in their career, they were a specialist in one thing, but carried knowledge from previous roles along with them. These people are incredibly valuable. By all means, hire them — but allow them to focus on whatever their current passion is. Don’t make them focus on what they did five to ten years ago.

Hire great people, let them do what they love, and create an environment of frequent and frictionless collaboration. You will ship that product, and you will have created an environment where passion, happiness, and creativity thrives.