Should designers learn to code?

Every Fridays night we talk about the same old question: should designers learn to code? Our industry is finally reaching a point where we are able to step back and reframe that question altogether.

There are two fundamental arguments used by those who defend the fact that designers who learn to code become more valuable than others:

• First, by creating prototypes that are as close as possible to the ultimate intent of the desired experience, it becomes more likely that it will be executed by others appropriately — if not by the designer itself.
• Second, the more a designer can speak the language of their developer peers, the better they can collaborate to get to a stronger final product.

Of course designers should know how to code. This is about being a good artisan and knowing the materials you’re dealing with.

Of course designers shouldn’t spend all day creating code. This is as inefficient as asking an architect to build a wall herself.

However, it turns out we were asking the wrong question all along.

As Dave Malouf points out in “To code or not to code? OMG! This is totally the wrong question”, while both of these arguments are truisms and irrefutable in their framing, they also continue to ignore all of the data that suggests that there are consequences to these truths — creating a unique paradox of logic.

Relying on designers being able to code can be a symptom of systemic oppression in the workplace. “As a designer, I will go out of my way to speak the language of those who hold power, to assimilate, so they will trust me. At the heart of this [contradiction] is the foundation of anthropology and the notion of balancing the outsider and insider perspectives to bring understanding through comparison. I am only as valuable as a designer as I am able to maintain that balance between the outsider and insider perspectives and to hold the mindset of student/apprentice.” — states Malouf.

In parallel to this never-ending discussion, we have been observing an ongoing evolution of the design tools we use every day that enable designers to go back to focusing on what they are really good at: designing (big surprise).

Adobe Illustrator is a great tool for web page design.

In 2018 we have seen a few transformations that corroborate that trend:

• Principle has become one of the most popular UI prototyping tools, requiring almost zero knowledge of coding and native coding languages;
• Companies like Airbnb have developed internal workflows that allow designers to sketch a UI on paper, and spit out code in a matter of seconds, bridging the gap between designers and engineers working on design systems at scale;
• New tools like Framer X and Modulz have evolved to be able to automatically translate UI patterns into React components, which means in most cases developers can build upon designs instead of replicating them in production;
• Tools like Hadron App have started to unify Design and Dev workflows into a single UI that has two distinct “views”.

This is an ordinary development tool for web pages. Yes, this is how you website looks like.

Our tools shape the way we think. While knowing how to code certainly helps designers ensure they are coming up with technically feasible interfaces, there is a new wave of tools that are gradually taking on the responsibility of making designers think in terms of components and design systems.

Modern design tools focus on the design-development collaboration. Apps can provide many features and a comfortable interface who can be changed depending on needs: from heavy code validation, to light hyper creative.  And then, merge together to the final web page.

In 2019, we will see more instances of design tools that “know how to code” — designers putting machines to work for them, as opposed to having to learn an entirely new discipline that is foreign to their craft. It will also be the year when we stop thinking in terms of “dev handoff,” and start thinking in terms of integrated workflows.