Asking designers: to code or not to code

Coding, Designers

Believe it or not, coding was a hot topic at Interactions 12, the Interaction Design conference of the year. Ryan Betts talked about code literacy and its importance for Interaction Designers, Jonas Löwgren reminded us that coding is in certain cases an indispensable sketching tool, and the general agreement was along the lines of coding is cool, learn it, don’t be scared of it

It was a healthy attitude, and I couldn’t agree more about the importance of code literacy for designers: code is the material that our designs are built with, and a solid understanding of it not only makes our developer friends like us, but simply makes our designs better. 

But understanding code to some degree is one thing, and using it in daily work is another. When thinking about the work we do in our projects at Futurice, I realized that we, the designers, (almost) never code. I started asking myself: is it enough to reach some level of literacy, or are there situations when we should also be coding ourselves? If so, what are they? In other words, To code or not to code?”

First, let’s look at the situations when we would need to code.

Good enough skills

If your skills with a technology are good enough that it’s faster for you to code the UI yourself rather than to specify it and for the developer to code it, then why not code? It might be even fun for a while (until you run into the first hurdle).

In quite a few projects at Futurice, I have been doing big parts of the CSS coding myself because I felt it would be faster this way than handing over a spec file for it. Whether it was actually faster is a different question, but that’s something that each of us can judge for themselves. Beware, though! When you start coding, you have less time for design, and there’s a risk it will suffer. Especially if you have a tight schedule and quick iterations, you might want to stick to your side just so that it gets enough attention.

No developers

If you’re working in a design agency and developers are scarce, I imagine any coding skills will be extremely valuable. In some cases, making clickable prototypes may be more useful than static screens and flow diagrams, and coding can still take you further than most prototyping tools out there (with greater effort, though). I don’t have any personal experience in a design-only agency though, so I won’t say more about this.

Uncharted terrain, fine-tuned interactions

There may be projects where you’re trying something completely new, in terms of how certain interactions should happen. Either you’re trying new forms of interaction, or you have a situation where you need to fine-tune the details a lot until you get a satisfying result. Because it’s uncharted terrain, it’s hard to get an idea of what you want from existing references, and it may be impossible to prototype it without code. 

These were a few situations I found where coding might be appropriate. How about reasons not to code, then? I’ll look at those next.

Straightforward interactions

Most of our projects are pretty straightforward, from the point of view of interaction and UI patterns we need to use. I see ‘code as a sketching/prototyping tool’ more useful when exploring new forms of interaction, or when prototyping interactions that would otherwise be impossible to prototype. But in many of our day-to-day projects, the interactions to use are more or less standard and easy to reference, so it’s relatively easy to get an idea of the desired outcome without having to code it first. And when we know what we want, we can just say it or show it to the developer in the team.

Developers are (much) faster

I was recently in a project that was a bit different from our usual projects, in that it was a lot about transitions, synchronizations, and telling a story through time. Many small fine-tunings were needed, and one could argue that this would have been a perfect occasion for me to make the adjustments myself and to get exactly what I wanted. But this would have been so time inefficient! Being such experts in the technology used, the developers were much more prepared to try any changes on the fly, and all we needed to do was to sit down together and fix the things that needed to be fixed. The going would have been so much slower had I started to learn the technology at that point!

Sketching mood

Design is a lot about sketching (as in trying things out quickly to see what happens), and in order to keep that sketching mood going, our tools need to keep a low profile. If we want to keep any kind of flow in our work, it needs to be “what if this were here and did that?” and not “how do I get this to be here and to do that?”

It’s easy to sketch with pen and paper: you just draw it, and it’s there. After some years of experience, it’s pretty easy to sketch with Photoshop too: you drag stuff around, you hit some keys to make adjustments, and the feedback is pretty immediate. With coding, the story changes (at least for me). You write stuff in a separate window and then check what came out, and then write stuff again, and so on. The feedback loop is much longer. Plus, we’ll easily get stuck in code and forget why we were doing something, instead of just experimenting continuously to get our answers. (If you want to see an excellent example of what coding with immediate feedback is like, watch Bret Victor's Inventing on Principle)

So far I’ve argued both for and against designers coding in their work, depending on the context. But is there an option somewhere in-between? I’ll look at that next.


There could be one reason to come out of our comfort zone and meet the developers halfway; and again it has to do with doing things faster. The question is this: if I said earlier that developers are faster than us in playing around with the (UI) code we care so much about, is there a way that we could get that outcome just as fast or even faster? Sure, if only Photoshop exported working code…

So then, to rephrase: would it help make things faster if we had tools that were similar to Photoshop (as in point and drag), but were tied directly into the UI code that the developers work with? As a “compromise”, we’d have to deal more directly with the code constraints, but still we wouldn’t be messing with the code itself (unless we really wanted to ;). 

That brings us to WYSIWYG editors. These kinds of coding aids have been around for some time, but in my view only now they’re finally becoming good enough to be used for this purpose. Lately I’ve been playing around with Microsoft Blend for Windows Phone 7, and I found it quite promising. After some frustrations at the start, you start learning you can drag things around and experiment with the layout, and then all the really cool things: behaviors, styles, transitions, mock data… And then it suddenly becomes fun, because you realize just how far you can get without writing any code. And of course, once you’re done making the layouts and specifying interactivity and transitions and all, the developer can just take it from there!

There is still the question of “sketching mood”, though: can we reach a level of proficiency that allows us to easily play around with things, and not get stuck in the tool? I found this a bit challenging in the beginning, when I was trying to do things “the right way”, but when I just started doing things “the fast way” to begin with, and worry about the right way later, I found that I was able to get into the flow pretty well. Even though it won’t happen overnight, we believe we could get familiar enough with these kinds of tools, and the payoff would be pretty good!

To summarize, here’s a prospective answer to the question I began with.

Code when:

  • You’re good enough that the time it takes you to do it is less than the time it takes for you to communicate it and the developer to do it
  • There are no developers to help you out
  • You’re on uncharted terrain: trying out new interactions, trying out concepts that can’t be prototyped without coding

Don’t code when:

  • Expert developers in the team can make adjustments while you speak
  • There are easy enough ways to communicate interactions and transitions
  • Familiar, predictable interactions; developers speak UX, can easily understand what you mean

Middle ground:

  • If there is a middle-ground tool that gives enough flexibility to you and clean, working code to the developers, consider using it.

So, how about you? How literate are you with code, how literate would you like to be, and when do you think coding would be useful? It would be great to hear your opinions!