Use iteration to resolve a specific design question
Plan a revision cycle for a workshop-booking review page by identifying uncertainty, changing a reasoned variable, examining the result, and keeping evidence separate from assumptions and cosmetic churn.
Give the next version a learning purpose
Iteration means revisiting a design in response to what you learn. It is most useful when each cycle addresses a specific uncertainty rather than simply producing another visual version. A workshop-booking review page might need clearer commitment language, better session comparison, or a more reliable correction route. Choose the question before making the revision.
Record the reason for the proposed change
Record the current issue, supporting evidence or assumption, proposed change, and what you need to examine afterward. Keep related behavior consistent where possible so the effect of the change remains interpretable. Sometimes several elements must change together; explain that relationship rather than pretending every design question can be isolated into one tiny variable. Prepare the work so that another person can inspect its reasoning without a live presentation. Use concrete examples, readable labels, and links to supporting material where appropriate. Avoid relying on a dense board whose meaning exists only in the facilitator's memory. The point is not to document every conversation; it is to preserve the context and distinctions that matter when somebody acts on the output later.
Revise a booking review page
Create two versions of a booking review page. In the second, move the session details beside the final action and clarify whether submission reserves the place. Walk through a correction task and plan a participant task to examine comprehension. Label your own walkthrough as a preliminary check, not as evidence that the revision improved outcomes. Use a small worked example to examine the mechanics of the method. Keep invented material clearly labeled and separate from any real research evidence. The example should expose decisions about wording, grouping, order, or responsibility that would otherwise remain implicit. Where the activity requires a fact you do not have, leave a question rather than manufacturing a convenient answer to complete the diagram or make the exercise look finished.
Avoid changing every condition at once
If each cycle changes the research question, content, and task simultaneously, interpretation becomes difficult. If the team keeps polishing despite an unresolved service rule, pause and resolve the dependency. If a revision creates a new failure state, include that state in the next review rather than declaring success from the original screenshot alone. Watch for a convenient example becoming the only situation the team considers. Add a case with a different starting condition, incomplete information, or an interruption, then inspect which assumptions no longer hold. Do not invent research findings to justify the additional case. Use it as a deliberate challenge to the working model and identify the real evidence or expertise needed to assess whether the concern matters.
Keep a short account of each cycle
Review each cycle with a short record of what changed, what was observed, what remains uncertain, and the next decision. Retain useful alternatives without treating the number of versions as a measure of progress. Iteration should move the team toward a better-supported design and a clearer understanding of its limits, with enough documentation that another person can follow the reasoning.
Worked decision
Move session details beside the final action to examine verification. Keep the task consistent and record what the revised prototype can actually demonstrate.
References & further reading
Examples and exercises in this guide are original teaching scenarios.
