Designers are not Programmers

(After discussion with Mike Rundle, I've rewritten this essay for - hopefully - more clarity.)

There seems to be a growing sentiment that interaction designers, visual designers and UI designers need to know how to write code. Graphpaper.com quotes Mitch Kapor, writing:

Designers must have a solid working knowledge of at least one modern programming language (C or Pascal) in addition to exposure to a wide variety of languages and tools, including Forth and Lisp.

And on Joel on Software, Joel writes:

It helps, as a program manager¹, to be pretty good at coding yourself. This is unfair. Program managers aren't supposed to write code. But programmers tend to respect programmers a lot more than non-programmers, no matter how smart they are.

I disagree with this notion. In fact, I believe that being able to program can be a negative attribute for people who are responsible for designing the user experience. Designers who know how things are implemented or, even worse, who have to implement their own designs are in danger of impeding the quality of their designs. They are tempted to take code into account when they should be concentrating on the best possible user experience.

Being able to program corrupts your ability to focus solely on the human. If you know how to code, you will need to learn to ignore the code if you want to become the best user experience designer you can possibly be.²

Designers who are Programmers

Designers who also know how to code either work with dedicated programmers, or they implement their own designs. Both cases can cause issues.

In the first case, the user interaction designer is compromised because he may make premature decisions which should be left up to the programmer, who has the full picture of the code base and better knowledge of the technology. In the second case, he is compromised because he has two contradicting goals.

Designers who work with Programmers

If the designer creates designs which are implemented by a programmer, but knows how to write code, he may make premature decisions. He may submit designs which obey wrongly perceived constraints ("it's the web, so my visual design can't have drop shadows on complex backgrounds and round corners and advanced typography"), or he may decide to specify a particular technology even though his design would work better with a different technology (such as using Ajax when all necessary information for the DOM transitions could be loaded when the page loads). The more you know about HTML, the more you're tempted to think inside the HTML box.³

In my experience, visual designers who know how the web works give me blocky, boxy, "webby" designs. Which makes my job easy, but doesn't exactly push me to be my best. The people who don't know how HTML and CSS and JavaScript really work give me designs with drop shadows on complex backgrounds, round corners, interesting typography. And sometimes there's no way to implement their designs in a standards-compliant, efficient way (which is okay, because we can iterate). But more often than not, after a good night's sleep, I will come with a solution for their ideas, and the end result is all the much better for it; a lush, awesome, functional, usable application.

Designers need to be aware of interaction constraints and usability constraints, but not of technical constraints. Conversely, most programmers are very aware of technical constraints, but not of interaction and usability issues. Designers create for humans; programmers create for computers. Working together, they can create a holistic solution.

The best designs are a result of friction between the designer and the programmer, of divergent goals which combine into the optimal solution through discussion and iteration. If you try to accomodate the programmer prematurely, you will avoid this friction. This may be convenient, but will decrease the quality of the resulting solution.

A little knowledge is a dangerous thing; you can never make useful educated decisions when you only have half the picture. User experience designers should design the best possible user experience and let the people who have the full picture of the code make the best possible code decisions.

Come up with the best design you can possible create, and let the programmer surprise you with how far he actually gets.

Designers who implement their own designs

If the designer implements his own designs, he is beholden to two different goals: Clean code and great user experience. These two goals contradict each other. If you have to implement your own designs, you're bound to compromise for the sake of code quality, which is bad for your interaction design.

Designers who implement their own designs face two issues: They know when a neat new idea will create messy code, and they know about all the existing code that would be touched by a change to the user experience.

Nice UI, Messy Code

When you write code, your goal is to create a clean, maintainable, readable code base. When you design the user experience, your goal is to create a human-friendly application. The two goals are at odds, because the user experience is all about the little details, and those little details all end up being messy bits of code you would rather not have to write.

The best possible code is code with the least amount of user interface. This is why programmers love command line utilities: it's all functionality, without any of that ugly code which improves the human experience.

It's tempting for programmers to dismiss design ideas because they would result in ugly code, regardless of the idea's "human" merit.

Existing Code

If you write the code as well as creating the design, you will know about all the code you've already written. When coming up with new ideas, you may realize that the change in the user experience would require significant changes in your existing code base. This may encourage you to dismiss your new idea.

Compounding the problem is the fact that designers who write code are often tempted to forgo the whole "detailed specs" aspect of programming. They will come up with an idea and, instead of writing it down in a natural language, write it down in code. And there's nothing wrong with that.

But this does mean that they will quickly have a lot of existing code early in their project cycle. If they value their code, they will often go with the first idea they came up with, because that was the first idea they wrote down in code.

If you don't go through your iterations when establishing the spec, you'll go through them when writing the code. You're not avoiding work, you're shifting work from a natural language to a programming language.

I've worked on projects with detailed specs and on projects without specs and everything in-between. It's possible to avoid specs, but it requires you to start out with the knowledge that your code will change and that it is possible that none of the code you start out writing will make it into the end product. This is, of course, always true, but it's doubly important if you avoid design work and specs, and go straight to code.

Getting attached to your existing code will hurt your ability to improve your application. Changing the UI for the better will often require throwing away perfectly serviceable, beautifully crafted code. So don't let your existing code stop you from changing the user interface; don't get attached to your code.

At the same time, you can't cut corners when writing code, because the code you originally wrote just might make it into a shipping version of your software.

Advantages

Of course, designers who know how to code also have advantages. They do make the programmer's life easier. Having a better idea of a system's constraints, they don't submit impossible designs. And if they implement their own prototypes, they can iterate quickly instead of having to collaborate with a programmer.

If you have to do both...

I've worked as a designer for other programmers, as a programmer for other designers, and as a designer who implements his own designs.

Working on the UI while ignoring my work's implications on the code was a huge problem for me for the longest time. I would work on a user interface issue, come up with an idea, and then immediately shoot it down again because I would realize that it would be messy to implement; that it would tamper with my elegant⁴ and clean code.

Learning to ignore the code was one of the hardest things I had to to do when I started to work on user interfaces. From the engineer's point of view, a line of code written solely to improve the user experience is a line of code without functional value. It just adds mess to the code base. I had to learn to turn that part of my brain off when working on interaction design and UI design.

You work with dedicated programmers, but know how to write code

Avoid premature decisions
Let the programmers do their job
Iterate

If you work with programmers, but know how to code, then don't design for (perceived or real) technical constraints of the target system. Instead, create the best possible design based on human constraints and established user expectations, let the programmer worry about the technical constraints (trust me, we love a challenge). Iterate if the design is not possible. Don't be afraid of creating friction and pushing developers a bit further than they themselves thought they could go.

You write the code for your own designs

Learn to ignore the code
Learn to throw away code

When working the human side of your application, you absolutely can not let the computer side restrict you. Thinking about the code is not your job (at the moment). Your job is to come up with the best possible user experience. The actual implementation is a job for a different time. You need to get the code part of your application out of your head and focus only on the human side of things.

Worry about the implementation at a later date.

Conclusion

Code is executed on a machine, but the interaction design is executed on a human. You can get the machine to do whatever you want, but the human has a mind of his own; you thus have to optimize for humans, not for machines.

In my experience, knowing how to write code can be a hindrance to people who are designing the user experience. It disrupts their ability to focus on the user, and knowledge of the existing code base will impede their ability to make changes which require major rewrites. Do not force user experience designers to learn how to code.

If you already know how to do both, you need to learn to ignore the coding side of things when you're working on the user experience. And if you don't do much work on specs, instead preferring to go straight to code with your user experience ideas, you need to be prepared to throw out a lot of perfectly fine code.

If you know how to write code, if you know how your design will end up looking in code, you have to be careful not to let that knowledge constrain your design.

Please note...

I'm not saying that programmers make poor user experience designers. As I said, knowing how to code has advantages. In fact, some of the best user experience people started out as programmers. My main point is merely that knowing how to code has disadvantages, too.

This article was not intended to be controversial. It describes something I've noticed in myself, and something I've seen to varying degrees in every single person I've worked with who does both design and code. The fact that coding decisions and design decisions are often contradictory seems self-evident to me. I'm frankly surprised that there are people who deny this concept.

If you do both code and design, you need to acknowledge these disadvantages and be conscious of them so as not to let them hurt your work. I'm not trying to be confrontational; I'm trying to get you to be more conscious of your own decision making, to get you to keep potential pitfalls in mind. The next time you discount a design prematurely because it it's not easy to implement or because it requires major rewrites, please think again. The next time you make tech decisions you should leave to the programmer, please reconsider.

The next time you work on, say a visual design, ask yourself whether you made all of your choices because they were the best possible choices, or if you made them because you knew you could implement them in CSS.

And if this has never happened to you, if you've never let your knowledge of code influence your designs in a negative way, I apologize, and you're free to tell me how freaking wrong I am.

Addendum

Colin Barrett points out something I neglected to take into account, writing:

There's a reason behind the "designers should be programmers" movement: What they're really after is designers who can talk & think like programmers.

We engineers are notorious for having our own jargon-filled language. Often times an engineer will say something that sounds reasonable and concise to him, but completely goes over the heads of everyone else in the room. Not all engineers are this way, but some (many?) are. Rands talks about this on his blog.

The advantage of having a designer who can think like a programmer is obvious to anyone who has worked in an organization with engineers and non-engineers: Attempts to communicate with (or otherwise wrangle) Engineering invariably end up failing miserably.

It's not that UX people need to know the particulars of the system you're working with -- you're spot on that that creates problems. The goal is to have UX folks who can effectively understand and communicate to engineers, so that when it's time to get engineering to actually implement your interface, you'll be able to communicate effectively with engineers and produce a much better final product

Great point! Communication between engineers and designers can indeed be problematic. Given this, having designers who are capable of understanding programming lingo can be tremendously useful.