My friend Wayne Greenwood asked me what I thought of his recent blog post in which he argues that designers shouldn’t write code. He wrote, “Your time is the ultimate zero-sum game. The more you spend on the complexity and details of coding, the less you have to make the product experience better for your users or to influence product strategy.” My friend @miniver sucked me into the twitter debate on the subject–so I thought maybe I should share my thoughts without the 140 character restriction.
Wayne’s argument–that designers shouldn’t be coders–is based on a fundamental insight that I find compelling: if you are paying attention to how a software system will be built, you will be influenced by that need; if you don’t do something to counter that influence, you will end up with software designed around what Alan Cooper calls the “implementation model.” Cooper argues that designers who are doing a good job are making software that is designed around a user’s “mental model.”
For example, users might think of an invoice as a piece of paper with a company name, a customer name, a list of purchased items, and maybe an invoice number on it. A good onscreen design would present these things together in one view. But imagine that the system is a database system, storing this information in different tables–a customer table, a buyer table, a product table, and an invoice table. A bad onscreen design would show the information as it is stored, in separate tables, and force the user to relate these things together in his or her head. The example sounds extreme, but this type of problem happens frequently, in subtle ways, and more often than you might think.>
So I think the core insight is spot on–but what conclusions should we draw from this? Wayne argues (and not to pick on Wayne, so does Cooper, @miniver, and many others, including me a million years ago) that designers shouldn’t code. I think now that this is an oddly reductive position to hold.
First, I believe that having identified the influence, good designers and teams should be able to control for it. Most designers are comfortable starting with bad ideas and iterating until they find satisfying solutions. Along the way, we throw out lots of ideas, for lots of reasons. We should be mature enough to throw out ideas that are unduly influenced by the system model.
I don’t see this workflow as especially pernicious. It seems to me that it’s just an extension of where we used to be 15 years ago when designers had to learn PhotoShop. There’s a geeky, technical tool in this workflow, and some people get good at using it. In my experience, just as many good and bad design ideas come from this workflow as from a “pure” workflow in which roles and responsibilities are segregated.
The difference for me is that more good product comes from this workflow. In my experience, having designers in control of the presentation layer results in a presentation that more closely conforms to the designer’s intent. I imagine that most designers would think that’s a good thing.
Wayne also argues that our position as designers is threatened if we learn to code. “A singular aspect of the Great Unicorn Quest that should give you pause is the implication that user experience & design as a discipline isn’t significant enough to be a sole focus. As if designing products that people love isn’t sufficient to justify a full-time position.”
I can’t really rebut this except to say that I’m not meeting very many unemployed UX designers these days. As in none. Demand for our work has never been higher. The war is over. Design has won a place on the team. We can lay down arms, fuck around in text editors, and stop fighting the battles of yesteryear. If you’re still fighting it at your company, quit and move to SF or NYC. The future is here, and it’s hiring.