Studio Matrx Monthly · Volume 1 · Issue 1 · June 2026
Amogh N P
 In loving memory of Amogh N P — Architect · Designer · Visionary 
Iteration disciplineLesson 5.4
Design Thinking/Module 5 · Test & Iterate — closing the loop

Lesson 5.4

Iteration discipline

Versioning, and knowing what to change and what to hold

6 min Lesson 27 of 32
The hook
Two designers get the same five flaws. The first panics and changes everything — rips up the whole design, and in fixing the too-low dais accidentally destroys the daylight that was working. The second changes surgically — fixes the five flaws, protects the four things the test proved good, keeps a record of what changed and why, and ends up strictly better. Same flaws, same talent. The difference is iteration discipline.

Not all flaws are equal

A list of failures is not an improved design. The cardinal error is treating every flaw as a reason to tear down and rebuild. Flaws come in different depths — a surface detail (the dais is 100mm too low) or something fundamental (the concept misreads how the family lives) — and each depth calls for a different size of response. The discipline begins with diagnosing the depth, which tells you how far back to loop.

How far to loop back: the depth tells you

A surface flaw (the dais is too low) loops back one step, to Prototype — adjust and re-test, touch nothing else. A concept flaw (the layout fights the family's evening routine) loops back to Ideate — generate new options, reaching into your reserve of un-chosen ideas. A deep flaw (the family doesn't want anything like this) loops all the way to Empathise — you misread the people, and no tweak fixes that. Loop the right distance: the panicking designer over-loops and throws away good work; the lazy designer under-loops and papers over a concept flaw with a cosmetic tweak. Most flaws are surface or concept — short or medium loops. The courage to loop all the way back when a test reveals a deep flaw separates honest design from stubborn design.

Hold what works

A good test tells you what's working as clearly as what's broken — and you must protect the working parts as fiercely as you fix the broken ones. The panicking designer who redesigns the whole room to fix the dais destroys the daylight, the circulation, the prayer-corner placement the family loved. Iteration that doesn't hold the good goes sideways, not forward — you trade a known flaw for a fresh unknown one. Disciplined iteration is surgical: change the broken thing, hold everything the test proved good, and re-test to confirm the fix didn't break a neighbour. Iteration is change plus protection plus re-verification — never change alone.

Versioning

Keep a clear numbered record of each version and what changed and why — v0.1 → v0.2 → v0.3 (the version-control logic Studio Matrx's DesignAI uses, with an audit trail). It lets you iterate without fear (every version is saved, so you can try a bold change and return if it fails), keeps a record of why (so you don't re-make a rejected mistake), and makes the loop visible and honest — the version history is the loop as a document, and you can see the design converging, each version measurably better against the brief's success criteria.

empathisedefineideateprototypetest surface flaw → tweak the prototype concept flaw → rethink the idea deep flaw → you misread the people; back to empathy
The depth of the flaw tells you how far back to loop. Loop the right distance — neither too short nor too long.
Go deeper — for practitioners & students

Change one major thing per iteration, not five — if you fix five at once and re-test and it got worse, you can't tell which change caused it; isolating consequential changes keeps cause and effect legible so you learn from each iteration. Some flaws should be deliberately not fixed — a minor flaw not worth the side effects, or one whose fix worsens something more important, or one the client should decide on; iteration discipline isn't fixing everything but fixing the right things and consciously accepting the rest (Simon's satisficing). And guard against the two opposite pathologies — thrashing (endless change without convergence, usually from lacking clear success criteria) and premature freezing (stopping too early from attachment or fatigue). Healthy iteration is convergent: each version measurably closer to the agreed criteria.

Try it

1. Diagnose each flaw's depth — surface (Prototype), concept (Ideate), or deep (Empathise) — being honest, not downgrading a concept flaw to avoid the work. List what to hold (the wins, the green rows) — guard these as fiercely as you fix the flaws. Iterate surgically, one major change at a time, re-checking that you didn't break the hold-list. Version it with a short changelog (what changed, why, what was held, what re-testing showed) and mark which flaws you consciously chose not to fix, and why.

Check yourself

3 quick questions — pick an answer to see why.

Q1A test reveals the family doesn't want anything like the proposed design. How far should you loop back?

Q2Why change only one major thing per iteration?

Q3What does 'iteration is change plus protection plus re-verification' mean?

Key terms

Loop distance
How far back a flaw sends you depending on its depth — a surface flaw to Prototype, a concept flaw to Ideate, a deep flaw all the way to Empathise.
Hold-list
The working parts a good test proves good — daylight, circulation, a loved prayer-corner placement — which must be protected as fiercely as the flaws are fixed.
Versioning
Keeping a numbered record (v0.1 to v0.2) of what changed and why, the logic Studio Matrx's DesignAI uses, so you can iterate without fear.
Recap
Finding a flaw isn't fixing it — flaws come in depths, and the depth tells you how far to loop back: surface to Prototype, concept to Ideate, deep to Empathise. Loop the right distance — the panicking designer over-loops and destroys good work, the lazy one papers over cracks. Equally vital: hold what works — iteration is change plus protection plus re-verification, never change alone. Versioning lets you iterate without fear, remembers why, and makes the loop a visible converging document. Change one major thing per version, consciously accept some flaws rather than chasing ruinous perfection, and avoid both thrashing and premature freezing.
Carry forward →

Versioning shows your design converging, getting better each loop. But the loop could go on forever — there's always one more flaw, one more refinement. So when do you stop? Why is knowing when to stop as important a discipline as knowing how to improve?