COVID-19 Find out how we're helping our clients through COVID-19 Read more

Why We Hire Designers Who Can Code

Jordan Moore

Jordan Moore Director of Design

The question “Should designers code?” is almost as old as the internet itself. The question has reached almost philosophical heights. You don’t have to look very far to see pundits continue to struggle to grasp and wrestle with it. Like all great questions, it frequently resurfaces and everyone who comes up against it fails to definitively and convincingly answer it well enough to put it to rest. So fundamental is the question “Should designers code?” to our industry that I shall refer to it from here on as The Question.

For the record, I know better than to try and tackle The Question head-on just as I know I can’t definitely answer the world’s other great unanswerable questions like “Why do we exist?”. Instead, I’m going to tell you why we hire designers who can code — something I can give exact answers to without getting stuck in an endless “it depends” loop (which, by the way, is the fastest way to fail a job interview at Dawson Andrews).

The Seismic Shift that Forced Our Hand

The lack of appreciation for the role of aesthetics in digital design has been prevalent since the release of iOS 7 in September 2013. Overnight, Apple managed to make an industry of designers of “handcrafted” interfaces look foolish with what was declared a “digital native” aesthetic in direct opposition to the skeuomorphic (digital replicas of analogue material) interfaces which were commonplace at the time.

This paradigm shift led to an increase in appreciation for interaction design leaving skeuomorphic design behind — I believe skeuomorphism still has a lot to offer, but that’s for another time. The appearance of the interface was no longer centre stage, instead, how the interface behaved became the primary focus.


Most designers welcomed the shift in perspective. But this is where people who answer a definitive “No” to The Question have it completely wrong. Many on this side of The Question believe that there should be no onus on a designer to bring their ideas to life in code. They believe that static compositions and the right level of direction to a developer should be enough to guide interaction design. The problem with this stance is quite simple: to be a great interaction designer, you need to demonstrate, you know… interactions. To demonstrate interactions means getting your hands dirty with code — playing with the interface materials in their native environment to understand how they behave and fine-tune adjustments rather than kicking a static layout over the wall and hoping it comes to life just how you imagined it.

You can describe and document interactions to an engineer and they can interpret the instructions in line with the quality of the instruction, but this process ultimately is costly for both the designer and the engineer, patience gets worn thin over time, some conversations don’t even happen to give everyone an easier life — all the human factors come in to play and the promise of a great user experience lives and dies in the imagination of the designer who couldn’t see it through.

The industry is driving out the static layout designer. Whether designers are consciously aware of this or not remains to be seen. The chain of events since the digital native design aesthetics of iOS 7 brought with it the adoption of incredible new tools like Figma emphasising the importance of design systems, systematic thinking, and the handover to engineering. Digital designers who adopt the systematisation of design but fail to adapt to the new landscape are potentially designing themselves out of design as these tools get closer to code.

“We shape our tools and then our tools shape us” 
- Fr. John Culkin

The tool that gets teams from idea to living code the fastest will win. This means that if you want to survive and thrive as a digital designer in 2020, you need to expand your skill set and learn to code. Any refusal to do so is limiting the value you can offer back as an individual whilst the tooling is encroaching on every aspect of your job. 

Where The Question’s “Yes” camp has the most merit is that knowing code enables you to contend with today’s powerful toolsets and methodologies. The designer who codes thinks in components, works systematically, knows where the performance gains and loses are, understands the underlying physics of the platform (block, inline, document flow etc). They narrow the gap between form and function.

Future-Proof Your Future

For those of you who are perhaps misreading the tone here, let me be completely clear: this is a call to arms for designers who find themselves without that supporting skill to go and pick up a supporting skill. It just so happens that coding is perhaps the best fit. Stacking your skill sets multiples the value you bring into your teams.

Let’s look at a basic example scenario. You have a job opening for a designer with two candidates who are completely evenly matched in all areas including their design capabilities. Candidate A, however, happens to have a psychology degree and relevant work experience in the field. This unique skill stack complements their design skill in a way that Candidate B can’t offer with their equally matched design skills. In fact, Candidate A would bring an entirely new perspective into the company — a designer who looks at the world with a powerful lens of user behaviour and motivations will produce more valuable work than one who doesn’t have this complementary skill.

I purposely chose psychology in the example above because the coding example carries too much bias from the debate itself. It’s easy to see however that when you swap “psychology” with “coding” how Candidate A will bring more relevant value than Candidate B. The key operative here is “relevant value” which is where the “No” camp tends to sidestep in these conversations. Anyone with additional skills brings some degree of additional value, however, if coding is one of them it happens to have much more relevant value than something like a language degree or other skill stacks which don’t have as much of a value add.

I’ll never forget the uncomfortable silence that permeated the design studio where I was working when Steve Jobs’ infamous open letter to Adobe made the rounds. Not many in the studio took issue with the contents of the letter, but we knew what it meant for our only Flash Developer on the team. At the time, Flash was as common on the web as JavaScript, and a necessity for playing embedded media. Although there were new HTML standards emerging for audio and video players, a web without Flash was inconceivable until Apple’s devastating blow-by-blow account of why they weren’t going to use Adobe’s Flash technology on their devices.

Like iOS 7 and the open letter to Adobe, the effects of these seismic shifts are hard to accurately predict in advance and their effect on the people of our industry. It’s safe to assume that anything that can be automated will be automated. The main reason we hire designers who can code is simply that we hire multi-disciplined people with good talent stacks. We would rather hire someone with a desire to learn code than the person in the “No” camp because it shows initiative and willingness to adapt to an industry which is in a perpetual state of flux. Diverse skill stacks bring new, unique perspectives to challenging design problems, they increase individual and collective value across the team, and perhaps most importantly — it increases our chances of being able to work with these individuals for a long time.

Toys R Us thumbnail

Toys R Us

We were tasked with optimising the $1.5bn e-commerce function of Toys “R” Us as offline stores and leveraged debt bled the company into bankruptcy

View case study Not now