Iteration

In the late 1970s, the British designer James Dyson got annoyed with his vacuum cleaner. Like most machines of the time, it collected dust in a bag, and the tiny pores of the bag clogged quickly, so the cleaner lost suction long before the bag was full. Dyson had seen industrial cyclones, the tall cone-shaped towers used in places like sawmills to spin dust out of the air without any filter at all. He wondered whether a tiny cyclone could do the same job inside a vacuum cleaner. So, working in the coach house behind his home near Bath, he started building one out of cardboard and tape.

It didn't work very well. So he built another, and another. By his own count, over about five years from 1979, he made 5,127 prototypes before he had a design he was happy with. He has often joked that this means 5,126 failures. Even then, no British manufacturer wanted it. The first cleaner based on the design, the G-Force, went on sale in Japan in 1986, and the first vacuum sold under his own name, the DC01, only appeared in Britain in 1993.

The number is so large that it sounds like stubbornness, and there was certainly some of that. But each of those prototypes was a small experiment. Dyson has described changing one thing at a time, the angle of an inlet, the size of a cone, the shape of a chamber, testing it, and keeping whatever made it better. The final design wasn't invented in a flash of genius. It was found, step by step, by making something, seeing what it did and making it again.

That process has a name in design: iteration. It means improving something through repeated cycles of making, testing, learning and changing. In the post on mood boards, I wrote about setting a visual direction for a project. Iteration is what happens next, when that direction meets reality and has to be shaped, again and again, until it actually works.

Iteration comes from the Latin iterum, meaning "again", but repetition alone isn't iteration. Redrawing the same poster ten times without changing your mind isn't iterating. The point of each cycle is to learn something, and to let that lesson change the next version. That's why most descriptions of iterative work look like a circle with four stops on it: make something, put it in front of reality, look honestly at what happened, and decide what to change.

The idea has a long history outside design. In the 1920s and 30s, the American statistician Walter Shewhart described a cycle for improving manufacturing, which his colleague W. Edwards Deming later taught widely as Plan, Do, Study, Act. Deming insisted on "study" rather than "check", because the point was to understand the result, not just tick it off. In the late 1980s, the software engineer Barry Boehm proposed a spiral model for building software, in which a project circles round and round through planning, building and evaluation, growing a little with every turn. In 2001, a group of seventeen software developers meeting in Snowbird, Utah wrote the Agile Manifesto, which pushed software teams to deliver working pieces early and often rather than spending years on a plan. And in 2011, Eric Ries's book The Lean Startup gave the same loop a business name, build, measure, learn.

Designers have always worked this way, even when nobody drew the circle. A potter adjusts the wall of a pot after every firing. An illustrator redraws a character until the pose feels right. In the post on sketching as thinking, I wrote about drawing to find an idea rather than to show one. Iteration is the same habit stretched over weeks or months, with real tests between each version instead of a quick glance at the page.

One useful distinction is between iterating and polishing. Polishing makes a chosen design more refined. Iterating can change the design itself. Early in a project, each loop should be cheap and rough, a paper sketch, a cardboard model, a clickable mock-up, because you're still finding out what the thing should be. Later, the loops get tighter and the changes smaller. Matching the effort of each version to the question you're asking is most of the skill.

One of the clearest demonstrations of why iteration works is a small game called the Marshmallow Challenge, devised by the designer Peter Skillman and made famous by Tom Wujec in a 2010 TED talk. Teams of four get eighteen minutes, twenty sticks of dry spaghetti, a metre or so of tape, the same of string and one marshmallow. The goal is to build the tallest free-standing tower with the marshmallow on top.

Wujec reported that recent business school graduates were among the worst performers, while children who had just finished kindergarten did surprisingly well. The reason was the way each group worked. The graduates tended to discuss, plan carefully and build one tall structure, putting the marshmallow on top in the final seconds. Very often the tower buckled under its weight and there was no time left to recover. The children skipped the planning and started building straight away, putting the marshmallow on early and rebuilding each time something toppled. They ran many small loops instead of one big one, and each collapse taught them something. Architects and engineers did best of all, because they combined iteration with real knowledge of structures, which is a useful reminder that iteration works best alongside skill, not instead of it.

Research on interfaces points the same way. In a 1993 paper, the usability researcher Jakob Nielsen looked at several projects that had redesigned their interfaces over a number of rounds, testing with users each time. Usability improved substantially with nearly every round, and Nielsen recommended at least two or three iterations for any interface. The first version of almost anything has problems its designers can't see, simply because they know too much about how it's meant to work. Testing exposes them. Redesigning fixes some and reveals others. A few rounds later, the thing is far better than any amount of extra planning could have made the first version.

