Designers Will Code
Should designers code? It's an important conversation for our field, but the reality is that most designers can't and don't code as part of their regular process. We could argue about theoretical ideals, but technology is on the cusp of rendering the whole debate irrelevant.
This is significant, because the ability to implement your vision is the hallmark of great craftsmanship. It teaches you both the limits and the possibilities of your medium. Jeremy Bell of Teehan+Lax argues that designing with code is simply a more honest way to work [1]:
We spend hours designing for a medium that’s interactive and responsive, but we start by producing mockups that are static and inflexible. If great design is not only aesthetics but also how it works, then it’s time to make development part of the creative process.
Those who feel designers shouldn't code typically argue that design is hard enough as it is, without the added burden of becoming a great engineer. Jennifer Tidwell, for example, asks [2]:
So there’s lots of good stuff to learn before you can create production-quality software systems. But here’s what I worry about: it takes years to learn it well, and this is what a lot of good software engineers do for 50+ hours per week, building knowledge and picking up new skills. Practice, practice, practice.
Hey, designer. Can you afford to invest those years?
Tidwell goes on to take a fairly balanced perspective but this nicely summarizes a really pervasive idea: try to learn both design and code, and you won't become great at either.
But this isn't true. It's possible to build tools so that designers don't have to be great engineers to build great software. The question isn't "should designers code?" but "how can code work in a way that empowers designers?"
Before joining Quora, that question would've seemed hypothetical. But after working with the systems and tools our engineers have developed, it's becoming clear to me that it's the question we need to be asking.
Bret Victor details the value of weaving design and development in his piece Learnable Programming [3]:
An essential aspect of a painter's canvas and a musical instrument is the immediacy with which the artist gets something there to react to. A canvas or sketchbook serves as an "external imagination", where an artist can grow an idea from birth to maturity by continuously reacting to what's in front of him.
Victor's examples are centered around the actual development environment, but this principle accurately captures what designing in code is like at Quora. The engineering that powers Quora effectively collapses the gap between vision and working code.
I think it's worth sharing specifics on how this is possible, so let's get a little technical.
Quora is built on two systems: LiveNode and WebNode. LiveNode is the system that updates a page in real time whenever something changes. This is made possible by WebNode, a way to build pages by arranging different individual components together, rather than with large templates. Think of breaking up a page into various parts, and being able to work in isolation on those different parts without worrying about what's going on in the rest of the page. I'm simplifying things here, but this is roughly how it works — modularity taken to the extreme.
The fact that these components all stay current with live data automates a lot the engineering work. If a designer is making a form that submits an answer to a question, the existing list of answers will show the submission as soon as it's posted, without anyone writing new code telling it to update. This means that changes on the interaction or visual level usually require no engineering support whatsoever. And because we run constant deployment, and designers can push to production, a Quora designer can make changes and see them live on the site in minutes.
Working faster might sound like an incremental improvement, but taking an idea through the design process is like completing a sentence. Slowing down and switching contexts means losing your train of thought. If you're forced to take off your designer hat and dig through some documentation, you've lost that creative momentum.
Speed is important for more than just writing new code. Finding existing code, seeing the results of your changes — momentum can be lost throughout the whole process. Because every piece of the site can be tied to a single component — which means most of its code is grouped together — we have a tool that lets you hover over the page and see precisely which piece of code is powering that element:
That first line in the yellow box represents the exact file path and the specific section of code (the Python class). See that link, Open in Editor? Clicking that link opens the relevant file in your text editor of choice and actually scrolls down to the right line number so you can immediately start making changes without all the code hunting of a typical system.
And because each component has the ability to update without the rest of the page changing (that's how LiveNode remains efficient) then you can save your changes and just that component will refresh with your new code in seconds,without reloading the page, much less restarting the whole server. Change has the immediacy of a static design, but with all the functionality of a working product.
A critical necessity for the change-react-change dynamic is working on a representation that is as close to final as possible. Because most components also contain their equivalent logic for the mobile website and apps, we can tie a given page to its mobile version and show them together in the browser, allowing you to check your work in many contexts at once:
Further, we can easily switch our local version of the code to use production data, and it's trivial to gate new features so we can just live with them on the site until they're ready for public consumption.
These systems add up to create a design process that is not only interactive and immediate, but also represented in final context powered by real usage, mirroring the end-user experience more than a mockup or static HTML ever could. In other words, you're designing the real product, not an abstracted representation.
I'm not suggesting that we've found the perfect solution, or that everyone should copy WebNode and LiveNode. But I believe something similar will be the future — not designers becoming top-notch engineers, and not fully visual programming. We will instead meet in the middle: designers will become more like programmers as programming becomes more like design.
A huge thanks to Mills Baker for his ruthless editing skills. This post was originally written on Quora.
[1] http://www.teehanlax.com/blog/designing-with-code/
[2] http://designinginterfaces.com/2011/06/01/designers-that-code-a-response-to-jared-spool/
