“Designers shouldn’t code” is the wrong answer to the right question

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.

The core insight.

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.

The core insight is right. The conclusion is wrong.

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.

Second, “code” is such a broad term as to be essentially meaningless. What do we mean when we say this? Do we mean back-end programmers writing APIs in C#? Do we mean full-stack developers writing web applications in Rails? Do we mean front-end developers working in HTML+CSS+Javascript?

HTML + CSS + Javascript in the design workflow

The “coding” that I see lots of designers doing these days is HTML+CSS+Javascript. (I’ve met lots of developers don’t think of this as “real” coding, but let’s call it coding for now, because lots of people who argue that designers shouldn’t code are objecting to designers working at this level.) The designers that I see doing this typically have a workflow that goes from paper to a drawing tool to a pixel tool to a text editor-browser combo, then back again.

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.

Designer’s Intent

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.

A threat to the design profession

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.

UPDATES

Addendum #1: A number of commenters have pointed out that I didn’t comment on Wayne’s main point, that designers can and should pursue a career path involving strategic product leadership. I completely support that assertion. My colleague Giff Constable wrote a good post on this last year: http://giffconstable.com/2011/12/strategic-ux-vs-tactical-ux/

Addendum #2: Some commenters are coming to the conclusion that I believe designers must code. I think that’s nonsense too. The world of digital design is big and varied. (And yes, many of us work beyond the web–gasp!) The skill sets required on any one project are too big to live in one body. So… multi-skilled people? Yes. Designers must code? Nope. (I think Davide Casali’s long article on this subject handles the question with some nuance: http://intenseminimalism.com/2011/designers-shouldnt-code-the-digital-duo/)

