3 Reasons Why Learning To Code Makes You A Better Designer

Jared Spool

June 6th, 2011

[This topic has set off a firestorm of debate. That's good. You can see my original post here. There have been thoughtful responses from Jennifer Tidwell, Hillel at Jackson Fish Market, Matt Nish-Lapidus, and Michael Angeles. This is my last post on the topic for a little while.]

Not every job will require that a designer know how to code. However, there are three reasons why learning to code makes you a better designer:

  1. You’ll better understand the medium you’re working in. If you know what database queries will be faster than others, you can make the right response time tradeoffs. If you know what’s easy to code and what’s difficult to code, you can get your ideas implemented faster (and more of them, since development time is a limited resource.) Understanding what your medium does well and where isn’t as effective makes for more informed design decisions.
  2. Knowing how to code helps you produce better prototypes. The best way to communicate a design idea to your teammates and clients is through an interactive prototype. Producing your own quick prototypes brings your ideas to life sooner, releasing that inner brilliance you’re carrying around and helping everyone see what your designs are really about.
  3. Knowing how to code helps you identify bugs and flaws in the production code. As your team’s designs start to come to life, you can play an essential role of helping the developers isolate interaction problems, which means your end product will be the best it can be.

There’s been a lot of debate as to what languages designers should learn to code in. Based on these three reasons, I think it needs to be the languages used by the rest of the team, whatever they may be.

It’s clear from our research that designers who can code bring more to the team and, in the long run, see more of their brilliant work making it through the development process, to the user.

21 Responses to “3 Reasons Why Learning To Code Makes You A Better Designer”

  1. Dave Malouf Says:

    You had me on 1 & 2 and lost me on 3.
    Not b/c I’m too good for Q/A but b/c the usual product lifecycles would have the designer way on the next thing during this part of the design process. This is related to another criticism that comes up often in regards to the “code or not to code” debate. Which is, that when the designer becomes a production person their design time is reduced, thus causing a reduction in the amount of time.

    This brings up a bigger issue, which is to say, that while the original post was clearly framed as “Silicon Valley” and “Start ups” it is almost impossible to speak about either community separately or together as distinct from the general community. We need to have clear understanding of how to educate all desigenrs as we do not have enough educational programs to bifurcate our curriculums yet on these type of edge cases.

    Also, there is the awful slippery slope of “how much is enough and why?” I’m personally all for any interactive designer to be required to learn A programming language, any programming language. AND I would suggest languages that are far away from typical production environments. Why? B/c 1 & 2 does not require HTML/JS/ActionScript or even Java/C# to be effective. While removing the trap of getting stuck in #3.

    Then the question becomes about tools for communicating design decisions clearly AND exploring. So much can be done in a guenuine way to achieve #2 (prototyping) w/o a lick of code. My fave combo is keynote, illustrator and aftereffects. Amazing stuff can be generated with that combination or similar.

    I have seen a lot of talk from both MS and Adobe in their attempt to change the developer/designer lifecycle, but all I hear in these conversations is how designers have to be more like developers. What I’d love to see is developers become just a hair more like designers: curious, exploratory, nonlinear, visual, emotional, empathic, aesthetic. That might be nice. Let’s start creating IDEs that force developers to be those things, eh? ;-)

    – dave

  2. Bryan Says:

    I’ll go ahead and disagree with all three of these points on purely practical grounds. If a designer is good, they will consider technical limitations and make informed decisions, and they won’t necessarily need a degree in software engineering to do it.

    Get a programmer who knows a wee bit about design, and suddenly they feel the need to inject themselves into the visual design process in an otherwise silo’d environment. It goes both ways. In a more collaborative environment this may be acceptable – I wouldn’t know – but the kind of team you describe seems like either an army of magical unicorns or close to design by committee.

    And designers who know a little about programming finding flaws in production code? Don’t get me started. Designers trying to come up with their own explanations for bugs gives you good insight on how religions develop.

    The rarity and peculiar nature of designer/programmer hybrids almost guarantees that the ones who do exist will excel in both disciplines. If the job market demands these skills be intertwined, then we will see what effect splitting the difference has on a larger, more generalized scale.

  3. Pete Says:

    A little knowledge is more dangerous than a lot. Designers should design and programmers should programme.

    I’ve seen it happen when a designer thinks he can code, and believe me it’s not pretty.

  4. James Says:

    As someone who went from a more coding background into a more design background, I generally agree with these points — especially point 2. I prototype a LOT, just to see if what I’m thinking is even practical.

    Another reason it’s good for designers to know some code: it really helps communication with developers. A designer who can show they have an appreciation and understanding of programming will automatically get respect, allowing a lot better working relationships — especially when working out what is technically possible and what would make a great user experience (as unfortunately, both aren’t always possible).

  5. AJ Siegel Says:

    I have to agree with Jared and James. As someone who also went from coding to the UX field, I have a lot more credibility with my developers and QA folks. I don’t need to write a lick of code but I can communicate better because I have. For me, it makes it easier to sell UX ideas to developers when not only can I show them the UX benefit, but I can talk about the coding options to achieve it.

    For context, I work in a large corporation with distinct development and UX team. I am involved in projects that follow traditional waterfall methods and agile-y methods. The two styles present their own challenges with integrating usability in the process, but when I can empathize with the developers it helps the process along.

  6. Gene Moy Says:

    Gotta know what your medium is capable of and where it breaks. On the other hand, look how much time we spent back in the dotcom trying to get browsers to match, finally we had x-browser JS APIs, which finally, at long last, ha ha, died when we got CSS, box hacks and so on. Never mind creating clean code that wasn’t nested twenty tables/divs to high heaven. Meanwhile designers, particularly senior and management creatives, thought code acted exactly like print: they were surprised. We spun and spun just trying to catch a ride on a speeding train called the web. No bridge, and no common language, because there was no understanding of the medium and its capabilities. Usability, IxD, and all that took a backseat to just trying to launch. Everyone stayed in their little silos. Not much time for doing discovery, observing users, and all the other things if you’re doing both, is there?

    It’s true there are a lot of folks calling themselves UXers who have never put together a webpage nor nary so much as a “Hello World!” app together in their lives: they are much the worse for it. There’s an important role in our industry for the production designer/design engineer/creative developer/integrator/etc, and in fact it is probably the most critical role in the team, tying the backend to the frontend and realizing the assets. It is a key competency and I look for this as a competitive advantage over those who don’t have it.

  7. Nick van der Linde Says:

    I fully agree that having a (basic) familiarity with code provides designers with a lot more insight in the limitations that technology puts on their design. Also, and perhaps more importantly, I firmly believe that keeping up with developments can spark creativity in design, as advancements in technology continue to offer better and easier ways to craft the user experience.

    As for what languages are best suited to designers, I would argue that HTML, CSS and Javascript are probably most relevant as they are as close to design as code typically gets. Additionally, they are essential for prototyping while offering a relatively easy learning curve.

  8. Jenifer Tidwell Says:

    Good stuff, Jared. I’ve enjoyed this distributed and messy conversation!

    Regarding #3: I’ve found that being the designer on a project means caring a lot about the end product. Caring a ridiculous amount, in fact. Many times, I’ve been the only one to notice an interaction bug after implementation has been done — and sometimes I’m the only one who cares enough to advocate for a fix. If I know the software well enough to describe exactly what the fix ought to be, and how it should precisely behave after the fix is done, then it’s way more likely to get fixed.

    Here’s a more subtle point. I sometimes screw up a design, believe it or not. :-) Sometimes I won’t notice at design time that interactions I specify aren’t easy to build. Maybe I shouldn’t care about that in theory, but in the end, that code has to be built — so, yes, I sometimes change the design partway through the construction process to make it easier to implement. Again, it helps a lot if I understand the software.

  9. Rahul Says:

    100% agree with this post. I’m fascinated by the idea that this undercurrent is taking place – great designers like Jared, Ryan Singer, Glen Murphy, Rebekah Cox, Andy Clarke – all preaching the same thing. Designers who can code are better designers.

    But not enough people are talking about it. Why is Jared’s post kicking up such a storm? Yes, he’s Jared MF Spool, but it’s not like you bump into people talking about why designers should code very often. Is it really that so few designers have realised this? Or are the truly great designers who code just working on building great user experiences and not bothering to write blog posts?

  10. Designers and Programming at myninjaplease Says:

    [...] -You’ll better understand the medium you’re working in. If you know what database queries will be faster than others, you can make the right response time tradeoffs. If you know what’s easy to code and what’s difficult to code, you can get your ideas implemented faster (and more of them, since development time is a limited resource.) Understanding what your medium does well and where isn’t as effective makes for more informed design decisions. -Knowing how to code helps you produce better prototypes. The best way to communicate a design idea to your teammates and clients is through an interactive prototype. Producing your own quick prototypes brings your ideas to life sooner, releasing that inner brilliance you’re carrying around and helping everyone see what your designs are really about. -Knowing how to code helps you identify bugs and flaws in the production code. As your team’s designs start to come to life, you can play an essential role of helping the developers isolate interaction problems, which means your end product will be the best it can be. (Source) [...]

  11. Chad Hietala Says:

    I agree with everything above. #3 I think is the most crucial here, but I think can be extended into code performance. You can make an app look pretty, flow nicely, but if app is slow, the experience you designed is greatly degraded. Being able to look at production code and be able to pick out the parts that are making the experience a poor one makes you extremely valuable.

  12. ant Says:

    this post could’ve been entitled

    «Understanding What Your Collegues of a Diffrent Trade Do Will Make You Better At What You Do»

    it is in no way, shape or form, related to UX / Design work. its true for almost evey job!

  13. Sarah Horton Says:

    I totally agree.

    I have always been a designer and coder, all the way back to the days of HyperCard and Director (I know – I’m dating myself). For me the value of a design/build skillset has been understanding constraints. The best designs work brilliantly within the constraints of the medium.

    That said, I can see how this may lead to a more conventional design approach, as some have suggested. When I typeset books, I rarely break conventions. My most unconventional act is violating the left margin with hanging bullets. Shocking, I know! The same holds for my web designs. I tend to follow conventions for functional elements and use visual design and content as the differentiator.

    I’m not sure that this is a bad thing – designing within constraints and following conventions – particularly from a usability perspective. But given that the medium is so changeable and its constraints are constantly shifting, designers who code need to make a commitment to keeping up with current coding practices. Otherwise our understanding of the medium will grow stale and our designs will become quaint and outdated.

    I second (or third, fourth?) the sentiment that this is a timely and important topic. Thanks, Jared et al, for this interesting debate!

  14. Larry Says:

    Having written a million lines of code in over a dozen different languages, I can easily find value in your first point, but not point two, and certainly not the 3rd point.

    Yes, you should, as a designer, be somewhat aware of the limitations and opportunities of the medium or container within which your design must live. I don’t believe, however, you need to be a knowledgeable coder, just aware of the platform.

    To suggest that a designer should create mockups or prototypes in the native format is a bit archaic given the numerous non-code prototyping tools available that are all sufficiently rich enough to adequately demonstrate or articulate a design approach.

    Debugging is for programmers. To even think that that is the role of designers assumes that ALL programmers are prone to gross enough errors that a designer could find flaws in their code. Would you also suggest that all programmers learn all their is to know about UX/UI design processes, too?

    Another point to consider is that great UX design is more about more accurately defining the problem at the higher, more strategic level and designers whoa re mired in the low-level implementation level of coding are more likely to miss the higher order aspects, resulting in prototypes that solve the wrong problems, albeit, very well. I know that’s a bit of a stretch, but experience has shown that when folks get too close to the code, they tend to think in terms of the limitation of the current technology, thus limiting design ideas to those that fit the technology, instead of pushing the technology.

    I think you make a strong case for point number one, and I would suggest you focus on that.

  15. Michael Says:

    Is there some difference between code and design? I’m thinking of code as having no visual equivalent. HTML/CSS are structural and design languages. They don’t do anything else but markup content. While you may like GUI based tools, they all have their languages that underly the surface too (postscript, XML). As it goes, HTML/CSS is pretty easy to use and understand. Javascript may be a different beast, but basically its ‘event > action’ Understanding and changing the UI to handle events, and coming up with events that effect the design is pretty much design too. Now, there are plenty of talented people using drawing tools to communicate a finished product, but I’ll offer that its tough to call webpages ‘code’ and it is crucial to learn.

    I guess I’m on the fence about Jared’s mention of SQL, but it doesn’t hurt to know bits about a query language. Your designs will rely less on “Lorem Ipsum”.

  16. About The Three Three Says:

    [...] 3 Reasons Why Learning To Code Makes You A Better Designer » UIE … I'll go ahead and disagree with all three of these points on purely practical grounds. If a designer is good, they will consider technical limitations and make informed decisions, and they won't necessarily need a degree [...]

  17. Episode 29 | The Digital Life Says:

    [...] getting rave reviews Will Sony get hacked out of business? Eric Schmidt expansive at D9 conference Jared Spool on designers and coding Hidden App 1, Oakland Thief [...]

  18. Andy Rossi Says:

    Just a simple thought.

    I wonder why so many people think that there is this huge gap between visual design and code. Designers shouldn’t just mock something up and hand it off.

    There is a process that must continue. The design is still being finalized as the application or website is being coded. Interaction is part of the design. Workflow is part of the design. This is where “usability bugs” rear their ugly head and need the designer to find and conquer them.

    Understanding the code just enough to speak intelligently about it is key. Designers who code aren’t going to stand over the shoulder of developers to point out inefficient code. That’s just weird. They’re there to make sure that the interaction in the site is designed correctly. It’s almost like code art direction, in a way.

    Template creation can also be a part of this process. All the css/html/simple js code could be completed by the designer, then passed off to the developer for the actual buildout.

    In general, it’s definitely more convenient for designers to understand code at it’s basic level, and super helpful for them to write it. Win-win.

  19. John McSwain Says:

    First, I want to pose a different perspective on the title. Learning to UNDERSTAND code may be the best way to enunciate the points Jared listed. I do think that a deeper understanding of the working medium COULD be achieved by learning topics like reusability or OOP among other things. Prototypes can be built using a multitude of tools (Axure), but the being able build a native model quickly COULD communicate ideas quicker. Understanding code COULD help identify bugs in production…

    What bothers me more than anything are the comments that address the topic in absolutes. Every designer that understands/writes code isn’t terrible, every developer that understands/designs interfaces isn’t aesthetically inept, and every company doesn’t have roles that operate in silos. Consider the possibility that your perspective is limited…

    A major point of the article is that non-coders who understand code COULD develop empathy for other components in a product/project. I’m willing to bet that this COULD make the final product better…

  20. Patrick Neeman Says:

    I don’t think it should be the designer’s responsibility for doing the HTML/CSS. Would you ask a print designer to code in Postscript? That’s what you’re asking.

    However, understanding the limitations would be huge. I’ve worked with a lot of designers that throw things over the wall and just expect it to be built. That’s stupid. Software design should be a collaborative experience where the coder understands the design needs, and the designer understands he can design a car with five wheels.

    It’s about the concepts more than anything else.

  21. Device Proficiency | Sniffing Sharpies Says:

    [...] while back Jared M. Spool made a much noticed observation in an interesting post regarding designers who can code . It’s clear from our research that designers who can code bring more to the team and, in the [...]

Add a Comment