How Many Design Revisions Do You Need? A Decision Guide
Use revision rounds to solve named user, content, brand, access, technical, legal, or production problems. Not to chase a fixed count, group taste, or unsupported agency rule.

More design rounds do not always make work worse, and a third version is not always better than a tenth. A late round may fix a serious user, access, legal, content, print, or technical fault. Revisions become wasteful when the team cannot name the problem, evidence, owner, or pass rule.
A Revision Is Useful When It Solves a Named Problem
The message is false, unclear, missing, or in the wrong order.
A user cannot find, read, understand, or complete the task.
The work breaks a brand, access, legal, or platform rule.
The design fails on a real device, size, language, or file type.
A key owner has sound new facts that change the brief.
A test shows a clear fault and the change targets that cause.
Start With a Review Brief
State the audience, task, message, proof, content, channels, sizes, constraints, required items, access needs, owner, approvers, budget, dates, and pass rules. Mark what is fixed and what may change. A clear brief does not remove discovery; it gives the team a shared point from which to learn.
Give Each Reviewer a Role
One person should own the final product decision. Other reviewers may own facts, brand, users, access, law, tech, print, or local use. Ask each reviewer to flag issues in their area and explain the user or business risk. Do not turn every personal preference into an equal design command.
Sort Feedback Before Editing
Fact or content fault: correct the source and the design.
User-task fault: show the test or path that failed.
Rule fault: name the rule, market, owner, and needed fix.
Production fault: show the device, size, file, or process issue.
New scope: price and plan it apart from a correction.
Taste: note it, but do not present it as proof of harm.
Use Prototypes and Small Tests
Test the riskiest idea before polishing all screens or files. A rough flow may answer a task question. A content draft may expose a weak claim. A print proof may show a color or size fault. A coded sample may show a device issue. Match the test to the question and do not treat preference as task success.
Keep a Decision Log
Record the issue, source, decision, owner, date, version, change, and result. Group feedback into one clear round where possible. Resolve conflicts before the designer makes two opposite changes. A log helps a new reviewer understand why a choice exists and keeps an old request from returning without new evidence.
Know When Another Round Is Needed
Continue when a must-pass rule or key task still fails, new verified facts change the work, or the proposed fix created a new fault. Stop when pass rules hold and remaining requests are out of scope or preference without a clear risk. A fixed round count can help a quote, but it cannot replace a sound stop decision.
The Short Answer
The right number of design revisions is the number needed to meet the approved brief and pass rules. Use clear review roles, issue types, evidence, small tests, one decision owner, and a log. Continue for real faults; stop when the work passes and further changes have no defined need.
Need a cleaner design review process?
TTGC can help set the brief, roles, pass rules, test plan, and decision log. No revision count can guarantee approval, quality, sales, speed, or return.
Sources
- GOV.UK Service Manual — Agile delivery. https://www.gov.uk/service-manual/agile-delivery
- Nielsen Norman Group — Design Critiques: Encourage a Positive Culture to Improve Products. https://www.nngroup.com/articles/design-critiques/
- W3C — Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/







