Why your team keeps asking for one more iteration.

The PM walks in and says the design looks great, and asks if you can show the team five more variants. You spin them up in twenty minutes with Claude or v0 or whichever tool the team has standardised on this quarter. The next morning the EM swings by and asks if you can show what each of those would look like in dark mode, which puts you at twenty-five. By afternoon the founder pings to ask whether you can do one where the primary action sits in the rail instead of the hero, and that puts you at twenty-six.

You're producing rather than designing. The work is happening, and the decision isn't.

The pattern has a name worth using. I've started calling it the iteration spiral, the behaviour that emerges when AI drops the cost of generating design variants so far below the cost of choosing among them that the team's natural stopping rule breaks down entirely. Each new variant feels essentially free to produce, and the cumulative cost of having to choose between them all turns out to be anything but free.

The rest of this piece is about what the spiral actually is, why it's worse than it used to be, who's pulling the design loop in which direction, and the process moves that close the loop without slowing down the work that needs to ship.

What I mean by "the iteration spiral."

For the last twenty years, design teams have operated with an implicit stopping rule. You explore enough variants to feel confident that you've checked the option space, and then you converge on a direction. The number that counted as "enough" was always calibrated by cost. Five variants meant several days of designer time. Ten variants was a sprint. Twelve was a senior-design escalation. Asking for more had a price that was visible to everyone in the room, and the visibility kept the asking honest.

AI has effectively deleted that cost. Not reduced it, deleted it. Twenty variants now is twenty minutes of work, not twenty days. When one input to a system goes near-zero while every other input stays the same, the system breaks in predictable ways, and the first thing that breaks is the stopping rule that used to govern the loop.

The iteration spiral is the behaviour that follows. The team keeps asking because asking is now essentially free. The designer keeps producing because producing feels like progress and is visible in standup. Nobody decides because deciding is genuinely harder than ever, since the option set keeps growing every time someone leaves a comment in the Figma file. The loop never closes. Two weeks pass, the work hasn't shipped, and there are forty-three frames in the file.

It isn't anyone's fault, and pointing fingers misses the point. The PM isn't being unreasonable; they're behaving rationally given the new variant economics. The designer isn't being weak; they're trying to be a good partner. The economics shifted faster than the rituals around them did, and naming the spiral is the first move out of it.

Why AI makes this worse than it used to be.

The cost moved. The team's instincts haven't.

In the pre-AI version of design work, generating five variants was the bottleneck of the whole exercise. Choosing among them was the easy part, because by the time you had five real mocks you'd thought about the problem long enough that the answer often felt obvious. Production was the hard work, and selection was the relief.

In the post-AI version, the order has flipped. Generation is the easy part now. Variants flow out faster than the team can absorb them. Selection has quietly become the hard work, and most teams have no muscle for it because they never had to develop one. They're using a stopping rule that was calibrated for the old economics in a world where the rule no longer fits the work.

