We Don’t Need More Designers Who Can Code

To be straight from the outset, I don’t completely disagree with the premise. However, I think the statement, “we need designers who can code” misrepresents the underlying issue.

As the head of a product design team, who can also write code (front and back end), I understand the value of the combined skill set. The ability to prototype, the ability to converse cross-discipline, and the ability to understand capabilities and tweak implementations. But I also know where the boundaries lie. I am not a developer and I wouldn’t want my code underlying a production application at scale.

Saying designers should code creates a sense that we should all be pushing commits to production environments. Or that design teams and development teams are somehow destined to merge into one team of superhuman, full-stack internet monsters.

Let’s get real here. Design and development (both front end and back end) are highly specialized professions. Each takes years and countless hours to master. To expect that someone is going to become an expert in more than one is foolhardy.

Here’s what we really need: designers who can design the hell out of things and developers who can develop the hell out of things. And we need them all to work together seamlessly.

This requires one key element: empathy.

What we should be saying is that we need more designers who know about code.

The reason designers should know about code, is the same reason developers should know about design. Not to become designers, but to empathize with them. To be able to speak their language, and to understand design considerations and thought processes. To know just enough to be dangerous, as they say.

This is the sort of thing that breaks down silos, opens up conversations and leads to great work. But the key is that it also does not impede the ability of people to become true experts in their area of focus.

When someone says they want “designers who can code”, what I hear them saying is that they want a Swiss Army knife. The screwdriver, scissors, knife, toothpick and saw. The problem is that a Swiss Army knife doesn’t do anything particularly well. You aren’t going to see a carpenter driving screws with that little nub of a screwdriver, or a seamstress using those tiny scissors to cut fabric. The Swiss Army knife has tools that work on the most basic level, but they would never be considered replacements for the real thing. Worse still, because it tries to do so much, it’s not even that great at being a knife.

I don’t want my designers spending all their time keeping up with the latest cross-browser CSS solutions or learning how to use javascript closures. In the same way that I wouldn’t want our developers spending all their time diving into color theory.

I want my designers staying up on mobile interface standards and the latest usability best practices. I want them studying our users and identifying unmet needs. I want them focused on the work that is going to make our product the best that it can be. And yes, part of that work means learning about code, so they can be effective, empathetic members of the larger product team.

Now, implicit in learning about code or about design is getting your hands dirty. So this does mean that developers should be able to look critically at design concepts from a user-centered perspective, and that designers should be able to understand the basic underpinnings of how their design will be implemented. If they can also throw together a rough prototype, bonus. But we need to rid ourselves of the idea (and pressure) that designers should be coders, or that developers should be designers.

Convergence has its place, but this is not it.

If you empower your team to focus on their strengths as well as do some work to gain empathy for their teammates, then you don’t need Swiss Army knives. Instead, you have a toolbox full of experts that now work better together.