Designing by Making: your process for arranging furniture can point toward a good process for UI design

The last time you had to arrange the furniture in your home — did you create a design first? No. You had a design idea, and then immediately jumped into implementing your idea by moving the sofa and table around until the result felt good.

Hmm… let’s try putting this over here…

Consider these attributes of the typical process for arranging furniture:

1. You do it yourself. If you have enough money, you might tell movers where to put the heavy things first, but you’re still directly involved, and you’ll end up pushing things around yourself before it’s all over.
2. You work directly with the furniture and the space, without recourse to a single design artifact. Think about it: in the time it would take to create a scale model of a room and the furniture to sufficient accuracy that it could actually inform your decisions, you can finish the task of moving the real furniture into place.
3. You can never predict whether a layout will completely work until you’ve actually gotten things in place. Once the pieces are in place, you always discover something unexpected. You move your desk so it faces the door, then sit in the desk chair and realize you can’t see the view out the window. So you turn the desk around to face the window, then get a creepy feeling that someone might sneak in the door and creep up behind you without your knowledge. Each layout you try teaches you something.
4. The process is inherently iterative. You start with an idea, and iterate through various layouts until you converge on an acceptable result (or you’re tired of moving stuff around).

You can design software user interfaces this way too.

I had a chance to speak about my own design process at a talk I gave last month at the California College of the Arts in San Francisco, to an engaged audience of interesting students in the school’s MBA in Design Strategy program. There I discussed how my own design process has changed substantially in the last five years to become something I might call designing by making. In this process, the design of a software experience is inseparable from the coding of that experience. In this regard, the process has a lot in common with arranging furniture.

Many contemporary design process artifacts like field interviews, a wall of post-it notes, and paper prototypes reflect an increasingly antiquated premise: that building a real thing is much more expensive than producing a design. Historically, it has been true that designing software with a complex user interface was a minor cost compared to the labor of actually writing the code. In my early days at Microsoft, one might have seen a ratio of one designer to five to eight engineers (developers and testers), because even primitive tasks like obtaining user input or positioning interface controls in a window entailed such extensive, labor-intensive coding. It seemed sensible to invest considerable thought and time in the design phase because it could be many months before the designer would get to experience the actual product for the first time. Unfortunately, that moment of enlightenment often didn’t come until the fully-functional pre-beta builds arrived roughly two-thirds of the way through the product cycle. At that point, when the designer inevitably has new insights into the best design, any big design changes would often needed to be deferred until the next version.

Much software is still designed this way, even though the economics of user interface implementation have changed radically. The effort required to create useful, functional, beautiful, reliable, and performant software application user interfaces has been dropping for years, and this trend will continue for the foreseeable future. About five years ago, the technology reached the point where it became possible for me to create web applications directly. Rather than working in Photoshop, Microsoft Word, or a prototyping tool as before, and handing these designs off to an engineer, I can now directly create the user interface design in code myself.

This is roughly as expensive as the old way of doing things, but with the significant advance that I am now working with a functional artifact — a working user interface — from the very beginning. This turns out to be a transformative difference. Just as you can never predict all the ramifications of a particular furniture layout, you can never fully predict the strengths and weaknesses of a UI design.

Instead, I currently believe it’s best to design something by making it. This means it’s generally not worth a great deal of time to consider the hypothetical implications of a theoretical design. (“Will the user find this clear?”, “Will this meet the user’s needs?”) It’s faster to just build something that actually works, then immediately observe whether it is good or not. Instead of viewing design as a predecessor to making, this is designing by making. The process looks just like the process above:

1. Do both the design and coding yourself.
2. Work directly in code, without recourse to other design artifacts. If you’re working with good tools, in the time it would take to create an accurate static image of what you want, with all the specs that would go along with that, you can instead create a functional design that actually does what you want.
3. Know that you will be unable to predict whether a design will completely work until you actually having a working interface.
4. Build your schedule around iteration. You start with an idea, and iterate through various approaches until you converge on an acceptable result (or you’re tired of moving stuff around).

This process isn’t for everyone. There are software domains that don’t entail a user interface (Mars landers, say), where a traditional, process-heavy design phase obviously holds true. And not all designers can code, nor can all coders design. But I believe that designing by making does allows someone who can do both well to iterate much faster from an idea to a usable interface than a designer who is forced to rely on someone else to write the code.

I believe that in the near future, most software application design will look like this. The trends simplifying the coding of user interfaces will continue and accelerate, as better design/coding tools permit the construction of better design/coding tools. Component-oriented user interface frameworks will allow people to spend less time designing and coding the details of common patterns.

Furthermore, companies with experience in creating tools like Adobe are now waking up to the realities of a post-Flash world, in which the open web is the real application platform to focus on. (Microsoft is also slowly waking up to the prospect of a post-Windows client world, although that change will take much longer, and I’m not sure they’ll be able to change fast enough to stay relevant.) Generally speaking, I have high hopes for innovation in the realm of tools and frameworks, all of which should make it more and more practical for someone like you to do both the design and coding yourself.

Today, it is already possible to have a design process built around coding that is as efficient — or, often, more efficient — than a traditional, artifact-heavy, pre-coding design process. What’s more, the tool chain will ultimately improve to the point where designing a user interface will be as fast as arranging furniture. In the time it takes you to say, “Let’s try moving the bookcase over there”, and actually move the bookcase, you’ll be able to say, “Let’s try a tabbed navigation approach”, and actually switch a design to using tabbed navigation. Imagine what it will be like to design software like that.