I used to put a line in every proposal that read: includes up to three rounds of revisions. It sounded reasonable. It sounded like something a professional would write. It also caused more friction than almost any other sentence in my contracts, because nobody could agree on what a round actually was.
Was swapping a typeface a round? Was moving the hero image down forty pixels a round? One client in 2021, a logistics startup called Hauler, sent me eleven separate emails over two weeks, each with a single small request, and then was genuinely confused when I said we’d used up our three rounds. From where they sat, they’d never asked for a round. They’d just asked questions.
The problem with counting rounds
Rounds measure the wrong thing. They measure how often a client opens Figma and leaves a comment, not how much work that comment creates or how much it moves the project toward being finished. A round can be one tiny fix or forty structural changes, and the contract treats them identically.
What it does to the relationship
Once a client starts worrying about running out of rounds, they stop giving you honest feedback. They batch every concern into a single mega-email to avoid spending a round, which means you get vague, overloaded notes instead of the specific, timely ones that actually help. I noticed this pattern at Hauler, then again with a skincare brand, then again with a nonprofit redesigning their donation flow. The counting mechanism was training clients to communicate worse.
Switching to decisions
In early 2022 I rewrote the clause. Instead of three rounds, the contract now names a fixed number of open decisions per phase, usually five for a landing page, eight for a product redesign. A decision is something like: final hero layout, primary accent color, nav structure, button hierarchy, empty state tone. Once we agree on a decision, it’s closed. Reopening a closed decision costs extra, revisiting an open one doesn’t.
How I define a decision up front
Before kickoff I now send a one-page list titled Open Decisions for This Project. For a recent job with a furniture retailer called Birch & Co, it read: 1) category page density, 2) product card anatomy, 3) checkout step count, 4) use of customer photos, 5) mobile filter pattern, 6) typography pairing, 7) color of the add-to-cart button, 8) loading state style. Eight items, each one a real fork in the road, each one worth a conversation rather than a guess.
- Decisions are named in plain language, not design jargon
- Each decision gets closed with a written confirmation, usually a one-line Slack message
- Reopening costs a flat fee, agreed before the project starts
- Anything not on the list is assumed open until we name it
That last point matters more than it looks. It forces me to think through the whole project at the proposal stage instead of discovering scope mid-flight. It also gives the client a map. They can see exactly what’s still negotiable and what’s locked, instead of guessing whether their comment will eat into some invisible budget.
What changed in practice
The Birch & Co project closed in nineteen days with zero scope disputes, which had never happened to me before on a job that size. Partly that’s luck. Mostly it’s that the client knew, from day one, which eight things we needed to agree on, and stopped treating every small comment as a potential threat to the timeline.
Fewer emails, better ones
Feedback got shorter and more precise. Instead of a paragraph hedging around a concern, I’d get a direct note: on decision four, we’d rather not use customer photos, our brand guidelines say no lifestyle imagery. That’s a sentence I can act on immediately. The old system buried sentences like that inside three-page emails trying to cover every worry at once.
A client who knows exactly what’s still open will tell you the truth about it. A client who’s afraid of running out of rounds will tell you what they think won’t cost them anything.
Where it still gets complicated
Decisions can metastasize if you’re not careful. Early on I let category page density include six sub-questions, which made it feel less like one decision and more like a hidden round in disguise. Now I cap each decision at a single, answerable question. If a decision splits into three real questions, it becomes three decisions, and I say so before the client ever notices the slippage.
New work versus revisited work
The other complication is distinguishing a genuinely new decision from one that was always implicit. When the Birch & Co team asked, late in the project, about the color of error messages, I had to decide whether that was new scope or something we should have named on day one. I now keep a running addendum for exactly this, dated and shared openly, so nobody has to rely on memory about what was promised.
None of this makes scope disagreements disappear completely. Clients still sometimes want to reopen something we closed, and that’s fine, that’s what the reopening fee is for. But the fights about what counts as a round are gone, because there’s no round anymore, just a short list of named decisions that either stay open or get closed, one at a time, in daylight.
