Iterative Design

A couple of recent articles have both clarified and catalysed a change that was already taking place in the way I design websites. Both Khoi Vinh’s “How to Design Faster, Maybe” and this interview with 37Signals’ Jason Fried pin down a style of work I’m beginning to employ: iterative design.

In some sense, all design is iterative. Nothing is made that doesn’t change in the space between concept and completion. But in some ways, it is the shift in our understanding—or at least, my understanding—of the idea of completion that has caused (or at least accompanied) this change. More and more, websites are not simply static repositories of information but evolutionary entities, with features and content being constantly added and stripped away, styles changing. The web is flowing, not standing still. All this, of course, is “post-launch”; it’s after the site goes public. But we can employ this approach earlier, while we’re still preparing a site for that fateful day. This is the story of how I started to do just that.

The Old Days

I used to design websites in Photoshop. At the time, this seemed to be not only convenient, but almost the only way one could design a website. The graphic-heavy, table-driven sites I made were not created with code; rather, the coding¹ was an unfortunate but necessary part of the process, where my beautiful designs were sullied by the less than inspiring reality of content and interaction.

The many designs I churned out (and there were a lot—I created over seventy for this site alone) were invariably conceptual in nature: behind each one was not the question, “What is the best way to present the information I need to present?” but an idea. There was a design with a gritty, monochrome feel that sported sunglasses and broken typewriter fonts. There were deserted, cloudy cities; green lizards; dark trees touching the water.

These were, at best, bad art. They were not websites; they were not in any sense about the content that theoretically might have found its way into them. They were emphatically not about the user—they were about me.

Struggle and Standards

Two things have changed since then. Firstly, I spent a lot more time actually making real websites for real clients, clients with content that they needed to present. I’m as ascetic and immaterialistic as the next man, but getting paid is a big incentive when you’re a starving student. Consequently, I took all the work I could get.

When one does something a lot, one tends to get better at it, and part of getting better at doing something is thinking more clearly about it. Thinking with greater clarity about what I was doing made me receptive to new ideas: specifically, the ideas of the “web standards movement”.

I put this in scare quotes because the term is often misapplied. Web standards—adhering to the letter and the spirit of W3C recommendations²—is only on aspect of a wider movement tied to blogging, CSS usage, and the loose network of web developers who discuss and promote these things. In a more perfect world we might have a name for this wider community, but in the absence of such a term, “the webs standards movement” must suffice.

It took a while, even after deciding that this was the way forward for me, to grasp what the separation of style and content actually meant. That one could display a given HTML file in myriad different ways (a la CSS Zen Garden) was easy to see. However, a more powerful and subtle thought was working on me: if a web page was a document, presented in a certain manner, then one should be writing the document and then presenting it in the most appropriate manner.

This has two major corollaries. The first is methodological: writing the underlying document is now logically prior to creating the visual design, at least to some extent. The second is normative: if the underlying document is the important thing, then the really important thing is the content.

Evolutionary Mechanisms

This is where iterative design takes off. Instead of starting with a layout in Photoshop, I start with the content—as much as I can get for the project at hand. I examine it, arrange it, rearrange it, work out what fits with what, how to structure the site. All this takes place in a notebook: the tactility of writing makes a project more real, while the indelibility of ink means I just scribble down ideas. Without the easy editing available on a computer—one can waste hours writing and rewriting some small detail—I’m forced to simply plunge ahead with my thoughts.

I then start to scrawl layout ideas, and work out some of the basics of the visual design. Importantly, everything is subject to change. I work on several different tracks at once: site structure, document structure, visual identity.

Things get hectic and complicated here, so I have to simplify. I divide my time into ‘work’ and ‘rest’ periods. When I’m working, I’m at the computer, putting the content into HTML, creating the site and document structure. I can’t do this for eight hours a day, I’d go mad, so every so often I’ll go and make a cup of tea, wander in the garden, chat to my family, and most importantly, take a break from coding.

When I do this, I’m resting, but I’m also creating a mental environment within which I can think about the project with the benefit of distance. Not being at the computer, I can’t actually do anything, only turn over ideas in my mind—and write them down. Then, refreshed and relaxed, I can go back to work and put ideas into practice. Working this way, I get better ideas, and I think them through more thoroughly, which in turn means less time is wasted sitting and staring at a blank Photoshop document.

Sometimes a new presentational idea will require me to rewrite the markup; sometimes, adding new content to the site reveals the flaws of the design, and I have to change that. By keeping my markup lean and my designs clean, I give myself the space and time to let the content change the design appropriately, allowing evolutionary change within the site until and even after the site launches. The end results are—as websites—far superior to the sites I used to make.

Footnotes

1. I coded everything by hand, even then, in the days of WYSIWYG dominance.
2. In a general sense, these recommendations call for a separation of content, presentation and behaviour, and valid code that conforms to the specifications.