011 min
Why Iterative Design starts from a draft that will be wrong
A home computer with a modem could let bank customers check their accounts and move money without visiting a branch. A prototype of such a system was built for Danish bank customers, and the usability researcher Jakob Nielsen reported on it in a 1993 paper. The designers sorted the commands into three menus named Functions, Accounts and Information.
The grouping looked reasonable to the team. Then test users tried it. Testers could not tell which of the three menus held a command, so they opened all three every time they wanted to use one.
The team had not expected this. It appeared only when people used the prototype. What people say they will do can differ from what they do, so the testers were given tasks to carry out instead of being asked what they liked.
That is the situation iterative design answers. The rest of this article follows the same prototype through five versions to show how the method behaves, where it helps, and where it stops helping.
022 min
How Iterative Design works
The method has four moves. Designers finish a version of the design. They watch several people use it and write down each problem those people have. They change the design to remove those problems. Then they test the changed version, to confirm that the fixes worked and to find any new problems the changes caused.
A team usually adds steps around that core. Before the first version, it defines the problem and the goal, studies the users, and looks at competing products. It then brainstorms ideas, often as quick sketches, and picks one to build. After each test, the team reviews the results with stakeholders, meaning the people who pay for the product or depend on it, and decides what to change next. Showing every version to stakeholders also keeps them informed of progress.
Start rough and cheap
Early versions can be low-fidelity, which means they look and work much less like the finished product. A designer might sketch screens on paper and have a person play the computer by swapping the sheets, a technique called paper prototyping. Later versions become high-fidelity: they look and respond almost like the real thing. Cheap early versions let a team afford many rounds. They also let a team learn early whether the product matches what people want, before it pays for the full build.
Each round can use five test users or fewer, since later rounds will test again and catch what this one missed. Feedback does not have to come only from usability tests. Teams also use interviews, usage data from the released product, and A/B tests, which show two variants to different groups of people and compare the results. A usability test shows why people struggle. Usage data shows where.
A fix can create a new problem
The second version of the banking prototype had two menus, Accounts and Other, instead of three. In the second version, testers had fewer problems finding commands and made fewer errors. That did not make the design finished. A fix can introduce a new problem of its own, so the third version had to be tested like the first.
Nielsen's advice follows from this: do not stop after the first redesign. The home-banking team changed the help system twice, in versions 3 and 5, after tests showed what was still wrong.
031 min
Where Iterative Design comes from
The method is older than most design tools. In software it goes back to the 1950s, and NASA's Project Mercury used very short iterations of half a day, each with a fixed length, in the early 1960s. Craig Larman and Victor Basili document both in a 2003 history.
For user interfaces, the case was made in 1985 by John Gould and Clayton Lewis. They named three principles of system design: focus on users from the start and throughout, measure how people actually use the system, and change and retest the system again and again. The three depend on each other. Measurement finds the problems, and iteration is what fixes them.
The waterfall misreading
Many accounts say that software was once built in a single pass, from requirements to design to code to test, and they credit Winston Royce's 1970 paper with the idea. Larman and Basili say this reading of Royce is wrong. Royce recommended doing the work twice, so that the version delivered to the customer was in effect the second one. Most descriptions of his model leave that step out.
041 min
How much Iterative Design improves a design
How much does repeating the cycle help? Nielsen measured it. Nielsen's 1993 study measured gains of 38 percent per iteration. It covered four projects, and the gain varied a lot from one project to another. Nielsen Norman Group describes a website project in which the measure the team targeted rose 233 percent over six iterations, which is about 22 percent per iteration.
How much the gain varies
The size of the gain depends on the design. In a 1996 test of four designs, Nielsen and Jan Maurits Faber measured gains from one iteration of 12 to 29 percent, averaging 18 percent. Each figure comes from different interfaces, so neither is a promise for yours.
Why one round is not enough
A common mistake is to treat one redesign as the finish. Gould and Lewis asked system designers to describe their process, and among those who mentioned iteration, many seemed to think that one round of revision was enough. Nielsen Norman Group recommends at least two iterations, which means three versions: the first draft and two redesigns.
052 min
Where Iterative Design goes wrong
Gains get smaller as rounds pass. Later rounds have less to fix, so each one usually gains less than the one before. This is the same pattern as diminishing returns anywhere else, and the method gives no signal for when to stop.
A team without a stop rule makes familiar mistakes. It keeps refining after the gains are too small to matter, which costs money and delays the launch. It changes many things in one version and cannot tell which change helped. It skips real users and tests on colleagues instead. The method also fits badly with a client contract that fixes the deliverables and the date in advance, since nobody knows beforehand how many rounds the design needs.
Fixation on one design
Iteration has a built-in bias. Each round improves the design the team already has, so the team has little reason to ask whether another design would be better. Iteration can also lead to fixation, which means refining one option again and again without looking at others.
An experiment: one design at a time, or several
Steven Dow and five colleagues at Stanford tested this in 2010. Thirty-three novice designers made banner advertisements for a magazine. In the serial condition, each person made five ads one after another and received feedback on each ad before making the next. In the parallel condition, each person made three ads and got feedback, then made two more and got feedback again. Everyone then made a final ad.
The final ads ran as a real campaign on a social network. In the Stanford experiment, the final ads from the parallel group outperformed those from the serial group, and independent raters found the parallel group's drafts more varied. Both groups made the same number of drafts and received the same amount of feedback. Only the order differed.
Local maximum: a good design in the wrong place
A second limit has been known for longer. Improving one design in small steps finds the best version of that design. It cannot find a better design that lies somewhere else. Critics call this hill-climbing: the team reaches a local maximum, a design that no small change can improve, and never finds a better one in a different design space. Nielsen Norman Group accepts the critique, and it adds that most interface projects use established patterns, where polishing gives a high return. Its suggested remedy is to make several rough alternatives first, in what is called parallel prototyping, and then iterate on the best.
061 min
Iterative Design vs. nearby concepts
Three neighbours cause most of the confusion.
| Approach | How the work is ordered | When users see the product |
|---|---|---|
| Waterfall | Each phase is finished before the next one starts | Late, after the earlier phases are done |
| Incremental development | The product is built part by part | The method does not require it |
| Iterative design | The same design is tested and revised in rounds | In every round |
A team can build incrementally without ever testing and revising a part, so incremental is not the same as iterative. The waterfall in this table is the version that textbooks describe, which differs from what Royce wrote.
Iteration is also a feature of larger methods. Agile software development, lean UX and design sprints all rely on it, and design thinking uses it as one of its steps. Iterative design is the part of these methods that tests a design with users and revises it.
Comparing two finished options is a different job. A comparison test measures which option is better. Iteration looks for the problems in one option and removes them, and it can start again from the result.
072 min
Running Iterative Design on a team
Four decisions separate a method that works from a habit of changing things at random.
- Write the goal as something a test can show, such as the share of testers who finish a money transfer without help.
- Fix the number of rounds the schedule allows before the first test, and plan for at least two.
- Change a few things per round, so that a result can be traced to a change.
- Keep every version together with what its test found. Shared design tools keep a version history and let teammates comment on a version, which helps the team see what changed and why.
Before the first test, also decide when the team will stop. A good stop rule is that the goal is met in a test, or that the gain from the last round is small next to what the round cost. Without that rule, the next round always looks worth doing.
Each role on the team has a part. A designer prepares the version and the tasks that testers will carry out. A researcher, or the designer, runs the sessions and records what testers do and say. A product manager checks that the changes stay within the goal. An engineer says early how costly each change would be, so that the cheap fixes are made first and the costly ones are weighed against what they would gain.
081 min
Frequently asked questions
How many test users does each round need?
Five or fewer is usually enough for a round, because later rounds test again and catch what this one missed. Nielsen Norman Group suggests paper prototypes for early versions, at about a day per round.
Does iterative design take more time than planning everything first?
It adds testing rounds, but it can save time overall, because problems are found while changes are still cheap. The cost grows when the team has no rule for when to stop.
Can iterative design be used outside software?
Yes. Any product that can be tested in versions suits it. Engineers use it on machines, and circuit designers build a circuit on a breadboard, a plug-in board for trying out parts, before making the final one.
What is the difference between a prototype and an iteration?
A prototype is one test version of a design. An iteration is one pass through the cycle: change a version, test it, and note what to fix. A design usually goes through several iterations.
?4 questions
Questions people ask
How many test users does each round need?
Does iterative design take more time than planning everything first?
Can iterative design be used outside software?
What is the difference between a prototype and an iteration?
§6 sources
Sources
Nielsen, J. (1993). Iterative user-interface design. IEEE Computer 26(11).
Nielsen Norman Group (2024, updated from Nielsen, 2011). Design processes for high usability: iterative design, parallel design, and competitive testing.
Nielsen, J. and Faber, J. M. (1996). Parallel design and testing. Nielsen Norman Group.
Larman, C. and Basili, V. R. (2003). Iterative and incremental development: a brief history. Computer 36(6).
Show all 6 sourcesShow fewer sources
Gould, J. D. and Lewis, C. (1985). Designing for usability: key principles and what designers think. Communications of the ACM 28(3).
Dow, S. P., Glassco, A., Kass, J., Schwarz, M., Schwartz, D. L. and 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).
