Should UX designers code?

Posted byVictor Zambrano

Short answer: not really.

I’ve always disliked the word “should“. It takes out all the joy of reasoning, understanding and deciding on a subject.

You see, I’d prefer to expose the advantages and shortcomings of the issue and let each one choose their paths. After all, I’ve had the privilege of working with great UX designers that could and couldn’t code.

First, coding is not a binary issue. There’s much more nuance to it than “can code” or “can’t code”. There are hundreds of programming languages, and not all apply to all platforms and fields of production. There are many levels of expertise for those languages. There are complexity levels for each programming language, and even amongst languages.

So suppose you design for iOS. Then the level of coding required could take one a decent 6 months to a year to learn (3-6 months in the case of Swift?). Or suppose you design for medical devices, then you might even have to take longer to learn a very obscure and unique platform. Or you’re designing for lo-tech services for emerging technologies that piggyback on existing (and obsolescent, diverse) infrastructure. Or imagine you’re designing for IoT or physical computing, and you’d need to learn at least 3-5 different programming languages and platforms, on a stack that’s getting higher, wider and more complex, and also depends on the existing platform with which you might be trying to integrate. So in light of all these examples, why is it that there are many saying designers should code?

I’d say those might be web designers, and they’re talking about front-end coding.

Many UX designers work on the web, as it is the platform with the most needs, the widest range, reach and access, the most lenient one, one that is fit for communication, etc. And those designers work and design for what’s known as front-ends (the technical name of what we designers call “interface”). So front-ends are designed by designers and then coded by front-end developers. And the front-end markup languages are not that complicated to learn: it’s mostly made of html and css (thought many more complex frameworks such as Lass/Sass, jQuery, AngularJS are being used more and more on top of the html/css base).

So what most people might be trying to say is:

[web] designers should code [ html and css, and, perhaps, javascript]

(Anyone that’s saying something else, like UX designers should learn to code Objective-C or Java is completely out of their mind and better be left alone, immediately, forever).

That sounds more specific, and more believable to us who know coding is not a binary issue. So, let’s answer this simpler, more specific, less restrictive question: Would I be a better web designer if I knew how to code for front-end?

Short answer: most probably yes.

The reason is simple: you’d then know how front-ends work and behave, so you’d also know how to design for better coded front-ends. Also, you won’t have to argue with developers on the feasibility of your designs, because you’d know it yourself, first hand.

However, the real advantage would be a powerful one: you’d be able to build “models” of your designs (like the cardboard ones architects do). You’d be able to refine your designs in code, possibly looking very much like the end product (the coded interface), and explore many nuances of the interaction, the behaviour and the levels of responsiveness of your designs you won’t be able, or it would take much effort to do, on visual apps. You’d be able to show test subjects, stakeholders, executives and clients a deliverable that might resemble much more the final product, bridging the gap that comps and wires create and therefore being able to harvest much better, more specific, faster feedback.

There are many other benefits:

Less work: On the current process, the designer does all the screen comps on a visual tool (e.g. Illustrator, Sketch), then adds a truckload of specs to assure the product is built according to predefined standards, and then exports to JPGs, PNGs or any other graphic deliverable format. This all takes a lot of effort and time, much repetitive work: adding every bit of information, duplicating and moving around, amending previous changes and adding content, not to talk about having to change all other related comps when a minor change affects one of the items in them. Then the front-end engineer grabs those comps and specs, and tecnically builds it all *again* on code, having to read all the specs and translate them to code.

Instead, coding your own prototype, all the specs are alredy there in code, and can be navigated with a browser inspector. And once you get to be pretty good at it, front-end developers can even start from your code. Which takes me to the next advantage:

Speed: Once the prototyping process is well oiled, it might be that some parts of the prototype can be reused or at least the final product can be started from the prototype, so imagine the gains in production time. Another speed gain is on the communication cycle: since your prototype is built to design specs, there’s less back-and-forth on understanding exactly what its needed from the interface and how it should look, feel and behave.

Flows: By protoyping an interface as a click-through, you’d get a much easier way to explore real user journeys and customer flows, as you can really navigate and see what the user will be going through, assess their experience, and decide what can be improved and what needs to be changed from the point of view of the user/customer.

Transitions: On a coded prototype it’s also easier to explore the use of specific transitions and animations that are part of the experience, and see how they play, tweak them and improve them all while continuing design of the product/service.

Content: In my experience (and with a bit of preparation), on a coded prototype you can better explore the relationship and impact of real content, by means of a full-fledged CMS, a simpler JSON file with content, or even hooking it up to a CSV file (or better, to a Google Spreadsheet online) that can be modified by stakeholders and content managers/strategists, and then read back by the prototype. That way 1) the content cycle will accelerate and have a more meaningful impact on the design process, 2) real content will make its way faster to the final design and 3) stakeholders will have a better, more real approach to the final product, and will feel more connected to its design and process.

The best news is that you don’t have to do the coding from scratch. Currently there are plenty of free, robust and excellent frameworks and libraries for front-end development that will help you do more in less time. Some of the best known frameworks are

(this list is not a comprehensive one, just some examples to start with).

After discussing all the great advantages of learning to code for web, I’d like to say one thing: You don’t need to code in order to design for the web (or for any other platform). What you need then is to be in close contact with how your product/service is built. Most of these advantages still exist even for designers that don’t code. It just takes for designers to work very close, elbow to elbow, with front-end developers. I’d envision a designer/front-end developer relationship like that of an Art Director and a Copywriter: none of them need to learn to do the other’s job, they just need to work together very very closely. I’d even argue that the division of roles might even benefit the process, as designers and developers might then come to the solution from their unique point of view and complement each other, and in that way both can really explore the problem at hand from their own standpoint, interest and expertise, thus giving the product/service a wider, bolder vision as the complement of both approaches.

So I’d say if you design for the web, and want to advance your career, your skills, your pace or all of the above, now you know how: learn html, css (and why not, even javascript!) to code web front-ends. It’s a lot of fun and a great decision, I bet one you won’t regret.