I’m a designer. Should I code?
Should designers know how to code? And why?
Recently I have received, and accepted, several stories debating the need for designers to learn, know and write (they’re all very different processes, mind you) code. I thought it would be an opportune timing to chime in and add my two cents to the tip jar.
I think the answer all boils down to one question:
It all depends what is expected of a you, the designer.
Things have changed significantly since the days of Geocities and Angelfire. Back then, simple knowledge of HTML and some CSS (mostly inline — oh the humanity!) would suffice. However, in the age of today, there are simply to many things one has to lookout for when implementing site designs — the different frameworks and libraries that one needs to know; the new or revised languages, such as HTML5, that sounds far-fetched from their sleepy origins; and more.
As a designer and coder myself, I have to confess that this topic sounds trivial to me — I have written and designed sites where I handled both front- and backend development. However, as new technologies emerge, I start to find myself struggling to keep up. As I tried hard to learn about Node.js, the new technologies and APIs that HTML5 has made available, the process made the prickly topic about if designers should code seem less and less trivial. It spurred and piqued my interest in this debate — should designers code?
To code or not to code?
There are many solid, valid and perfectly sound arguments on both sides of the fence. One major point for the no-you-don’t-need-to-code camp is that there are developers whose role significantly overlaps with that of the coding responsibilities of a web designer. Designers should focus on the UI/UX part of design, and less about its technical implementations. There are increasing amount of web technologies that one has to take care of, and to encumber the designer with the requirement to know many of them by heart is an overwhelmingly unreasonable idea.
Meanwhile, the other camp argues, quite eloquently so, that not all teams can afford a developer proper. For simple sites, perhaps knowing HTML, CSS and basic JS would suffice — in that case when front-end development is the only concern, hiring a developer might seen as cost-inefficient with very little marginal return. In situations like this, knowing basic frontend programming actually puts you at an advantage compared to another designer who has no idea how to code.
Know what you are hired for
The point I want to bring across is simple — know what is expected of you. Do you work in a big team, where there is always a coder to handle most of the workload, yet it would still be nice for you to help out once in a while?For large teams, economies of scale becomes a significant driving factor, allowing for individual roles to be highly specific and specialized. In that case, it would be nice to know some basic coding skills, but you are also safe for not knowing too much.
Conversely, while working in a small team and/or with a shoestring budget, the designer’s role becomes significantly, and sometimes unrealistically expanded — you suddenly find yourself swamped with a deluge of delegation, from basic wireframing all the way to the (very) technical implementation and troubleshooting.
Get to know what kind of programming you are expected to do.
In my humble personal opinion, a gulf exists between front- and backend programming. Frontend comes quite naturally so with the realm that designers dwell it, snce it simply involves implementing ones design technically. However, throwing it backend programming makes things significantly difficult. For example, while working on a project at work singly, I found myself overwhelmed with questions I have never thought about — from the implementation of a simple but secure authentication framework, to the database design itself.
Not much is so much more than nothing
Know how to code, but not necessarily do it yourself.
In the end, it is important that you know how to code, but it is not absolutely necessary that you must code. Sometimes, knowing a little more about how your layouts and workflows are implemented helps to convey your idea better to another team member. Communication is key, and that, is what makes or breaks the team.
Knowing how to code helps you to put yourself in the shoes of someone who is tasked to implement your interface, workflow, design or whatnots. However, you don’t necessarily have to code, do you?
It is similar to the relationship that I have at work (in real life, I am a PhD student in molecular biology), with someone who proofreads our scientific journals and yet have little idea of the hardcore science behind it. If Becky is unsure about the phrasing in parts of the paper, it might be due to differences in our fields of expertise, or a sincere grammar mistake on my behalf. If I can explain the science behind my paper in layman’s terms to Becky, it would make her job a lot easier, too.
Becky is of course not expected understand how rhizobium-legume symbiosis work, or how the NFR1-NFR5 receptor complex interacts with their ligand, the Nod factor, to allow the plant to perceive the presence of a compatible rhizobia to establish stable symbiosis. However, if I can learn how to put what I have been researching on in a context that is familiar and comfortable with Becky, it would be a win-win situation for both of us.
This brings us to the article written by Thomas Rumbold, who is agnostic to the whole idea of the prerequisite for designers to learn and write code, but adds that having the mindset of a coder might be an advantage.
The take home message? Learn how to code. Learn how to think like a coder. But don’t expect to code unless necessary.
