Iterate — treat the stages as a loop, not a line

Cycle back to earlier stages as testing reveals you framed the wrong problem.

Why it works

The five stages are drawn as a sequence but used as a loop. A test result often shows the real problem was misframed, sending you back to Define or Empathize. Embracing the loop prevents sunk-cost lock-in — the mechanism is keeping the problem definition revisable in light of evidence.

How to do it

1. After each test, ask explicitly: did this challenge the solution, or the problem definition?
2. Allow yourself to return to Empathize/Define, not just to tweak the prototype.
3. Set a stopping rule (good enough for the decision at hand) so iteration does not become avoidance.

Evidence

Mechanistic. Iterative, feedback-driven development is well supported in general; the specific non-linear use of design-thinking stages is practitioner guidance from IDEO and the d.school. A controlled study by Dow and colleagues found that exploring several alternatives in parallel, rather than committing early to one, yielded more divergence and stronger design outcomes — the same logic that rewards looping back instead of locking in. (mechanistic)

Iteration can also become a way to avoid committing; the discipline is knowing when to stop, not just when to loop.

Sources

• Dow, S. P., Glassco, A., Kass, J., Schwarz, M., Schwartz, D. L., & Klemmer, S. R. (2010). Parallel Prototyping Leads to Better Design Results, More Divergence, and Increased Self-Efficacy. ACM Transactions on Computer-Human Interaction, 17(4), Article 18.

Common mistake

Treating the stages as a one-way checklist and shipping the first prototype because you "finished the process," ignoring test signals that the problem itself was wrong.