The DNA of our industry is rapidly evolving. Devices are multiplying like a zombie plague; once immutable patterns are being challenged; interface conventions are changing at an incredible pace; and, all the while, our documentation is struggling to stay relevant. This constant flux can be enough to make you want to quit and buy a farm. But one thing remains constant through it all: user experiences are forged in code. Even industrial design can’t escape its reach. Code is the material that breathes life into a user experience, so we ought to get familiar with it.

Ill Communication

     - Alvin Toffler, Rethinking the Future

The UX community has been atwitter recently about whether designers should know how to code. While programming is an invaluable skill to have at your disposal, it’s not a skill we all have the need or opportunity to acquire.

But as UX professionals we are learning, unlearning, and relearning things all the time. We do it to understand the needs of our users, keep abreast of changes in our field, and communicate effectively with our clients. Understanding code is no different. And that understanding is the first step towards nurturing a healthy code literacy.

What exactly do you mean by code literacy?

First, here’s my favorite definition of literacy (my emphasis):

     - UNESCO

More on the “continuum of learning” later, but let’s also examine a reasonably terse definition of code:

[A] rule for converting a piece of information (for example a letter, word phrase or gesture) into another form or representation.
     - Wikipedia

Wonderful. Now, if you delicately splice (read: mash) those two together, you might say code literacy is:

the ability to identify, understand, interpret, create, communicate, and use rules that shape and reshape information in order to participate fully in the creation of new information.

Doesn’t sound far from what us UX professionals practice on a daily basis to produce our deliverables, does it?

How Literate Should We Be?

As with any other UX skill, the degree of literacy you require will vary. Just as not all of us need to master visual design, not all of us need to master code. But just as we all take care to understand the principles of visual design, we should also take care to understand the principles of code. An understanding of principles and mastery are the two bookends on our continuum of learning, but they aren’t the whole story. So let’s explore four archetypes that exist along the continuum.

The enthusiast

Enthusiasts understand the principles of code, and no more. They may have tried their hands at writing code once or twice, but didn’t necessarily enjoy it—at least not yet. Most importantly, they understand the thought and process that goes into writing code. Remember when you were first exploring user experience? Enthusiasts can:

  • grok the vocabulary
  • understand basic programming concepts
  • engage in meaningful conversations about development

They might even be able to intuit the difference between good and bad code.

If you work closely with an engineering or development team, achieving this degree of code literacy will allow you to communicate more effectively with them. It will also increase your empathy for what it takes to implement your designs.

What is the difference between a model, view, and controller? How much work does it take to create a new build of the application after they make a change you request? What does the debugging process look like? These are the sorts of questions an enthusiast seeks answers to. As those questions are answered, you’ll understand code—the material of user experience—much better. You’ll find that you begin to design solutions that are both more effective in delivering a user experience and more efficient to implement. The end product will improve.

The mash-up artist

Further along the continuum are the mash-up artists—people whose code curiosity has blossomed. They’ve learned enough about code and feel comfortable enough to start playing with it. Mash-up artists are able to:

  • read and understand short blocks of code
  • articulate the basic differences between languages
  • cut, paste, and make small alterations to code
  • use code to communicate pieces of functionality

This level is where code literacy really starts to provide you with a sense of agency. Have you ever seen a final implementation of something and wanted to tweak a few things? When you are code literate, it becomes much easier to just hop right in and make some changes yourself. You wouldn’t be taking that code straight to production, for sure, but you will have the ability to show, not tell, someone what you were thinking.

Mash-up artists can also begin to create interactive prototypes of specific features. Coding at this level is very much like designing using only design patterns. A mash-up artist will re-appropriate found code for their own use, often to help communicate a concept or explore an idle thought. They might be limited in their ability to customize the result, but when they provide the right context the coded prototype can be a very effective tool for communicating a new idea.

The inventor

The inventor is well equipped for an environment where UX best practices are non-existent or in a constant state of flux. The inventor knows:

  • at least one language enough to write code from scratch
  • what is and is not possible in a language
  • the difference between good and bad code
  • how much effort is required to make changes to code
  • how to code a prototype of anything

At Nitobi, our UX team is small, and we work in the volatile medium of mobile. This is fertile ground for inventors. The Nitobi UX team often takes a project from concept to code: we help to define the scope and strategy of a project, conduct user research, draft wireframes, test our ideas with prototypes, and then design and code the final UI. Oftentimes, our front-end code will go all the way to production. As inventors, we mitigate risks by taking an idea from concept to code; it allows us to quickly separate the good designs from the bad.

The wizard

Wizards are the developers that you respect and admire. The bulk of us will never achieve that level of code literacy and still call ourselves UX professionals. In short, the wizard:

  • can learn any language they need for a job
  • knows which language is best for the job
  • knows exactly what is and is not possible
  • is able to conjure anything they want

If you are a wizard when it comes to code, but consider yourself a UX professional, well… let’s just say I’m pleased that you read this far.

Ways to Start Thinking About Code

If you don’t think you’re on the continuum yet, wading into code can seem a little bit intimidating, so let’s look at a few ways you might start thinking about code.

