There is a point in some projects where you realise you are no longer improving the work. You are just changing it.
That is not the same thing.
I am very pro-iteration. Most good things I have worked on got better because the first version exposed something we had not understood yet. You make the thing, look at it properly, discover what is wrong, learn something and make the next version with that new information in your head.
That is healthy revision.
The infinite revision machine looks similar at first. Somebody asks for something. You listen, ask questions and make a first version. They do not like it. Fair enough. Maybe I misunderstood the brief. Maybe the brief was not clear. Maybe everybody genuinely needed to see something real before they could decide what they meant.
So you revise it.
They do not like that either.
Then the pattern starts. Part of version one comes back. A new direction appears. Somebody else joins the conversation. Another person has seen something on Instagram. One comment says the work needs to be bolder, another says it needs to be more restrained, and a third person wants it to feel more premium without being able to explain what premium would actually change.
Nothing there is automatically unreasonable. Projects change. People change their minds. New information appears.
The problem begins when nobody can explain why the next version should be better than the previous one.
Iteration needs something to iterate towards.
Without that, you can move forever.
My first assumption is normally that I got it wrong
When this happens, my first instinct is not to blame the client.
It is usually the opposite.
Where did I go wrong? What did I miss? What should I have asked? What can I change to get this back on track?
That instinct is useful. If somebody is paying me and they are unhappy with the work, I should examine my own part in that before I announce that everyone else is confused.
The danger is staying in that mode after the evidence has changed.
If the target itself is moving, working harder does not necessarily move you closer to it. You can produce more versions, refine more details and spend more hours while becoming progressively less certain what anybody is actually trying to achieve.
That is one of the most frustrating project states I know because the normal relationship between effort and progress breaks down. More work stops creating more certainty.
Sometimes it creates the opposite.
What new information changed the decision?
Revision is not indecision.
A new version may be completely justified because something real happened. Users struggled with the first one. A technical constraint emerged. The budget changed. A stakeholder finally explained an important requirement. Something that sounded good in a meeting turned out to be awkward in real use.
Fine. Change it.
The useful question is: what did we learn that makes this version necessary?
If version two exists because version one exposed a real usability problem, the project has moved forward. If version three exists because testing showed that people misunderstood version two, we have moved forward again.
If version four exists because one person prefers version one, another likes version two, somebody else thinks the whole thing should feel more premium, and no one can say what the project is currently optimising for, we have a different problem.
At that point the work becomes a referendum with no constitution.
Everybody has an opinion. Nobody knows what wins.
Cheap options make the machine easier to feed
Modern tools make the infinite revision machine incredibly easy to feed.
I can generate alternatives very quickly now. So can clients. AI can produce another layout, another headline set, another technical approach, another image direction or another complete version almost instantly.
That is brilliant when you know what you are testing.
If I want three different information architectures because I am trying to understand which one makes a task clearer, useful. If I want several headline directions because we are testing tone, useful. If I deliberately produce a radically different design to challenge an assumption everyone has been making, also useful.
But cheap alternatives create a temptation: perhaps the right answer is hiding in the next batch.
Sometimes it is.
Quite often the real problem is that nobody has agreed what the answer needs to do.
Twenty more versions do not solve that. They provide twenty more objects to disagree about.
This is one of the strange consequences of AI making production cheaper. The bottleneck moves from making options to judging them. When almost every direction is available, somebody still has to decide which direction matters.
Three rounds is not magic. The boundary is the point.
For a lot of client work I define revision rounds before the work starts. Three is common for me.
There is nothing sacred about three. I am not claiming that every project can be made correct by the third set of comments, after which all human thought must cease.
The purpose of the boundary is to make revision part of a decision process rather than an indefinitely renewable resource.
If everybody knows there are defined rounds, feedback becomes more deliberate. Comments get consolidated. Contradictions are more likely to be spotted before they are handed to the person doing the work. People have to distinguish between I personally prefer this and this fails the thing we agreed it needed to do.
The question changes from what else could we try? to what specifically are we trying to improve?
That is a much more productive conversation.
Checkpoints stop history being rewritten
I also prefer smaller decisions to one enormous reveal at the end.
Agree the broad structure. Agree the direction. Then refine the detail.
Real projects rarely behave as neatly as that sentence suggests, but the principle matters. A checkpoint creates a recorded moment where everybody says: yes, this is the basis on which we are continuing.
That becomes surprisingly important later.
Without checkpoints, project history is incredibly easy to rewrite. A request becomes a suggestion. A sign-off turns into I was never really sure. A direction everybody discussed and accepted somehow becomes something the designer or developer invented alone in a small locked room.
If the foundation genuinely needs to change, fine. Go back and change it deliberately. What I want to avoid is dismantling everything above it because nobody can remember which decisions were actually made.
Sometimes the professional answer is to stop producing
This took me longer to learn than it should have.
When a project gets stuck, my instinct is to make something. Another version, another solution, another attempt to make the uncertainty disappear through better execution.
But not every project problem is a production problem.
If two contradictory directions are competing and nobody can explain the criteria for choosing between them, the useful thing may be to close the laptop and have the decision conversation first.
What are we actually trying to achieve? Which audience matters most? What is non-negotiable? Whose decision is final? What evidence would make one option better than another?
If those questions cannot be answered, version seventeen is unlikely to perform a miracle.
It may simply become source material for version eighteen.
The revision contract I wish more projects started with
I have gradually ended up with three things I want clear before subjective work gets deep enough to become expensive.
How many revision rounds are included? Not because the number is holy, but because unlimited revision is not a process.
What are we using to judge the work? Audience, objective, constraints, evidence, technical requirements — whatever actually matters for that project.
Who makes the final call when feedback conflicts? A project with six stakeholders and no decision owner does not have six times the wisdom. It has a queue.
That little contract will not stop people changing their minds. Nor should it. What it does is give change a structure. If the criteria change, everybody can say so. If the brief changes, the project can acknowledge that. If the decision-maker changes direction, at least the decision has an owner.
The aim is not to prevent revision. It is to stop revision becoming invisible scope, invisible indecision and invisible history rewriting all at once.
Good iteration narrows uncertainty
That is probably the simplest test I know.
A useful revision teaches you something. It may prove the brief was wrong. It may expose a usability problem. It may kill an idea you were emotionally attached to. It may reveal that the thing everybody said they did not want was, in fact, the thing that worked best.
Fine.
But the project should know more after the revision than it knew before.
The infinite revision machine does the opposite. Each pass creates more branches, more opinions and less confidence about why anything looks or behaves the way it does. The work gets busier without getting better.
This is not a clever way of saying clients are wrong and professionals are right. Professionals can be spectacularly wrong. I certainly have been. Sometimes a client keeps rejecting the work because the work is simply not good enough.
The useful question is not who is right?
It is what are we using to decide?
I still like revision. I still expect the first answer to be provisional. I still assume that making something will reveal things the brief could not.
I just want every new version to have a job.
Otherwise we are not iterating.
We are operating machinery.
And if nobody switches it off, the machine will run forever.