Jon Kolko’s Iteration and Variation is a great article on some of the dangers of iterative design, and how to avoid them. Jon’s main point is that iteration solidifies ideas:

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. […] Each further iteration serves to solidify details, and they become taken for granted: they become facts.

One way to avoid getting stuck on the wrong path is through variation:

Variation is a way of adding a sense of objectivity to design exploration. Variation is an exploration of alternatives. […] 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.

My immediate thought was that even though this approach sounds great, it just won’t fly in most software development processes — especially if the process involves Agile methodologies. Today, Joshua Porter got to the core of why UX and Agile are often difficult to integrate in Is design building interfaces or solving problems?:

But if you view design as “problem solving” then all bets are off. In this case it may take an hour or a week to figure out a solution to a design problem — It depends on the problem and the tenacity of the designer. This makes the initial design phase more unpredictable because your first decent guess is almost always wrong or inelegant (as usability testing often shows). And this makes it more difficult to schedule — and it’s why design doesn’t fit into fixed-time sprints very well.

And that’s the thing. Problem solving involves not just iteration, but also lots of variation. This often requires time to get it wrong a few times, which doesn’t fit comfortably with the concept of release dates. See, the problem with integrating Agile and UX is not that designers want to hang on to “slow and heavy documents,” “big upfront design”, or whatever you want to call it. The problem is that each iteration further solidifies the chosen path, and there is no time to stop and ask if you’re going in the right direction.

This is, of course, where Lean UX comes in:

We are, in this model, not doing research before or after the product is made but throughout the product design and delivery process. While in an Agile UX model, Building is Designing is Building, in a Lean UX model, Building is Research is Building

My biggest concern about this, from a practical point of view, is if it allows for enough leeway to test/research different variations, or if it just streamlines the iteration process to get you to the local maximum faster. I don’t know the answer to that, but all I can say is that I’m glad I’m not the only one struggling with these issues.