Approaching Design: Iterative or Linear?
- posted on February 22, 2008 / filed under design vocabulary, portfolio
- 1 comment / add yours
I am currently reading Universal Principles of Design (Lidwell et al), an excellent book recommended by Andy Rutledge in one of his podcast episodes. The book gives an overview and example of 100 different fundamental aspects of design. While most all of the topics covered are intuitively grasped, I find it immensely helpful to learn the concrete terminology & concepts used by the larger community. Time and again, I found myself saying “Ah, so that’s what they call that!”
This experience is especially true in looking back at the recent design & launch of my portfolio. Little by little, my growing design vocabulary has been able to quantify certain approaches, behaviors, and principles I employed in my quest for the perfect design. This is both for better and for worse, for there were definitely some design pitfalls I fell victim to over the past few months. At the top of this pile was my misguided approach to the design itself. The story is as follows.
Early on, I broke my design down into three general categories: layout, code, and content. The layout referred to the aesthetic look of the site, including color scheme, graphics, and typography. Content is, of course, the text that would fill up each page, from the menu elements to body copy. Code, finally, is the XHTML/CSS, PHP and eventual CMS integration that would power the site.
Having nailed down these requirements, I thought it natural to fully develop one aspect at a time. After all, wouldn’t it be easier to dive into the content after the layout was totally tweaked & polished? Wouldn’t coding be a cinch after all content was written?
I didn’t know it at the time, but this approach to the design process is known as a linear development cycle. The idea is simple: each element of the design is fully completed before the next element is started.

According to Lidwell et al, a linear model is preferred when “requirements and specifications are exact and unchanging.” Of course, this did not describe my situation. The vision of my portfolio was anything if unchanging, as I was continually taking new design ideas into account. Frequently, these new ideas would break the constraints of old ideas, forcing me to radically reshuffle or else start all over again (which I did many times).
The linear design is further called for when “the cost of iteration is prohibitive.” Was that the case in my situation? Not at all. The layout, content, and code of my website could all be tweaked at any time with utmost ease.
Luckily for me, the linear model has a counterpart: the iterative development cycle. The idea here is to develop all aspects of the design simultaneously, making a little bit of progress at a time.

Provided that the requirements of the linear design (above) are not met, an iterative approach is recommended across the board.
It didn’t take me long to realize that this was exactly the solution I was looking for. No longer would I spend 10 hours developing the perfect layout only to throw it away once I couldn’t make it fit with the content. Instead, I would spend a few hours on the layout (getting it good enough) and then flesh out the content and code to a likewise good enough level. This process would then repeat, allowing me to continually re-approach each aspect of the design already having worked with the corresponding elements.
Equipped with this priceless realization, I fully understood that my portfolio did not need to be perfect upon launch. Good enough would do for the time being, and future iterations would be follow close behind. I set for myself a deadline of one week: by that time, my website would be launched. No excuses!
I was on a mission, being spurred forward by newfound resolve and the heat of a deadline. Three things happened:
The results were immediate. Even in that first day of work, the knowledge of my impending time limit forced me to accept “good enough.” Although no aspect of the design met my ideals of perfection, I was emboldened with the knowledge that I would be returning to improve each facet of the design in short time.
The outcome was favorable. In only one week, I had slain the demon that had loomed in the shadows for far too many months. My website was finally launched. I was out there, having proudly hoisted my flag in the online design world. No longer did I wait on the sidelines, dreaming of the day when I too had a portfolio. It felt good.
The future loomed brighter than ever before. As great as I felt, there was even more to look forward to! I knew that with every week and month this general pattern would repeat itself: slight upgrades & tweaks would be made to all aspects of the design, the website’s design integrity increasing steadily all along.
Perhaps the most fundamental lesson taken away from this experience has to do with the worth of a design vocabulary. When you are able to concretely define that which is otherwise abstract, you have a semblance of control and power over the concept. You can make the concept work for you instead of the other way around. In this light, I recommend Universal Principles of Design to all. Although my reading on the topic has for the most part just begun, this is (so far) the most illuminating text I have come across.

Sue said:
at 6:37 pm on May 20th, 2008
Very interesting article! The concept of iterative work flow sounds interesting, but probably isn’t that practical for large-scale development teams. If you’re a one-person developer, sure, you can go back and forth between the stages - but if there are specialized people taking care of specific stages then it could lead to frustrations and conflicts as the developer has to re-do section due to design changes… is the book quite academic and theoretical, or does it also have plenty of design inspiration?
Post reply