Learning to Code: A Frenemy of Design

If you’ve been on the internet and are a designer, you’ve probably heard the discussion come up of whether or not designers should code.

As a designer who does code, or possibly even a “coder” who designs at this point, I thought I’d throw some thoughts into the void of the internet on the topic.

A few years back I was working for a fantastic boutique branding agency called Foundry Collective (now Studio Mast). It was my second job out of college and honestly I had no idea what I was doing (I still don’t, really).

In that time I became the Interactive Director of Foundry and had the great privilege of working with Scott Hill in creating the online presences of the several unique businesses and brands. However, at the time, Scott wasn’t super familiar with web design and the constraints that it carries with it.
This definitely posed a bit of an interesting challenge, but also a unique opportunity that I wasn’t aware of at the time.

In college, my background was in computer science. Though, I quickly switched to graphic design after realizing that the computer science program was nothing like how programming was portrayed in the 1995 classic Hackers.

Even after switching to graphic design in college, I was amazed at how much I didn’t know about design when I first started at Foundry. I knew the basics and could create something that didn’t look like complete garbage, sure. But because of my knowledge of and background in code, I still thought about design for the web inside the framework of HTML and CSS.

Scott’s view on design at the time was focused on print, branding, and illustration. So when Scott looked at a blank canvas for the web, he didn’t think about how hard it would be to code, he thought about what made sense what was good design.

At first I was a little frustrated with how often I had to explain things about the web, but I quickly found it very refreshing how the framework of the web didn’t limit the possibilities of what he saw as possible.
Fast forward to today, we’ve created entire career paths where designers control both the entire design and implementation process—something I am grateful and excited that I’m able to do. Yet, there’s something I see sometimes that makes this awesome concept start to fall apart.

Lack of brain space.

I’ve seen designers spend countless hours talking about performance, code structure, and implementation concerns only to let the actual visual design and sometimes even the experience suffer.

I understand these things are important and crucial, but just because they are doesn’t mean the visual design isn’t. And vice-versa, etc.

Every part of a designed experience is part of a well crafted recipe that needs detailed care and attention to each element in order to get it just right. Watch the Great British Bake Off if you want to get the idea.

With that in mind, the caveat of designers who code is that we sometimes spend too long thinking about certain things whilst not spending enough time on other things. This is simply the nature of filling your cognitive space with more than one dimension of creativity.

When I was at Foundry, I took for granted the benefit of working with someone who wasn’t completely constrained by the thoughts of implementation and could have the brain space to focus on solving the design problem at hand.

The overarching problem here is that we claim it’s black and white.

Either you’re a designer who codes, or you’re not — you either care about fast code or pretty pictures—you either see the the dress as blue and black or white and gold.

Why is it that we keep pressuring people to choose one thing over another? Are we actually trying to make the industry better, or are we trying to give ourselves more meaning by saying that the way we solve problems is the best way to solve problems?

At the end of the day what matters is what works.

Whatever balance of code and design works best for you and your team to create the best end product is the route you should take and invest in.

I thoroughly enjoy blending both code and design together and using my knowledge of code to empower a design and help the engineers I work with — but, that works for me because of the background I have.

I’m not here to solve this debate or tell you how to do your job. Times are definitely changing for design—new technologies and design needs are evolving faster than ever.

To be fair, the base of this argument does have merit. And it has merit whether you’re a designer, engineer, painter, carpenter, plumber, or a fictional mathematician.

I think the argument should boil down to this: try to understand the full life-cycle of your work.

If you want to be a design specialist that focuses purely on design and never touches code, that’s fine by me. I just ask one thing — try to understand a little about how things will be implemented.

If you’re an engineer who wants to focus purely on front-end code and never touch design, that’s fine by me too. I just ask one thing — try to understand a little about why design is important and makes a particular design good or bad.

This isn’t just because understanding these things will help you communicate better with your coworkers, it’s because good design requires balance and understanding.
You can design the most beautiful thing to grace the blurred background tilted device screenshots of Dribbble, but if it can’t be implemented well, it’s not good design.

You can engineer the most fast and performant framework with the most elegant code, but if it lacks the fundamental elements of what makes a good design or experience, it will simply be a bad design served to users more quickly.

Designing solid cohesive experiences is hard, but good design is fairly simple. Step back and try to understand the full picture, but instead of letting that hinder you, use that knowledge to create something new, fresh, innovative and bold.

To put it simply, you don’t have to be a mechanic, but knowing a little about how a car works will help you take better care of your car in the long run.