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. (mechanistic)

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

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.