Code as pattern

We love design patterns, don’t we? Well, so do programmers. In fact, they have been using patterns for longer than we have. What we both love about patterns is that they distill a common use case into something simple and prescriptive. And while design patterns in code typically refer to organizing concepts, code itself is very pattern-like. Code is nothing more than a series of patterns that don’t just represent something, they do something.

Code as material

I’ve referred a number of times to code as the material of user experience. Taking that idea further, it’s important to recognize that each language has a very unique set of strengths and weaknesses—its material properties. Designing for different languages is like sculpting in different materials. Just as a sculptor wouldn’t attempt the same form in ice as she would in marble, you should be wary of attempting the same project in JavaScript as you would in Java.

Code as narrative

In scripting languages such as Ruby, code blocks are, at moments, so close to plain English they can read like a Joyce novel. This means that you begin to describe the user experience and requirements, and also see how they play out on screen. As a result, you can start to notice holes in the logic and begin to refine your description.

Code as play

Once you hit a certain degree of code literacy, believe it or not, writing code becomes really fun. And we all know that play is an important part of incubation. The other day, on a lark, I noticed that you can get hilarious results replacing the word “open” with “sean penn.” It then took me a few seconds to write a bookmarklet that would do just that on any web page. While the product of play itself may be useless—and believe me, mine was—that sort of play can lead to plenty of valuable insights and discovery.

From Concept to Code

Even as an enthusiast, understanding the material of UX can help you have more meaningful discussions about development. Whether you seek to improve your designs, increase your ability to communicate new ideas, or build working prototypes, code literacy can help you achieve a higher quality end product. As UX faces a series of massive changes, our shed of tools should be changing as well, and code literacy of any degree is an invaluable addition to your repertoire as you steward a user experience from concept to code.

Add new comment


Nice post! I think your description of different roles would also be a helpful conceptual structure for teachers structuring their classes, as classes in my experience tend to focus narrowly on coding, design or learning how to use a program. When teaching novices, aiming for a 'enthusiast' level, I think, would make a lot more sense, in terms of inspiring novices to reach the point where coding becomes fun.

@Gabriel, Tom, Karen, and Ryan: Thanks for the feedback! It's cool to see that you guys identify with some of the archetypes and are working code into your practice. 

@Andre: But wizards are so powerful! I hear your point about carefully treading the line between the two sets of expertise, though. I'm not advocating that people become experts in both UX and code, though it's great if you can achieve it. And when they do, they should probably consider finding a business minded partner (unless you managed to master that, too) and running their own company. Case in point, sounds like you have a healthy freelance thing going. And, if full-time work ever sounds more appealing, it seems nothing would stop you from gaining employment as a Designer OR Developer.

When I first started out, I got hired as a developer and immediately started requesting more and more design responsibilities. It was certainly difficult to fight against the silo-ed nature of a resourcing spreadsheet, but eventually the company saw the value in having someone like me on a project. Now, it's something they very much look for. 

More than anything, it's important to move past the "clueless" end of the spectrum that Karen alluded to. Once folks get over that initial learning curve, I think natural curiousity will carry them further along the continuum - sounds like Gabriel is at that point. The more Designer/Developers there are out there, the more the job market will expect and demand that skillset.

I always shy away from terms like
'wizard' or 'rock star', but I do fit into the category of 'great at UX AND great at writing code'.

At the moment I am working for a client who hired me to design and build a complex engineering product: Rich client front end, java back end.

It's nice work when I can get it.

I think it is a great way to structure teams with 'process owners' who can work on things end-to-end versus having to hand off a feature to multiple people/teams to get it done.

The problem is that roles tend to be much more silo-ed. When was the last time you saw a job req for 'expert in UX design AND expert at writing code'?

So, although as a UX person it is great to understand code, getting too good as a software developer will often make it harder to get work since there is almost always a bright line drawn between 'designers' and 'developers'.

I'm the mash up artist. I find that when I think with a detailed knowledge of code it yields a different design than when thinking in terms of design patterns - the ideas do not flow as freely. It is usually better to work in tandem, with myself approaching from a ux pattern and meeting in the middle with the ideas coders bring to the table. The division of labor works for me! The gap from ux pattern to code can be a wide gap for many projects.

Nice post. One of the things I love about UX is that people come to the field from so many different disciplines. As a designer/developer of 8-10 years, I think I'd call myself an Inventor. I agree with you. I think a healthy understanding of code can be really useful in not only communicating but in planning for interactions.

Nice encapsulation of the roles of a UX designer. I totally agree that a designer who understands and knows the concepts inherit in different programming languages will be more able to help development along and achieve a higher quality end-product and have a smoother project flow. The stereotypical "Engineer VS. Designer" clash shouldn't exist anymore... But I do think that the spectrum of designers is very wide as you've laid out – the enthusiast/mash-up artist/wizard. You never know who you're going to get! Maybe you could add one more category before the enthusiast, which is the clueless...

Anyways, thanks for the article :) Me and my project team always talk about this topic actually!

Interesting, I think I'm "The mash-up artist", because my code curiosity has blossomed