78 comments Write a comment

  1. I come from the school of thought that you can do both. From the first moment – I was always a designer and coder. Learned to be proficient in both. Where did I start at – Well – very far back – Throughout the years I also held positions in both areas.

    Finally after 17 years – I enjoy coding more than designing. I get more from it – For design at moment – I get more pleasure doing personal art work instead of commercial work.

  2. Same as Frederick, I went to design school both undergrad and grad, and now work fulltime as a developer. My code and design chops both borrow from each other, both in project in which I’m wearing both hats, and in projects where I have to effectively communicate with product designers to find best implementation practices.

  3. I think designers must absolutely know how to code, even if they are not required to for their job. It makes the process so much easier for everyone involved if they have an understand of how their design will impact the rest of the team. Not to mention if you are doing design work for a particular CMS but have no idea how that CMS functions…its a complete nightmare.

  4. Designers must code if they are working on the web. If you expect to hand over a photoshop file to a developer, that has no design training, and get pissed off when they don’t execute it properly, that’s your fault. Would you accept the blame for a database issue as the designer? No, so why would the developer be at blame for a design issue? You have to meet them half way.

    The bottom line is that designers must be able to prototype their designs in html, css, and javascript. Photoshop is not an acceptable model for indicating user interactions that involve animation. We’re working with a clickable, dynamic medium, to provide static mock ups is not good enough.

    I feel confident to speak on this because I am educated in coding and traditional design. Was it easy no, but if you want to be successful, don’t be lazy. If you want to do print all your life, then ignore this, but if you want to design for the web you need to know how the tools work. Otherwise, you might as well toss photoshop and illustrator out the window and go back to hand drawing all your print work.

  5. I think there’s another reason why designers SHOULD code. There are some things you simply cannot create without code. I’m speaking of things such as data visualizations, where the dataset is too massive or complicated to build a visualization in Illustrator, or where you can’t get an accurate picture with placeholder data. These are two examples where designing requires code.

  6. To say designers shouldn’t code is to oversimplify things. Html, CSS and js have become the new tools of the trade. Yes, they are far more abstract than any Adobe interface and yes, they can introduce you to more complex things, but I strongly believe this is only a natural evolution. Take SASS for example.

    By creating more complete prototypes in html and css you can get far better feedback of the application behavior than mockups. I’ve always made changes from my sketches and wireframes when I finish a prototype and give it a test drive.

    Programmers design too! Because design is, above all, finding the best solution to a problem within a set of constraints. I see my developer coworkers, plan, test, and iterate.

  7. “I can’t really rebut this except to say that I’m not meeting very many unemployed UX designers these days.”

    If I do say so myself, this is some pandering, wide eyed, idealistic bullshit. Yeah, maybe YOU’RE not employed. Try talking to the many people who are trying to enter the field but struggle because they graduate school without knowing up to date technology. Or because certain companies don’t want “Designers who can code”.

    The problem with treating designers as if they are developers (And I’m not talking about HTML and CSS and even some Javascript, I’m talking actual languages here), is that you have companies that want to cut out having to hire extra employees. So they’ll hire some developer who knows how to make shitty, fugly, funky ass graphics with a pirated copy of Photoshop, right? Even if they aren’t as strong as a designer as they are a coder, or in the case of most UI/UX people, they aren’t as strong as a coder as they are a designer, but just because they can do both. This is a scenario where nobody wins, because that company doesn’t value an employee that can turn out a quality product, the kind of quality product that normally takes more than one person to produce. They just want someone who can be a code monkey and do their bidding, no matter what. The truth is, your knowledge in developing will never compete with someone who has studied it for 4 years if you just picked it up in 2. That doesn’t mean you shouldn’t learn it if you really want to, but it isn’t something you should use to advertise yourself because you are misleading people and you are also misleading yourself.

    Semi off-topic, but this attitude is also bit of the beef I have with the start up culture. In essence, People looooove to romanticize start ups and what have you for this very same reason. “But you’ll learn so many skills, you’ll be working with a small company…” righttttt. There’s this common misconception that with start ups, you aren’t privy to the similar work politics you encounter at a bigger company and that it helps you become more well rounded. The reality is much like big companies, Start Ups tend to think the same way; limitedly and with spending as little money on hiring qualified people in mind. What’s funny is when they hire people who know Javascript but may not know how to code it by hand like a developer, or who only know how to code by hacking existing code. Start ups care very little for developing the skills you are coming into the work place with; and most of them are grossly horrible to designers and don’t value good or visually strong design. It’s a one sided relationship where you have to benefit them. Pretty much like most big companies. With the added expectation of most of them expecting you to train yourself and not providing essential training to entry level candidates who really need it. Not like big companies, which have no problem even paying you for classes or for a Lynda account.

    This matters because it royally screws over designers who are interested in UI/UX and want to learn more skills. The whole field is based on the structure of designing the experience of ever evolving technology. Designers who try to learn how to code and better design software are never given the platform to do that within their jobs. And then there’s the issue of when designers try to branch out of UI/UX and can’t find work outside that field because they don’t have enough print experience, etc. So then when they can’t get that other design work, they face pressure to be employed only by what developer skills/experience with technology and languages they have, even if they are NOT developers. See, when you place an expectation on a candidate to fill a role, certain skills are given more over priority others. There’s little respect for people who love doing a little bit of everything. The truth is, UI/UX, as a field itself, is still too damn new for anyone to say that it’s going to be stable forever. Most companies still use Flash out in NYC, and there is a big demand for it. Years ago, UI/UX designers were just called Web Designers. I still see people use that term from time to time and I respect them for it, because they’re honest. Maybe it’s time to go back to that title. Because that’s all you are. You are designers. Learn to embrace it and quit it with the self hate.

  8. I fell into the conversation with @miniver (via @usabilitycounts) as it was happening. Struck a lot of chords with me—UXers shouldn’t code? Really!? And I’ve worked my ass off to learn how to. (I even write about authoring Modular CSS, but I digress.)

    I will confess that “the implementation model”, in my experience, is a very real danger. But you have to be a designer first. That means putting the user first and not being blinded by implementation. I’ve often said that “programming issues have no business being addressed in the interface“.

    I did have the pleasure of getting a brief reply from @mralancooper, and it was afterwards that I realized that there seems to be two different models for a UXer. One is based on the “Designer as Architect” paradigm. The other is the “Designer as Craftsman”. I’ll explain.

    Designer as Architect: In the three dimensional world, the architect creates the plans for a building. They think about the many aspects of how the floor plan is laid out, what direction the structure will be facing, and the many creative details of innovation. They, then, hand these plans—the designs—over to the builder who then implements them. So, the two are separate from each other—designing and building.

    Designer as Craftsman: This is an idea that comes from the Bauhaus school from the early twentieth century. The designer doesn’t only account for the aesthetic appeal and functionality of an item, but puts care into the crafting of the item. The lines are much more blurred as crafting—or building—becomes part of the design process.

    Which one of these two models is appropriate, in my opinion, depends on the needs of the organization you work for and the type of product you are building.

    Cheers!

  9. I think you can do both, but I don’t think most “professional” designers or devs do a good job at either, so it’s hard to imagine more than a handful that can. We all want to be all things to all people, but in the end we usually specialize because it’s realistic. Yeah, you can rattle off 10 to 20 technologies that are are familiar with, but how many are you an expert of?

  10. I dont really understand the separation between designing the software that generates the UI, and designing the UI.

    I don’t consider “drawing something” as UX-design.
    That’s where all these shitty brochure-websites comes from, with text beautifully faded into unreadability and shiny trinkets that might or might not be click-able.

  11. Pingback: “an oddly reductive position to hold.” | Web Development, Search Engine Optimization, Social Media Marketing Guru

  12. Sorry I am late to this party, but we’ve had this one before. I think Brian Temecula covered my response well. But for a slightly longer one: http://shoobe01.blogspot.com/2013/08/designers-cant-code.html

    Short as I can: I don’t build websites. Stipulating that UX design is 100% websites is stupid. There are DOZENS of technologies I am familiar with, from database optimization to printing. That’s a key part of my job. I EXPRESSLY stopped being a production coder (not developer) and DBA because I wanted to know a little about /everything/ which is impossible if you are working inside a handful of systems every day. Impossible on average. I am sure you can find me one, but find me 10 or 100 developers good at html, css, mSQL, iOS AND Android OS development. For starters.

  13. Pingback: What I've been reading lately (week 32), by Samuel Ericson

  14. I haven’t gone through all the comments here so if I’m making a comment subject that’s already been explored, a thousand pardons.

    I would make the point that as a designer I NEED to know HTML and CSS at the very least. Otherwise, I don’t really understand the medium I’m designing for. I preach this to my junior designers. Gone are the days where you could do whatever you wanted in a flash animation site with no regard for functionality. Design is more about function than style when it comes to websites. You create a UX around a content model and let that inform the style. Furthermore, I don’t even know how you could design a JS animation properly if you don’t know how it works. As much as I’d like to leave the presentation layer to someone and design whatever I damn well felt like, its irresponsible to everyone else involved if I don’t actually know how the site works underneath.

    Even furthermore, with the onset of responsive design, you have to be able to prototype the presentation layer or else you really have no idea what the hell you’re doing. That alone makes it a necessity. That shit (or something like it) is here to stay.

  15. With the addition of Addendum #2 I couldn’t agree more. Understanding the web as a medium and interaction design as a skill are traits design schools must include in the curriculum along side of good typography and software like Photoshop. These are the keys to success, in my opinion. I think the best designers have a powerful creative capacity to get to the root of the problem and have the tenacity to learn as much as they can about how to explore and present the best solutions. This just doesn’t apply to designing apps, web sites, or view books. But without mastering the right fundamentals and understanding what is feasible, within the scope of the project, you really do not have the tools to meet the challenges of the industry today.

  16. Like Brian, I agree that you can not be an expert in all design technologies; specially when everyday a new app is rolled out.
    Fortunately, some existing tools break the rules by allowing the generation of interactive content in HTML5, or Flash without necessarily being a master in at the coding side; at least when it comes to creating visual content.

    This makes things much easier to focus on the design, and creates efficiency in the amount of workload traditionally involved in such projects. One tool I’ve become fond of lately is Presenter from Easy WebContent. I’m using it more and more over flash to design graphics and interactive content. it might be worth a look.

  17. The issue with designers coding – even front end – is they don’t understand boundary conditions and data manipulation properly (sweeping generalisation) so they might consider a product passes QA but in fact does nothing or breaks terribly.
    (I experienced this recently when I was given a “Fully completed” product application form developed by a very high profile global agency which essentially did nothing other than write cookies, and trashed all the data if the user returned to the first screen).

  18. Pingback: Designing For Digital Products | DK Studio Home

  19. Pingback: Designing For Digital Products - rehavaPress

  20. Pingback: Getting Started With Open Source Web Design Tools | PHP World

  21. Who out there thinks HTML+CSS+JavaScript isn’t real coding?

    It is true they are higher level languages than the below but “coding” non the less!

    L1 Byte Code
    L2 Assembly
    L3 C/C++ etc
    L4 PHP etc
    L5 HTML CSS JAVASCRIPT

    I hope that gives some perspective.

    God speed!

    Hal

  22. Saying designers should or shouldn’t code is an oversimplification. This is about people not understanding the value (or skills) of their teammates and thinking they can do it better. Ego. Take it out of the web scenario and into the real world. Would I trust my architect to build a blueprint and scale model of my house? Yes. Do I want him on the construction site supervising his vision? Absolutely. Do I want him pouring the cement and putting up the support trusses? Um, well, MAYBE if he’s trained and qualified to do it — otherwise, don’t I want the construction foreman on that job? Isn’t that why I hired two guys? And if the foreman decides to take out a wall for aesthetic purposes and maybe to move some windows around for lighting, is that really his call to make? How close is he to the customer’s (MY) needs? Probably not that close, considering it was the architect who drew up the plan.

  23. Pingback: Designing with Code | Peppermint Design

  24. Pingback: Designing with Code | Manganoir

  25. Pingback: Thiết kế sản phẩm trong môi trường Digital | Làm việc hiệu quả & dễ giàng hơn

  26. Pingback: Design, production, and craft – What do designers make? | Normative