Designers, Engineers, and a Unicorn | Why designers should learn code

In the design community, there seems to be an ever growing discussion around whether or not designers should learn to code. Arguments like “Architects don’t build their own houses” float around like bad propaganda posters while job postings everywhere list HTML, CSS, and Javascript as requirements for design positions. What is the meaning behind this huge disconnect. As a unicorn, I’d like to share my thoughts with you!

Simply put, designers should know how to code.

I am not saying designers should code everything, or be front end engineers. I am saying designers should know how to articulate their designs as code. What better way to make sure your designs are implemented in the way you’d like then by handing them off in the very same medium they will be presented to the user in. Even if you chose to deliver image assets to engineering, learning to code means that you can speak the same language as the engineers.

Here are some reasons why I think designers shy away, and my reasons to overcome those obstacles.

Reason #1: Code Looks Scary

You’re a designer. You look at photoshop and all it’s many buttons and feel completely comfortable. You’ve memorized every keyboard shortcut, and even created a few of your own. You’ve tried every plug-in out there and have decided on your favorites. Then you look at HTML… and it makes no sense. There are < and / and and a } , and don’t even get started on the text colors. What are you supposed to be looking at? This is not a website. This is intimidating gibberish.

Whenever I present the idea of designers coding, the first kickback I get is about how daunting it appears to learn. While everyone learns at a different pace, I know that learning basic HTML and CSS can be done in your spare time in as little as a few weeks. Here are a few simple mental models to help expedite the learning process for designers:

• HTML is mostly content inside of containers inside of containers inside of containers. The containers can change types, and have different uses, but ultimately this is what HTML boils down to.
• CSS is like the properties section of Photoshop. You use it to define styling attributes like font size, color, and weight.
• Keep code simple, clean, and organized — code can get crazy faster than you can imagine. Put in the effort while you’re starting out to learn good code organization habits. They’ll save you!

Reason#2: Code is Constricting

As designers, our livelihood depends on our creativity and ability solve complex problems with imaginative and unique ideas. Because of the importance of this, designers are sometimes concerned that learning to code (or even designing in HTML/CSS) will restrict their ability to solve problems to just what they think the browser can do, not what they can imagine. To quote a dear friend of mine “My learning to code will make me think like an engineer, and I don’t want to lose my creativity”.

While I can understand this view, I completely disagree with it. I learned to code after doing web design for a while. After learning to code, I discovered that I didn’t realize the ways I could push the browsers to do incredible things. I had a preconceived notion of what the browser could and couldn’t do, and worked tirelessly inside of that box. After learning to code, I have opened myself up to nearly an infinite number of possibilities. Coupled with these new possibilities, I also now had the skill set to articulate what I wanted and give it to the developers in a medium they already understand.

Reason #3: It Will Upset the Balance

Designers design and coders code; so is the way of the land. Both UX people and engineers find themselves on opposite sides of a wall, designs flying back and forth. Some designers feel that this separation of function is important to foster creativity. Some companies or groups feel that the overlap of code and design is a waste of the employees’ true talents. I have heard these lines over and over about why a company shouldn’t support designers coding. However, after being both an engineer and a designer, I’ve discovered that when the two halves of the product development team are merged more seamlessly, the line between them blurred, they move so much faster, and produce far better products.

When a designer finds an inconsistency from the design to the built product, there is usually a huge cost in getting it fixed: you have to find the engineer, you have to explain the problem, you have to explain why it’s valuable to fix, then you have to wait while it sits in the backlog because it isn’t as important as some other problems for that engineer. In an age where users have extremely high expectations of the ui, these seemingly unimportant details can have a huge cost down the road, but still often get left behind. If you take the time to learn how to code, and foster a collaborative environment with your engineers, you can just go in and fix it yourself. This may seem like a rare story, or not really applicable to most situations, but I have discovered that this environment creates the best products, on the tightest deadlines, and ends with the happiest users.

In Conclusion

Designers solve problems for other people. Our biggest challenge is rarely coming up with a solution, but articulating that solution to a group of other people. We use tools like photoshop, sketch, and Invision to demonstrate our solutions to the people who can actually build them. HTML and CSS are just more tools in your toolbox to show the world your creative solutions. Why wouldn’t you take that leap?