Iteration and Variation

Two of the most basic principles of design process are iteration and variation. They aren't the same, but they are related. Iteration is making informed changes to an existing design. These changes may be provoked by user testing or critique. Commonly, these changes are provoked simply through the act of making the previous iteration; this is the pursuit of perfection, and can be endless (which drives some project managers crazy). When designing software or services, I've found that I gain a "sweeping sense" of design ideas, but I can't keep all of the details of that sense in my head at once. Iteration is the process that allows me to infuse this sense into the work and overcome the limitations of my own memory. The first pass is a "broad stroke", intended to get the essence of the idea out. For a service, this typically includes a view of the touchpoints, the people involved, the handoffs, and a few key details. In software, this is typically the "hero path": the main push through the interface, helping a user achieve a single primary goal. The input for this broad stroke is imagination, and the bottleneck is the ability to remember.

Once this broad stroke has been created (drawn, wireframed, coded, etc), further iterations assume the basic framework as fact. The initial iteration acts as a constraint, and becomes rigid: I'll refine details and extremities, review and change aspects of the idea, but the idea itself has come to life. That's good, because it serves as a creative anchor. It's bad, because I now have a subjective sense of ownership over it, and I'll become unwilling to let it go even when a better idea presents itself. Each further iteration serves to solidify details, and they become taken for granted: they become facts.

Variation is a way of adding a sense of objectivity to design exploration. Variation is an exploration of alternatives. In my own design process, I've found that I'll avoid variations unless explicitly prompted to make them, and sometimes I need to prompt myself. Where an iteration moves an idea forward (or backwards), a variation moves an idea left or right, and is not productive in a typical engineering sense: the expectation is that all of the variations (except one) will be rejected. But variations act as provocations for what-if scenarios. When I'm urging other designers to produce variations, I advocate what my friend Bob Fee calls the A-B-C-Q approach to variation. This is the idea of creating several expected variants, changing minor details (A leads to B, B leads to C), and then creating a wild or surprising jump (Q). These later "Q" jumps will ignore or purposefully reject constraints, or established precedent, or social norms, and it is from these "Q" jumps that more risky but exciting innovations emerge.

F. Scott Fitzgerald describes that "the test of a first-rate intelligence is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function." I usually can't hold opposed ideas in my mind, but I can visualize them one at a time on paper or in code, and process them at once after-the-fact. Developers are starting to embrace iteration through methods like "agile." This is useful, because it treats designed (and developed) artifacts as less precious and more malleable. It is useful to also introduce variation into a development process, in order to explore multiple ways of solving a given problem, and it is extremely beneficial to allocate development cycles to the exploration of both iteration and variation. It's not a "waste of time"; it's how design works.

Originally posted on Thu, 19 Jul 2012