One of the most dramatic recent examples of iteration comes from India's space programme. In September 2019, the Vikram lander of the Indian Space Research Organisation's Chandrayaan-2 mission lost control during its final descent and crashed on the Moon. It was a painful public failure, watched live by millions of people. Rather than starting from scratch, ISRO studied what had gone wrong and built the next mission on that knowledge.

ISRO's chairman, S. Somanath, described the approach for Chandrayaan-3 as a failure-based design. Instead of designing for everything to go right, the team asked what could go wrong and made the lander able to survive it. According to ISRO's public accounts, the lander's legs were strengthened to cope with a harder touchdown, it carried more fuel, it had more solar panels, and the target landing area was made much larger so that the lander could find a safe spot even if it drifted off course. The mission was tested heavily on the ground before launch. On 23 August 2023, Chandrayaan-3's lander touched down safely near the Moon's south pole, the first spacecraft to land in that region.

It's worth being clear about what kind of iteration this is. A Moon mission can't run five thousand loops. Each cycle takes years and enormous amounts of money, so most of the iterating has to happen inside simulations, models and tests on Earth, and the big real-world loop happens only a few times. That's true of a lot of design work too, from buildings to medical devices, where you can't simply launch and see. The lesson is to find the cheapest possible way to fail first, in a test, a model or a prototype, so that the expensive version has already learned from those failures.

Digital products are the easiest things in the world to iterate. A team can change a screen today, release it to a slice of users tomorrow and see the results by the weekend. A/B testing, where two versions of a page are shown to different groups and their behaviour compared, has made that loop fast and measurable. Design systems are iterative too. Components are released in versions, improved as teams use them and quietly updated across a whole product.

But fast loops have a famous downside. In 2009, Doug Bowman, then the visual design lead at Google, left the company and wrote a blog post explaining why. One of his examples was a team that couldn't decide between two shades of blue, so they tested forty-one shades between them to see which one people clicked most. He also described having to defend a choice between a three, four or five pixel border with data. His frustration wasn't with testing itself. It was with a culture where every small visual decision had to be settled by measurement, leaving little room for design judgement.

There's a deeper limit too. In a 2014 paper, Don Norman and Roberto Verganti pointed out that iterative, user-tested design is very good at climbing a hill, making an existing idea steadily better, but it can't tell you whether you're on the right hill. Small improvements to a bagged vacuum cleaner would never have led to a cyclone. Getting to a different and higher hill needs a different kind of thinking, the opening-up of options I wrote about in the post on divergent and convergent thinking, before the loops begin.

AI tools make this easy to forget. You can now generate twenty versions of a screen, an image or a paragraph in a minute, which feels like iteration but often isn't. Iteration needs a question, a test and a lesson. Without them, you're just producing variations and picking the one you like, and nothing is learned for the next round. The habit that makes fast tools useful is a slow one: before each new version, write down in a sentence what you're trying to fix, and afterwards, what you found.

The main thing I'd take from this post is that iteration isn't a sign that your first idea was bad. It's how almost every good design gets made. First versions are guesses, and the quickest route to a good design is usually to make that guess cheaply, put it in front of reality and let reality tell you what's wrong. The skill is in keeping each loop small, asking a clear question each time, and being honest about the answer, especially when it isn't the one you hoped for.

If you want to try it, pick something small that you can test with real people this week: a sign for your front door, a poster, a menu for a family dinner or one screen of an app you're designing. Make a quick first version and show it to two people without explaining it. Watch where they hesitate or misunderstand, and write down one thing to change. Make version two, changing only that, and test again. Do at least five rounds, and keep every version in a row on a table or a page so that you can see the path. The final one will be better, but the row of versions will teach you even more. In the next post, on critique, I'll write about the other half of this loop, how to give and receive feedback that actually helps.

Dyson's 5,126 failed prototypes sound like a story about persistence, and they are. But they're also a story about learning. Each failure was a small, specific answer to a small, specific question, and the five thousand and twenty-seventh prototype was simply the place where all those answers met.

Further reading: James Dyson, Against the Odds (1997) · Jakob Nielsen, "Iterative User-Interface Design" (1993) · Don Norman and Roberto Verganti, "Incremental and Radical Innovation: Design Research vs. Technology and Meaning Change" (2014) · Eric Ries, The Lean Startup (2011) · Tom Wujec, "Build a Tower, Build a Team", TED talk (2010)