Designers Should Learn How to Code

Over the past decade, the question “should designers learn how to write code?” has sparked a heated debate. In a 3-part series, Alan Cooper articulates why he rejects the idea that designers should to learn how to write code. He begins by pointing out that the debate is typically fueled by personal opinion, rather than facts.

Obviously, with a blog dedicated to UX Engineering, I’m going to be a bit biased here. Yes, I’m in the “designers should learn how to code” camp.

However, I’m not solely relying on my opinion to convince you. If there is evidence to support this side of the argument, then I’m going to use it.

Here are 4 reasons why designers should learn to write code.

The gap between design and development is expensive

The existing gap between UX Design and Front-End Development only exists today because we have a supply and demand problem. If companies can get the two-for-one special, they’re probably going to take it.

Money has more influence over the direction of our industry than we like to acknowledge. From a business perspective, if you can replace two expensive jobs with one, why wouldn’t you?

With an influx of job titles, such as UX Engineer and UX Developer popping up, the demand for this type of role is obvious. Companies would like to close the designer/developer gap.

There are currently 724 UX Engineer open positions on LinkedIn

Even the biggest tech companies, like Google and Facebook, have UX Engineer positions available. It’s one thing to suggest smaller companies have unrealistic expectations by requiring designers to write code, but when companies like Google and Facebook have those same expectations it’s more indicative of a shift in our industry as a whole.

Historically, companies have struggled to find people to fill this void. With UX Design being a relatively new field, combined with the fact that technology changes so rapidly, it was nearly impossible for anyone to learn both of these skills 10 years ago. We’ve used the term “unicorn” to describe such people because they were practically non-existent.

However, that is no longer the case. As John Maeda predicts, if designers want to survive in the future, they’ll have to learn how to write code.

The graph below illustrates an upward trend for the term “ux engineer” over the last 10 years.

Google Trends for the search term “ux engineer”

What happens when the marketplace is full of designers that can write code? I’m not a fortune-teller, but it seems likely that the days of handing over PSD files to developers could be replaced with something more efficient and cost-effective if companies can get their way.

Until the demand is met (if ever), we’ll continue to have this debate over whether designers should be expected to write code.

Better work process efficiency

Design iterations are necessary to hone in on a great user experience. Unfortunately, the user’s needs are not the only thing that determines the number of design iterations that you go through.

It’s not entirely possible to create a successful product by focusing on the user’s needs alone. Should their needs come first? Absolutely.

However, there are other design constraints to consider, such as SEO, performance, technical limitations, and figuring out how your product will make money.

This would imply that it’s actually a bigger issue than designers simply writing code. To have a more holistic view of a product, a designer needs to understand the business and marketing side of things too.

But that’s so much responsibility?!? Yes, having control over the direction of a product is a big responsibility. Who’s at fault if the product flops? Fingers will quickly point to the person who put all of those pieces together.

As Cooper points out in his post, designers can “know” these things without actually doing them. Sure, but can someone fully understand these design constraints without getting their hands dirty?

It’s not considered UX Design if you don’t thoroughly understand your user’s needs, so does that same logic apply if you don’t thoroughly understand the needs of your team?

Personally, my approach to design has drastically changed (for the better) by striving to understand how design impacts these other areas and vice versa. I couldn’t understand these relationships without diving into the code and exploring areas that are considered by some, to be outside of my domain.

If it’s a design constraint, then it’s not outside of my domain.

For example, speed sits on the very top of Google’s UX Hierarchy. If your page loads slowly due to large bespoke imagery, animations, drop shadows and other computation-heavy CSS, then mobile users on slow connections will never “experience” the product in the first place.

They’ll hit the back button and find something else to solve their problem.

Of course, without understanding how your design impacts performance, it’s easy to gloss over it. The mockup might have worked in the lab, but how will it perform in the wild?

With this in mind, it’s not too difficult to understand the appeal in hiring people with cross-domain expertise. This is especially true if it fills the void between design and development, which can easily be a slow, inefficient process for such a fast-paced industry.

Improved communication with the right people

The word “empathy” is thrown around a lot in design. We’re told that we need to walk in the user’s shoes to create a successful product.

But, where’s the conversation about empathizing with the other departments in your organization? They have needs too.

We’re also told that we need to speak the language our audience uses. This doesn’t stop with a product’s design. Designers are responsible for communicating their vision to other stakeholders involved with the project.

• Want your CEO to take you seriously? Discuss how your design will improve conversion.
• Want developers to understand your vision? Discuss how your design will improve performance. 
• Want your marketing department to trust you? Ensure them that you did keyword research before crafting your copy. 

These words are important to these people. This is the language they speak. However, you can’t speak this language without understanding it to some degree.

Learning skills outside of your domain helps you communicate the overall vision to everyone else that plays a role in making that vision a reality.

True innovation sits at the crossroads of design and development

This debate is simply just another form of the specialization vs generalization debate. People love to use the quote:

Jack of all trades, master of none.

This is meant to suggest that someone can’t possibly have an expertise in multiple fields. However, most people fail to recognize that the actual quote, in its entirety is:

A jack of all trades is a master of none, but oftentimes better than a master of one.

Generalization is only a “bad thing” when you dabble without following through. This is no different for specialists. You can’t master anything when you stop learning.

I’ll be the first to admit that I’m not a master at design or development. Any designer or developer who takes their career seriously knows that there is always room for improvement.

Design and development will continue to evolve over time, making it humanly impossible for one person to know everything there is to know.

Staying relevant in either field requires you to be a life-long student, not a master. Your ability to find answers is a more practical skill than assuming you already know them all.

Leonardo DaVinci had an unquenchable curiosity. This life-long pursuit of mastery positioned him to be history’s most famous polymath. One can see how his paintings were directly influenced by his understanding of anatomy. By diving into many different fields, DaVinci was able to make connections that no specialist could ever make.

Furthermore, DaVinci showed the world how true innovation happens at the intersection of design and engineering. If we bridge the gap between UX Designers and Front-End Engineers the world will see true innovation in this space too.

Conclusion

Most ux designers do not currently write code. Some UX Designers want it to stay that way. If you have no interest in learning development, then nothing is going to force you to learn it… at least for now.

Companies can hope for unicorns all they want, but if there is no supply to meet their demand, then there isn’t much they can do about it. The only alternative is to keep design and development as two separate roles.

However, more and more designers are willing and eager to learn how to write code. If companies have access to ux engineers, will it threaten the job security of non-coding designers? Only time can tell.