By the end of the lesson, you understand that iteration is not building in every suggestion of the testers. You can compare alternatives, make trade-offs visible, and check the changes with new evidence.
Why a cycle, and not a one-off fix?
Design is rarely linear: research, design, test, done. In reality the test opens new questions, the fix can cause new side effects, and the new version requires a new test. The cyclical approach accepts this, and organizes the work so that each round reduces part of the uncertainty.
The cycle of iteration
Iterative design is a method in which the design develops in repeating rounds, on the basis of evidence. An iteration cycle is a repeating series of observation, hypothesis, change, and check. Validation is checking whether the change caused the expected effect.
flowchart TD
A["Finding"] --> B["Hypothesis"]
B --> C["Modification"]
C --> D["Retest"]
D --> E["Comparison with the<br>success criterion"]
E -->|"not met"| B
E -->|"met"| F["Next question"]
The participant's suggestion is not a specification
Do not treat the participant's suggestion as a finished specification. If someone says "there should be a bigger button", ask what uncertainty or difficulty it would solve. Maybe the size of the button is the issue, maybe its label, its place, or that they do not know when it can be used. You can make several alternatives, then examine them in the task (this is sometimes called a simple A/B comparison, but remember: on a sample of two or three people it only indicates a direction).
Ask toward the cause: What did you want to achieve with this? What happened when you were looking for this? What would have been better from your point of view? These questions uncover the need behind the suggestion (as we saw in chapter 4 at the request–goal–need ladder).
Trade-offs
Every decision can have a side effect. More explanation can make a condition more understandable, but can crowd the mobile view. An earlier confirmation can reduce errors, but can slow the frequent user. A trade-off is not a failure; it is dangerous if it stays hidden or is not tied to the consequence of the task.
Record between which values you are choosing:
comprehensibility,
speed,
accessibility,
safety,
feasibility,
cost.
"It didn't fit" is not a full justification. Rather: "On mobile the short summary stays visible, the detailed condition can be opened, because in the test the basic information was needed for the decision; we will check the findability of the details in the next round."
A simple comparison table helps:
Alternative
Comprehensibility
Speed
Accessibility
Cost
Decision
A: pop-up confirmation
+
–
~
~
Rejected (slows the frequent user)
B: persistent status bar
+
+
+
~
Chosen
C: detailed help page
~
–
+
–
Later
Back to the research
If during iteration it turns out that we misunderstood the user goal or situation, it is not enough to draw a new button. You have to return to the research question. It may be that the user does not use a filter not because it is in the wrong place, but because they choose based on other information. The iterative process is not linear; the test can take you back to the formulation of the problem too. This is not a failure, but a natural part of the process.
When is it enough? The rule of stopping
Iteration has no natural end, so you have to state in advance when you stop:
the success criterion has been met on the examined sample,
the remaining problems are of low severity,
time or the frame has run out, and you document the rest among the "next steps".
Worked example: the "Accessibility" filter of Mai program
Participants do not use the "Accessibility" filter. First suggestion: move the filter forward. From the interviews, however, it turns out that they do not understand the term, and rather ask concrete questions: is there a staircase, is the restroom accessible, is it reachable by public transport. The better iteration is not mere rearrangement: it is a review of the label and the information model (concrete icons and answers on the card, simple yes/no signals instead of a filter).
Common misconceptions
Claim
Clarification
"Iteration means that I build in the feedback."
Feedback is evidence, not specification; understanding the cause is the essence of iteration.
"If it does not get worse after a fix, it worked."
Only the check shows whether the expected effect was achieved.
"A trade-off is a failure of design."
Stating the trade-off is a mark of the quality of design.
In brief
Iteration is a cycle: finding → hypothesis → change → check; the second and fourth steps are the most important.
Behind the participant's suggestion we look for the need.
We name the trade-off: comprehensibility, speed, accessibility, safety, feasibility, cost.
We fix in advance when we stop.
Review questions
For which finding could you make two different solution hypotheses?
Between what values is there a trade-off in your project?
Which change should be retested, not just accepted?
When would you say that iteration is enough in your project?
Improvement cycles and trade-offs
Objectives
By the end of the lesson, you understand that iteration is not building in every suggestion of the testers. You can compare alternatives, make trade-offs visible, and check the changes with new evidence.
Why a cycle, and not a one-off fix?
Design is rarely linear: research, design, test, done. In reality the test opens new questions, the fix can cause new side effects, and the new version requires a new test. The cyclical approach accepts this, and organizes the work so that each round reduces part of the uncertainty.
The cycle of iteration
Iterative design is a method in which the design develops in repeating rounds, on the basis of evidence. An iteration cycle is a repeating series of observation, hypothesis, change, and check. Validation is checking whether the change caused the expected effect.
flowchart TD A["Finding"] --> B["Hypothesis"] B --> C["Modification"] C --> D["Retest"] D --> E["Comparison with the<br>success criterion"] E -->|"not met"| B E -->|"met"| F["Next question"]The participant's suggestion is not a specification
Do not treat the participant's suggestion as a finished specification. If someone says "there should be a bigger button", ask what uncertainty or difficulty it would solve. Maybe the size of the button is the issue, maybe its label, its place, or that they do not know when it can be used. You can make several alternatives, then examine them in the task (this is sometimes called a simple A/B comparison, but remember: on a sample of two or three people it only indicates a direction).
Ask toward the cause: What did you want to achieve with this? What happened when you were looking for this? What would have been better from your point of view? These questions uncover the need behind the suggestion (as we saw in chapter 4 at the request–goal–need ladder).
Trade-offs
Every decision can have a side effect. More explanation can make a condition more understandable, but can crowd the mobile view. An earlier confirmation can reduce errors, but can slow the frequent user. A trade-off is not a failure; it is dangerous if it stays hidden or is not tied to the consequence of the task.
Record between which values you are choosing:
"It didn't fit" is not a full justification. Rather: "On mobile the short summary stays visible, the detailed condition can be opened, because in the test the basic information was needed for the decision; we will check the findability of the details in the next round."
A simple comparison table helps:
Back to the research
If during iteration it turns out that we misunderstood the user goal or situation, it is not enough to draw a new button. You have to return to the research question. It may be that the user does not use a filter not because it is in the wrong place, but because they choose based on other information. The iterative process is not linear; the test can take you back to the formulation of the problem too. This is not a failure, but a natural part of the process.
When is it enough? The rule of stopping
Iteration has no natural end, so you have to state in advance when you stop:
Worked example: the "Accessibility" filter of Mai program
Participants do not use the "Accessibility" filter. First suggestion: move the filter forward. From the interviews, however, it turns out that they do not understand the term, and rather ask concrete questions: is there a staircase, is the restroom accessible, is it reachable by public transport. The better iteration is not mere rearrangement: it is a review of the label and the information model (concrete icons and answers on the card, simple yes/no signals instead of a filter).
Common misconceptions
In brief
Review questions