Should designers code? The definitive answer.
Before I answer the most intensely debated question in designer history, let me tell you a quick story.
The story behind “Facebook Reactions”
Around 2015, the masses were begging, almost pleading, for Facebook to introduce a dislike button. Whether it was for disliking obnoxious political posts, showing disapproval at lame videos, or expressing sadness at tragedies, it seemed like almost everyone wanted a dislike button.
Due to the extremely strong and explicit user demand for the dislike button, it felt like only a matter of time before Facebook would release it. Survey after user survey and stories in the media made it look like the public had already decided what Facebook’s product roadmap would look like.
After all, how tough would it be for one of the foremost tech companies on the planet to just plonk a thumbs down button next to the like button and ship it.
But as we now know, the dislike button never shipped.
The product and design team at Facebook knew better than to accept requests from users at face value and implement it in a jiffy.
Ignoring the feature request, the design team dug a level deeper to uncover the real pain-point, ‘the why’ behind the vocal, explicit demand for a dislike button from the users.
They discovered that the real issue plaguing the user wasn’t the lack of a dislike button, but the simple truth that not everything in life is likable.
What users really wanted was the ability to react differently to different posts.
And thus was born Facebook Reactions!
The job of a designer is to dig deeper into why users are asking for certain features, and understand the real pain-point behind such requests. Designers who take the time to dig deeper and think in the second order will grow beyond knowing what their customers want, to eventually develop an understanding of why customers want whatever they’re asking for.
The distinction’s importance cannot be overstated and is more often than not the entire difference between some brilliant designers I’ve worked with and others who’ve failed to leave a mark.
This brings me to my point: If you’re asking whether designers should code, you’re completely missing the wood for the trees.
The real reason why developer’s plead for designers to know how to code is because designers today have forgotten that they essentially have two users for all intents and purposes.
Two.
The primary responsibility of the designer is to represent the best interests of the end-user in the product creation process.
But while designers usually focus intensely on understanding the end-user, the guy who will ultimately end up using the product, they’ve been guilty of neglecting the other user they have: the one much closer to home — the one who actually transforms the design into a working product — the programmer.
And it is this second user — the programmer — who craves and yearns for a piece of the designer’s bounty — empathy.
You see, the programmer also serves two masters: the computer and the end-user. But while programmers cohabit with the computer, they very rarely see the end-user.
This creates a dichotomy between the designer and the programmer — with one solely focused on pleasing the end-user whereas the other other intent on maintaining peace with the system.
What is missing in the middle of this indispensable relationship is one key element: empathy.
What the developer really yearns for is — empathy from designers.
The developer makes sense of their world by coding, so it only follows that they want others to speak the same language.
What the developer really wants though, is that designers understand the technological constraints behind whatever medium he or she designs for — a basic understanding of how certain approaches are “cheap” and some others are “expensive” either in terms of development time, cost, risk and computational practicality.
Designers, managers, and others who work with developers don’t need to know a thing about actual coding, but what they absolutely need to understand is the cost, impact, risks and tradeoffs of programming.
A developer wants a designer to understand code not because he wants a designer to also code, but to be able to empathise with them. The only language a developer speaks is code, and so it is obvious he wants designers also to be able to speak the same language — to understand developer constraints, considerations and thought processes.
What we should really be saying is that we need more designers who know about code.
Good designers have great empathy and a profound understanding of the invisible demons their end-users wrestle with; what is required is that they also empathise and understand the broad challenges programmers wrestle with.
This reminds me a familiar UX design process diagram by Paul Boag.
At its most fundamental level, product design deals with the most difficult problem in human experience: how to see things from other people’s point of view.
Designing products is ultimately an act of empathy. How well a designer can see the world through another’s eyes determines the value of their work. What designers need to understand is that their empathy has to extend both ways — with the end-user as well as the developer.
The answer then to the perennial question is, “No, designers should not code.”
However, it’s vital that anyone who directs, advises, or influences programmers should know about the hugely powerful forces at work on the programmer and their world.
So while it’s not at all important that anyone other than a programmer know about the minutia of programming, designers should be able to understand the basic underpinnings of how their design will be implemented.
In certain scenario, this could mean getting your hands dirty, where a designer has to code something up to show the developer what he really wants.
If you’re a designer working on web-projects, you may often come across various such scenarios: Be it just before the big launch of your web project when you want to make sure that every pixel is perfect and notice something is off, or you want to make some quick fixes on your client’s website.
While most in-browser “developer” tools help designers deal with such scenarios, they are obviously not built keeping designers in mind.
Sometimes, the best way for a designer to communicate their vision is to just code something up. The goal of such code isn’t the same as the goal of the code that coders write.
This code isn’t for deployment, but for design.
It’s purpose is different.
And that is why we built Visual Inspector : our FREE Chrome extension for in-browser editing.
Over the past month, we’ve been humbled by the response it has generated as it has virally spread to become the most popular tool for in-browser editing across the world. In-house designers from Instagram to Reddit have raved about it, and had more than 25,000 in 3 weeks.
Visual Inspector lets you inspect design properties from elements, edit text inline, and even experiment with colour themes and typography.
We would love for you to try it out and let us know what you think!
If you agree with us that designers shouldn’t code, why don’t you encourage us to write some more by sharing it in your circle and spreading the love ❤. In case, you don’t agree with our thoughts or have something to add, let us know in the comments.
About the author:
Abhishek currently leads product marketing at a leading ed-tech startup in India. He’s previously worked in product & marketing roles at various growth-stage startups and consulted for a couple of Silicon Valley based startups. He also writes occasionally for Wired, The Observer, Quartz, Huffington Post and other publications.
Holidays are coming! Spread the good news with your friends on Twitter. Gift them this awesome tool. They are surely going to thank you for this.
