Why Designers Should Code
Over the past several years the topic of the designer who codes has generated quite the lot of controversy within the tech community. Some camps believe designers shouldn't distract themselves with code and instead maintain their roots in graphic design as pixel-pushers, while others think that designers should be getting their hands dirty with code down in the trenches alongside their developer cohorts.
As I've written on the topic on more than one occasion[1] and non-coincidentally run a meetup group called Designers Who Code, it should come as no secret that I fall into the latter camp.
At the Outset
When I first started teaching myself web design back in university I didn't have any mentors to consult or tell me what to do. While I had plenty of friends in the computer science program, I was surprised to discover that they were all learning old-school Java/C++, and knew almost nothing in the realm of modern web languages nor web application development [1:1]. I'd had some exposure to the world of table-based HTML layouts and <font> tags back in high school, so in my need to make extra money to pay for beer my rent, I figured I'd just learn by Googling the hell out of anything and everything.
This way of learning has its faults, but as I had nobody telling me what or what not to do, it just seemed like common sense that I'd code up my own designs too. At the time they were mostly simple static HTML/CSS layouts, so anything I didn't already know I could quickly figure out (aka frantically Google and hit my head against the keyboard until 4am). It wasn't until I moved to San Francisco in 2012 that I found out that designers coding wasn't the norm, and what seemed like common sense to me was a foreign concept to most people I met.
This quote from Jeremy Bell from the blog of [the regretfully defunct] Teehan + Lax sums up what I encountered and how I felt pretty accurately[1:2]:
...If I was to be a designer, I couldn’t be a developer. There was never an option to do both. Instead, I’d spend hours designing static pages in Photoshop that would simply be handed to the developers for reproduction in HTML. There was rarely an opportunity to collaborate throughout the process. Hell, we barely spoke. Sometimes we weren’t even in the same timezone, let alone the same room.
That was 16 years ago, and not much has changed.
As I've previously written about, at my first full-time web design job I encountered the same problem — I was hired as the UI/UX Designer in party because I could code and communicate with developers in a way they'd understand, but within the first few hours of my first day the CTO quickly asserted that, “Designers don't touch code” (a huge sticking point that resulted in a relatively short-lived employment)[1:3]. While the concept of designers being anything more than pixel-pushers still remains a foreign concept to many companies, it thankfully seem to have been gaining more and more traction over the past few years as job listings for UI/UX Designers now regularly include “HTML/CSS” as requirements or nice-to-haves, or are listed under the guise of a “UI Developer” position instead.
You might ask, “So what, why should designers code?”
The full answer is a long one, but in short a [good] designer isn't someone who just makes things “pretty” or “functional”, but someone who strives to understand the problems at hand and develop the optimal solution to that problem, whatever set of skills that might require. This isn't to say a designers should do everything, but a good designer should know where they or their colleagues can deliver more value more efficiently and coordinate their role appropriately. In this case, there's numerous clear benefits to the designer building the frontend templates themselves.
Tightening the Feedback Loop
Nearly every web designer, myself included, has numerous stories of handing off mockups to a developer only to have the built version look nothing like the mockups that were provided. At the time it's always easy to rant and criticize the developer, but what else would you expect when you're handing off the responsibility of implementing the design to someone whose job is only tangentially related to design, and often doesn't care about the design nearly as much as you do?
This is by no means meant to criticize developers, but instead quite the opposite as I suspect a very similar problem would arise if the situation were reversed and developers gave designers specs to implement a new a feature. It might “work” in the designer’s eyes, but any experienced developer would likely cringe during the code review. Instead, a developer's job should be to build complex features and applications, not to fret over a few pixels here, a font weight there, and the crazy nuances of cross-browser CSS — that's the designer's job, and it makes infinitely more sense for the designer to be able to tweak those nuances directly rather than hunting down, bothering, and distracting a developer from their own responsibilities.
In reading a great Medium article by David Cole[1:4] I came across a rather strong quote from Jennifer Tidwell[1:5]:
So there’s lots of good stuff to learn before you can create production-quality software systems. But here’s what I worry about: it takes years to learn it well, and this is what a lot of good software engineers do for 50+ hours per week, building knowledge and picking up new skills. Practice, practice, practice.
Hey, designer. Can you afford to invest those years?
Cole goes on to dispute Tidwell by arguing that tools built for designers will help alleviate that learning curve, which while true to a certain degree, I think it misses the larger point at hand.
Designers don't need to practice 50 hours/week on development because the skills they need to cover design responsibilities aren't nearly as broad as your typical developer. Designers don't need to build a full javascript single page app (SPA) or an efficient Rails API to implement their designs effectively[1:6]; instead, they need to be able to work with primarily HTML and CSS (or SASS/LESS/etc), to build code-based static templates of their designs that can then (if needed) be taken by a developer and integrated into a larger application.
A developer who isn't trained in design nor practices it on a daily basis isn't going to notice the minute pixel differences a designer does, and being able to directly and immediately make those changes yourself helps tighten the designer/developer feedback loop in a way that pawning off frontend development responsibilities will never be able to match. Instead of a 12+ step process of delayed designer-developer communication, it instead becomes something more akin to:
- Wireframes + Mockups
- Build HTML rapid prototypes to test design elements.
- Build templates from mockups, making edits and adjustments as needed along the way.
- Iterate.
- Hand off templates to developer.
This not only makes for a much faster iteration cycle, but results in both a better end-product and frees up developers time so they can focus on building features rather than making small design tweaks. Additionally, any time you're discussing changes to an existing site with your product manager or management, rather than going through the full gambit of producing an updated mockup and iterating with your developer, you can instead often fire up Chrome Developer Tools or Firebug and test out the edits in real time, discuss, and make a fast decision right then and there.
Briefly on the topic of CSS & Javascript
CSS itself as a “programming language” is incredibly easy to criticize given it's problematic cross-browser history[1:7] and inconsistent syntax, but if someone has to deal with its insane idiosyncrasies across half a dozen browsers across dozens of devices with versions dating back at least several years, who better than the one person who really cares enough to fight their way through it all? And realistically, once you've used CSS long enough on a regular basis you start to quickly learn the quirks and ins and outs of the language, and how to use it in a way that's effective and cross-browser friendly.
To add to the mockup-to-code problem, anyone who has worked both sides of design and front-end development knows that what works in Photoshop/Sketch/[InsertToolHere] almost never perfectly translates 1:1 to what various browsers do, and you always need to make adjustments along the way. The design's not done until it's shipped, and trying to freeze it after you deliver some mockups to your development team is only doing the job halfway, and any time you try to lock-in a project that requires creative thinking you're going to achieve subpar results.
Regarding javascript, I personally love to learn new things and ended up diving head-first into its dark and magical ecosystem of libraries, frameworks, and package managers that install other package managers. I don't think this level of javascript knowledge is necessary for the majority of designers, but a minimal level of javascript knowledge goes a long way in communicating some of the finer points of your design. Want to simulate a panel or modal animating into view in a way that requires toggling or modifying style properties? Rather than mocking it up in After Effects or Keynote, you can actually build that animation exactly how you want it the first time around, and not nitpick with a developer about how it's off by 50ms or how it doesn't feel “quite right”.
Final Thoughts
There's much, much more to be written about on this topic, and I intend to do so over the coming weeks (and probably months). I've only begun to scratch the tip of the iceberg in my research efforts, and already I have well over a dozen articles from other designers and developers on the topic. As I continue to write more I might circle back and make adjustments/additions, so if you have something to say on the topic feel free reach out by Googlechat at robertnealan@gmail.com or email me at rob@atomidesign.com — I'd love to chat.
This is the first in a planned series of articles on the topic of being a designer who codes. As I publish additional articles in the series they will appear here accordingly. Cover photo is a screenshot of the Proton Radio Beta, a just publicly launched client work-in-progress.