There's a UX law worth naming here, because most designers know it but rarely cite it explicitly in product conversations. [Hick's Law](https://www.nngroup.com/articles/hicks-law/) (William Hick, 1952) holds that decision time scales logarithmically with the number of options on offer. The intuition that more options means a harder decision is correct; the magnitude is what most people miss. Twelve variants don't make for a 12x harder choice. They make for roughly a 3.5x harder choice, which is still much harder than three, and the cost stacks across every round of design review you go through.

What that means in practice is that the second variant in any round is doing real work for the team. The third is doing some work. The seventh is doing almost no work and is actively making the decision worse. Past a small number, additional options stop being information and start being noise, and the team starts mistaking the noise for thoroughness.

That isn't a guideline or a rule of thumb. It's measured.

The stakeholder side. Why teams keep asking.

Three reasons, all rational, all wrong now.

It feels like rigour. "Let's see all the options before we commit," the saying goes. In the pre-AI version of design work, that was wisdom, because five variants meant the designer had genuinely explored the space and could speak to the trade-offs. In the post-AI version, the same sentence is avoidance dressed up in process clothing. Asking for more variants when generation is free isn't rigorous; it's a way to delay the decision without naming the delay out loud.

It feels like leverage. "You have AI, use it." PMs and execs new to the AI workflow often expect designers to ramp output linearly with the new tools, and they mean well by saying so. The trouble is that "use the leverage" should produce better decisions faster, not more variants slower. If your team is generating more design and shipping less of it, the leverage you actually have is being wasted on the production side instead of being reinvested in selection.

It defers a decision. This is the one I see most often in practice, and it's the hardest to call out because nobody is doing it consciously. As long as there's another variant in flight, no one in the room has to commit to anything. The spiral feels comfortable. The decisions don't. The team prefers the spiral and convinces itself that the spiral is craft.

Naming the deferral, in the room, is the senior move that breaks the loop. "I notice we keep generating instead of choosing. Are we trying to avoid a decision here?" The question lands harder than it sounds when you read it on the page. Half the time the room realises the answer is yes.

The designer side. Why we keep producing them.

Three more reasons, symmetric to the stakeholder side.

Producing feels like progress, and variants are visible work product. You can show them in standup. The PM nods. The Slack channel sees movement. Saying "I spent today thinking about whether we have the right three variants" doesn't have the same texture, even though that thinking is often the higher-leverage activity by some margin.

Saying no feels obstructionist. The team is moving fast and asking for more, so the designer who pushes back reads as a brake on the velocity. That reading gets worse when the request is "it's so easy now, just spin a few more up," because the defence (that easy generation isn't the actual bottleneck) requires explaining the new economics, which takes more energy than just hitting generate one more time.

We've been trained on the old craft. The equation that more options equals more thoroughness is wired into design school, into portfolio reviews, into the way most of us present our process to non-designers. Most senior designers who got senior in the pre-AI era built their intuitions in a world where generating more was the proof of seniority. The intuition is now exactly the trap.

The senior designer's job has flipped. It used to be about generating enough variants to prove you had explored the space. Now it's about generating less and deciding faster.

The fix. A process built for the new economics.

The only thing that closes an iteration loop reliably is a process that has a stopping rule baked into it from the start. Five moves I rely on.

Define the stopping rule before you generate. Written into the brief, not negotiated mid-project. "We'll explore three variants, then converge in a 90-minute lightning decision jam on Thursday." Pre-committing to the convergence point makes the variant count negotiable in a healthy way: if the team genuinely needs five, you get to discuss whether to add the round before generating, not after.

The three-variant rule. Three serious variants from genuinely different framings, not three colour palettes for the same layout. Three approaches that disagree about something fundamental, like the IA, the interaction model, or the relationship between AI and user. Generating beyond three rarely surfaces a new direction; it just refines existing ones. If round one of three doesn't surface a winner, you run round two with three new variants informed by what you learned in round one, rather than bolting eight more onto round one.

Use AI to generate, and design the choosing process by hand. Variants come out of AI in twenty minutes. The blind workshop, the comparative crit, the documented decision rationale: those stay human and they stay slow on purpose. The expensive part of the design loop has moved from production to selection, so let the inexpensive part be inexpensive and reinvest the saved time into making the decision well.

Time-box convergence. If a decision needs two days, give it two days on the calendar with no design work scheduled against the slot. Don't let "let me just generate one more" eat into the decision window, because it always wants to. The decision is the deliverable.

Make the rationale the artefact. The output of a design round isn't the variant chosen; it's the documented reasoning for choosing it. A short doc, three paragraphs, signed by product, engineering, and design. That artefact closes the loop in a way that "here's the next mock" never does, and it makes the next round faster because the new variants get briefed against rationale instead of against vibes.

A reference point from my own work. On the Walmart Content Quality Score project at Salsify, the PM and I disagreed on the solution. We could have spiraled, generated a dozen variants, lost a sprint, and ended up no closer to an answer than we started. Instead I mocked two flows, both fully fleshed, and we ran a workshop with stakeholders for blind feedback across both directions. Each had strong parts the other was missing, so we merged. Two well-scoped variants and a defined convergence ritual closed a decision that twelve variants and an open-ended Figma file would have left open indefinitely.

That was a pre-AI workflow, but it generalises directly to the AI era. The structure scales. The spiral kills decisions, and structured convergence saves them.

One more counterargument, resolved.

The argument I take seriously is this: but isn't more options sometimes the right move? Genuinely difficult problems sometimes do need real exploration.

That's true. Some problems warrant ten variants. The fix isn't to ban exploration; it's to make exploration a deliberate choice rather than a default behaviour. The way I think about it, three variants is the budget for any standard design round, and going beyond three is allowed, but it requires a written reason. "This is a category-defining surface and the option space is genuinely wide" is a reason. "It's easy to spin up more" is not.

A worked example of deliberate exploration done well: on the OneClick shift-management redesign, I ran twelve weeks of breadboard, then prototype, then real-data prototype, then ship. Four passes at four different fidelities, each one answering a different question. That isn't eight variants of the same fidelity churned out in a sprint; it's a staged progression where each round generates new information for the next round to use. The team gained roughly 18% market share over competitors in the period that followed. The structure is the difference.

That single sentence, "what's the reason for the next variant?", is the difference between exploration and the spiral. It's the question Hick's Law has been asking for seventy years. AI just made the question urgent.