Skip to content

A lot has been made of the need for designers who can code. A quick google search for “should designers learn to code” yields 25 million results.

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.

Professionals need specialized tools. Likewise, professional teams need specialized team members.

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.

That’s what we really need.

—

“We Don’t Need More Designers Who Can Code“ was originally published in Medium on December 9, 2014.

Great design is driving business success. Soon, being a design-driven company will be table stakes. But building a company that values the innovative power of design is not an easy task. For startups, the challenge is creating a design-driven culture from the ground up. For established companies, it’s even more arduous. Replacing the old status quo with a whole new mindset and process. No matter what stage your company is in, there is one decision you can make today that will put you well on your way to design-driven success:

Hire people who make things.

From the person who checks in guests at the front desk to your chief executives, to your customer service reps, engineers and your designers. Hire people who make things. Not just make things for their job, but make things on their own time because they freakin’ love to. Fill every single role in your company with people who actively participate in the act of being generative.

To be design driven doesn’t just mean hiring the best designers you can (though that is part of it), it means creating an organization that understands and embraces the struggle required to create something.

People who make things get the creative struggle.

It doesn’t matter what they make. If they crochet dollies, or code applications, craft with their kids, write music, blog or bake pastries. Makers understand the creative process. They understand the anxiety, the excitement and feeling of ownership that comes with creation. They grok ideation and iteration and the self-confidence required to ship something they created.

Why does this matter?

Empathy

One of the biggest challenges I have as a designer is deciding when to show work to people in the organization. The challenge is that many people have trouble wrapping their heads around early stage work. They can’t look at it for what it is and give constructive feedback based on that. They tend to view all design work as they would a final product. Because of this, you hold off showing. You do more “polish” work than problem solving work. And when you do show it, and changes come up, you’ve put in way more time than you should have and you now have a compressed timeline for iteration. You pay the price in organizational speed and efficiency, and ultimately work quality.

If you fill your organization with people who possess empathy for the creative process, then everyone understands early stage work and it’s easier to work through rough concepts constructively. Work moves faster, feedback comes sooner, less time is wasted and the end product is better for it.

Pride of Ownership

Makers know what it means to attach their name to something. To pour themselves into something and then sign their name at the bottom for all to see. This takes self-confidence and pride of ownership. They won’t sign their name to crap work and they won’t sign your company’s name to crap work either. If your organization is staffed, wall-to-wall, with this mentality then everyone will hold each other accountable for what goes out the door.

Innovation From All

Makers are explorers. They are actively looking for inspiration, new ideas and watching cultural happenings. Ideas can come from anywhere in an organization. If you hire a diverse group of makers, ideas will come from everywhere. Just be sure you are ready to listen.

Appetite for Risk

To create something is to be willing to take risks. To take a risk on yourself (putting yourself out there), as well as to take a risk on an idea. The scale of the risk varies, but it is the underlying mentality that is important. One key to disruptive innovation is the willingness to take risks. Established companies are often upended by small upstarts because they are unwilling to risk something new. Being a company that is willing to take risks is not just about having one, or a few, “brave” leaders. Companies create real value when people at all levels are willing and empowered to take risks. If people are able to take risks in their day-to-day job then a system of diffused innovation can grow, impacting everything from daily processes to major product initiatives.

Great, but why does my front desk person need to make things?

Ultimately, this is all about culture. The more pervasive the innovative, maker mindset is in your organization, the deeper it is engrained in your culture. In the end this translates to a more empathic process, more ideas, greater individual initiative, shared accountability and a higher appetite for risk. All of which are fundamental ingredients for design-driven success.

The next step is harnessing those ingredients. But that’s another post for another time.

Maker culture is in full tilt, explosion mode. This is an important trend, not just because of the possible impacts on the future, but because it is expanding the population of people who create. This means you have more opportunity to bring those people into your company.

Go get ‘em.

—

“Want to be Design Driven? Hire People Who Make Things“ was originally published in Medium on December 9, 2014.