Systems & Execution

Your Designer Doesn't Need More Revisions—You Need Fewer Options

Unlimited revisions don't protect outcomes—they destroy them. Here's how fewer options and clearer constraints produce better sites faster.

January 22, 2026
7 min read
Coaches, Entrepreneurs, Local Business Owners

I killed a project last year.

Not because the client was difficult. Not because the budget ran out unexpectedly. I killed it because we'd spent twelve months adding features, revising functionality, expanding scope—and we were further from launch than when we started.

The client kept saying "just one more thing." I kept saying yes. By month three, what started as a schedule tracker had morphed into a custom booking platform with member portals, automated sequences, and integration requirements that needed a development team I don't have.

We mutually agreed to walk away. The client still doesn't have a website.

Here's what I learned: the problem was never revisions. The problem was that we never made the hard decisions upfront.

The Myth That's Costing You Months

Let me bust this one wide open: more revisions do not equal a better result.

I know. It sounds counterintuitive. We've been trained to believe that iteration is holy. That feedback loops are the path to perfection. That "unlimited revisions" in a contract means you're protected.

You're not protected. You're trapped.

Here's what actually happens when you have unlimited revisions without constraints:

  1. You defer decisions. Why choose now when you can "see how it looks" later?
  2. Options multiply. Each revision spawns new possibilities.
  3. Decision debt compounds. Every unmade choice stacks on top of the last.
  4. Taste becomes the battleground. Without clear metrics, you're left debating colors and fonts forever.
  5. Nothing ships. Or worse—something ships that satisfies no one.

Iyengar and Lepper's famous jam study proved this decades ago: when shoppers faced 24 jam options, only 3% bought. When they faced 6 options, 30% bought. More options don't help you decide. They paralyze you.

The same principle destroys website projects daily.

Revision Spirals Start Upstream

Every revision spiral I've witnessed—including my own disaster—shares the same root cause: missing upstream decisions.

Before you debate button colors, you need answers to:

  • What is this page supposed to accomplish?
  • How will we measure success?
  • What's explicitly out of scope?
  • Who has final approval authority?
  • What's the timeline, and what happens if we miss it?

These aren't fun questions. They require commitment. They force you to say no to possibilities. That's exactly why people skip them.

But here's the counterintuitive truth: the fastest projects are the ones with fewer options and stronger constraints, not more iterations on taste.

Constraints aren't limitations. They're liberation. When you know the boundaries, you can move fast within them.

The "One Direction, One Outcome" Rule

Here's how I run projects now:

One recommended direction per checkpoint.

Not three concepts to choose from. Not a mood board with seventeen reference images. One direction. My recommendation. Based on your goals, your audience, and what actually works.

You can reject it. We can discuss it. But we're not starting from "which of these five options do you like best?" because that question has no right answer—only preferences that shift with your mood.

This isn't arrogance. It's efficiency.

Design research shows massive usability gains from iteration—but that's iteration on usability, not on stakeholder taste. Testing whether users can find the contact button? Valuable. Debating whether the blue should be slightly more teal? Waste of everyone's time.

One success metric per page.

Your homepage has one job. Your services page has one job. Your about page has one job.

Define that job before design starts. Then every decision filters through: "Does this help or hurt the one thing this page needs to accomplish?"

No metric, no clarity. No clarity, no end to revisions.

Checkpoints That Actually Matter

Most approval processes are backwards. They ask for feedback at the wrong moments and skip the moments that matter.

Here's what a tight approval loop looks like:

Checkpoint 1: Strategy Lock

Before any design work, align on:

  • Site goals and success metrics
  • Explicit scope (what's in, what's out)
  • Timeline with consequences
  • Decision-maker identification

This checkpoint prevents 80% of revision hell.

Checkpoint 2: Structure Approval

Wireframes or site maps. No colors. No images. Just: "Here's what goes where and why."

Approve the structure before anyone opens Figma.

Checkpoint 3: Design Direction

One recommended direction. Review against the strategy you already locked. Does it serve the goals? Yes or no.

Checkpoint 4: Build Review

Functional site. Test on your phone. Click every link. Submit every form.

That's it. Four checkpoints. Not seventeen rounds of "can we try it in green?"

The 48-Hour Rule

Every checkpoint gets a 48-hour feedback window.

Not because I'm impatient. Because delayed feedback is degraded feedback.

When you sit on a design for two weeks, you forget the context. You show it to your spouse, your business coach, your neighbor. Everyone has opinions. None of them know your strategy.

By the time you respond, you're not giving feedback—you're starting a committee meeting in your head.

48 hours. Respond with your thoughts. Move forward.

If you can't respond in 48 hours, that's data too. It usually means the upstream decisions weren't clear enough.

What to Measure Instead of Debating Taste

When a revision request comes in, I ask one question: "What problem does this solve?"

Not "do you like it?" Not "does it feel right?" Those are taste questions with no answers.

Instead:

  • "The headline doesn't communicate what I do clearly enough" → Solvable problem
  • "I don't love the font" → Taste preference, not a problem
  • "Users might not see the call-to-action" → Testable hypothesis
  • "Can we make it more modern?" → Undefined term, not actionable

Measure what matters:

  • Does the page load fast?
  • Can users complete the intended action?
  • Does the copy communicate the core offer?
  • Is the site accessible?

Everything else is negotiable. And "negotiable" means "probably fine as-is."

Quick Wins to Stop Revision Spiral

If you're mid-project and already drowning, here's your lifeline:

  1. Limit each checkpoint to 1 recommended direction. Stop presenting options that don't have your endorsement.

  2. Require 1 success metric per page. If you can't define it, you can't approve it.

  3. Pre-define what's in and out of scope. Write it down. Reference it when scope creep appears.

  4. Use 48-hour feedback windows. Enforce them. Silence after 48 hours = approval.

  5. Reduce to 2 options maximum. If you must present choices, never more than two. "A or B" is answerable. "Pick from these seven" is not.

The Smaller Version Ships

That project I killed? A smaller version would have shipped in six weeks. A simple site with a clear layout, a simple form, and a way to capture data.

Instead, we spent twelve months building nothing.

More planning at the start would have avoided the headaches. Clearer constraints would have streamlined development. Saying "no" to feature requests would have meant saying "yes" to actually launching.

Your designer doesn't need more revisions. They need you to make fewer decisions during the project because you made the important ones before it started.


Stuck in revision limbo right now?

Send me the page and the goal. I'll tell you what constraint you're missing—and what one decision would get you unstuck.

No pitch. Just clarity.

Stay Connected

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Vincent Rignol

Based in Colorado · Serving clients worldwide

© 2026 All rights reserved