Iteration

Iteration

Iteration is the practice of repeatedly cycling through design, build, test, and refine — using each cycle's output to inform the next. The core insight: design problems rarely yield to single passes of careful planning. They yield to cycles, where each pass uncovers issues invisible to the prior pass. The teams that internalize iteration consistently outperform those that try to plan the perfect solution up front.

Definition (in our own words)

A design that emerges through iteration is built by repeating a small set of operations: design something; build a version of it; test it (with users, with data, with a critical eye); learn what worked and what didn't; refine; design the next version. Each cycle reveals problems that couldn't be predicted from the inside of the previous cycle. The total work to reach a good design through iteration is usually less than the work to reach the same quality through up-front planning, because iteration converges on what users actually need rather than what you predicted they would need.

Origins and research lineage

• Lidwell, Holden & Butler (2003) distinguished two types of iteration: design iteration (the planned, expected refinement during the design phase) and development iteration (the unplanned, costly rework during build that indicates inadequate design). The first is good; the second is a failure of the first.
• Henry Petroski, The Evolution of Useful Things (Knopf, 1992) and To Engineer Is Human (St. Martin's, 1985). Petroski's central thesis: useful objects evolve through accumulated failure and refinement, not through a single brilliant design moment. Successful designs encode many cycles of iteration.
• Eric Ries, The Lean Startup (Crown Business, 2011). Translated iteration into product-management vocabulary: minimum viable product, build-measure-learn loop, validated learning. Influential across software product design.
• Tom Kelley & David Kelley at IDEO, Creative Confidence (Crown Business, 2013) and earlier IDEO publications. Codified design thinking as an iterative discovery process: empathize → define → ideate → prototype → test → repeat.
• Boyd's OODA loop (military strategy, applied to design) — observe, orient, decide, act, then repeat. The faster the loop, the better the outcomes.
• Modern agile / continuous-delivery practice — Scrum, Kanban, XP, DevOps all encode iteration as a structural commitment. Releases shrink; feedback cycles tighten.

Why iteration matters

A first design is built on assumptions. Some assumptions are right; some are wrong. The wrong ones can only be discovered by exposing the design to reality — to users, to use cases, to edge cases the designer didn't anticipate. The longer the design avoids contact with reality, the more wrong assumptions accumulate; the bigger and more painful the eventual correction.

Iteration shortens the gap between assumption and verification. Each cycle exposes a few wrong assumptions; the next cycle corrects them. After several cycles, the design is largely correct because the assumptions have been replaced by observations. Without iteration, the design is shipped on assumptions still mostly untested.

The cost of iteration vs. up-front planning:

• Up-front planning is cheap to start (no implementation cost) but expensive to revise (entrenched specifications, sunk cost, political resistance).
• Iteration is expensive to start (each cycle requires building) but cheap to revise (each cycle is small).

For complex products with significant unknowns, iteration usually wins.

Design iteration vs. development iteration

The book's distinction matters in practice:

Design iteration

Planned cycles during the design phase — sketching, prototyping, testing, refining. Each cycle is intentional and produces learnings.

Healthy design iteration:

• Cycles measured in days to weeks.
• Low-fidelity prototypes early, higher-fidelity later.
• User feedback at each cycle.
• Explicit criteria for "done with this cycle."

Development iteration

Unplanned rework during the build phase, usually because the design wasn't iterated enough during design. The team builds something, discovers it doesn't work, partially rebuilds, discovers the rebuild has its own problems, etc.

Development iteration is costly because building is more expensive than designing. Reduce it by iterating more thoroughly during design.

The principle: spend cheap iteration cycles (design, prototype) to avoid expensive iteration cycles (build, rebuild).

When to apply

• Whenever the design has significant unknowns. New product categories, new user segments, new technologies — anything where you can't predict the right answer.
• In MVP design. The MVP is a vehicle for iteration; it ships not because it's "done" but because shipping enables the next iteration.
• In any project where the cost of wrong assumptions is high. Iteration tests assumptions cheaply.
• When stakeholders disagree. Iteration replaces argument with evidence.

When NOT to over-apply

• In safety-critical systems. The cost of "iterating" on aircraft control software is human lives. Use iteration during design and prototype; lock down before deployment.
• For decisions with high switching cost. Some decisions (database schema, API design that external partners depend on) are expensive to revise. Iterate intensely during design; commit deliberately.
• When the ground truth is well-known. A standard CRUD form for a familiar use case may not need many cycles. Iteration is investment in discovery; if you already know the answer, skip the discovery.

The iteration cycle

A workable cycle:

1. Define the question

What are you trying to learn or decide in this cycle? "How do users discover the new feature?" or "Which onboarding flow has higher completion?" Specific questions yield specific answers.

2. Build the cheapest thing that answers the question

The MVP for this cycle. A sketch, a clickable prototype, a coded version, an A/B test — whichever is cheapest and still answers the question.

3. Expose it to reality

Users (research session, beta cohort), data (analytics on a partial release), or a critical reviewer (design critique, code review). The design must encounter something outside the design team.

4. Observe and learn

What happened? What surprised you? What confirmed assumptions; what disconfirmed?

5. Decide the next cycle

Based on learnings, what's the next question? Refine, replace, or keep.

The full cycle should take days to weeks for most software design — fast enough that learnings stay fresh; slow enough that real building can happen.

Worked examples

Example 1: a new feature on an existing product

A team wants to add a new analytics dashboard. Iteration cycle:

• Cycle 1: paper sketches, internal review. Cheap; surfaces obvious structural questions.
• Cycle 2: clickable Figma prototype, 5 user interviews. Reveals which widgets users find valuable; which they ignore.
• Cycle 3: coded version, beta with 10% of users. Reveals real-world performance issues; surfaces edge cases.
• Cycle 4: refined version, full release with feature flag and monitoring. The dashboard is now mostly correct.

Each cycle costs more than the last; each replaces more assumptions with evidence.