Website Redesign Revision Policy

Outcome Summary

• Define what “a revision” means (and what it doesn’t) before design feedback starts.
• Keep approvals moving by using a single review path, clear sign-off gates, and bundled feedback.
• Reduce surprise scope by separating “refinement” from “new direction” and “new functionality.”

What Revamp Actually Does (Truth Block)

✅ Revamp does

• Generate an AI website redesign by pasting a URL.
• Provide a live preview link you can share for review.
• Let you iterate by generating new redesign demos (optionally steered by design preferences).
• Offer shareable demo links as part of the product experience.
• Provide code export on paid plans.

❌ Revamp does not

• Guarantee performance, SEO, conversion, or revenue outcomes from a redesign preview.
• Replace product discovery, requirements gathering, or contractual scoping for complex sites.
• Ensure the output will perfectly match specialized components or complex functionality without further work.

The Core Problem

• Feedback arrives as scattered messages, conflicting opinions, or late-stage “while you’re in there” requests.
• Clients treat “revision” as unlimited exploration instead of controlled refinement.
• Teams approve visuals but later revisit content, structure, or navigation—creating rework.
• Approvals get stuck because nobody owns the final call.
• “Small changes” pile up into a different site than what was originally agreed.

Framework

Align on definitions (so you can enforce them)

Start by defining feedback types in plain language.

Feedback type	Counts as a revision?	How to handle it
Copy tweaks, spacing, minor visual polish	✅ Usually	Bundle and apply within the agreed review loop
Layout changes within the same page goal	✅ Sometimes	Treat as refinement if direction stays consistent
New page goals, new audience, new positioning	❌ Usually not	Treat as a direction change (new scope)
New integrations, complex interactions, app-like behavior	❌ Not a revision	Scope separately
“Can we see a totally different style?”	❌ Not a revision	Treat as a new concept / exploration track

Set review roles and a single source of truth

• Name a single decision-maker (the person who can approve).
• Pick one feedback channel (doc, ticket, or annotated tool) and stick to it.
• Require feedback to be bundled (avoid drip-by-drip micro-requests).

Create sign-off gates (what gets approved, and when)

Use explicit gates so “approved” has meaning.

• Direction sign-off: overall look and feel, section order, messaging direction.
• Content sign-off: final copy, logos, images, legal lines provided by client.
• Build sign-off: final implementation details and launch readiness.

If you’re using Revamp, the live preview link makes direction sign-off easier because stakeholders review the same demo.

Define what a “revision request” must include

Make incomplete feedback un-actionable by policy.

• What page/section the change applies to
• What to change (and what to keep)
• Why it matters (goal / objection / clarity)
• Acceptance criteria (how you’ll know it’s done)

Separate “revision” from “scope change” with a lightweight change note

When a request changes goals, adds pages, or adds functionality, pause revisions and document:

• What changed
• What it impacts (pages, content, approvals)
• What must be traded off (timeline, budget, or features)

If you want a fast way to document assumptions/exclusions, you can adapt output from Revamp’s Website Redesign Quote + Proposal Generator into your change note format.

Use the demo-first loop (especially for approvals)

A practical workflow when using Revamp:

• Generate a redesign demo.
• Share the live preview link for consolidated feedback.
• Apply feedback by generating the next iteration (and capturing decisions).
• Only move to implementation once direction is approved.

Copy/paste templates (policy + messages)

Use these as-is, or adapt to your contract/proposal.

REVISION POLICY (PLAIN-LANGUAGE)

A “revision” means refinements to the approved direction (layout polish, spacing, component tweaks, copy edits provided by Client).

A “revision” does NOT include: changing the project goals, adding new pages beyond the agreed deliverables, changing the approved direction to a new concept, or adding new functionality/integrations.

Feedback must be bundled and provided in the agreed review format. Conflicting feedback must be resolved by Client’s designated decision-maker.

REVISION REQUEST FORMAT (CLIENT INSTRUCTIONS)

Please send feedback as a single bundled update.
For each item include:
- Page/section:
- Current behavior/content:
- Requested change:
- Reason/goal:
- Acceptance criteria:

APPROVAL MESSAGE (DIRECTION SIGN-OFF)

Confirming direction sign-off:
- We approve the overall layout, style, and section order in the current demo.
- Further changes are refinements within this direction (not a new concept).
- Next step is content finalization and implementation planning.

SCOPE CHANGE NOTE (WHEN REQUESTS EXPAND)

This request changes scope because it alters goals/deliverables/functionality.
To proceed, we’ll confirm:
- What’s added/changed:
- What’s removed/deprioritized (if any):
- Impact on timeline and cost:
Once approved, we’ll resume revisions under the updated scope.

Use Cases

Agency pitching a redesign (and preventing endless concept churn)

• Scenario: A stakeholder asks for “a totally different look” after the team already aligned on a direction.
• Recommended approach: Treat it as a new concept track, not a “revision.” Generate a separate Revamp demo link and ask for a direction decision before any further polishing.
• Common mistake: Applying mixed feedback to the same direction until the work becomes a patchwork of incompatible preferences.

In-house marketing team modernizing an outdated site

• Scenario: Multiple reviewers leave conflicting comments across email, chat, and slides.
• Recommended approach: Centralize feedback into one document/ticket thread, require bundling, and have the decision-maker reconcile conflicts before changes are implemented.
• Common mistake: Treating every comment as equal priority, which slows approvals and increases rework.

Freelancer delivering a redesign + build handoff

• Scenario: Visuals are approved, then copy and assets arrive late and trigger layout changes.
• Recommended approach: Add a content sign-off gate: content and assets must be final (or explicitly marked as placeholders) before implementation is considered stable.
• Common mistake: Building against placeholder content without explicitly documenting what will change when final content arrives.

Decision Checklist

• Have you defined “revision” in a way a non-designer can understand?
• Is there a single decision-maker who can approve (and resolve conflicts)?
• Is feedback bundled in one agreed format and location?
• Do you have sign-off gates for direction, content, and implementation?
• Do you separate “new concept” requests from “refinement” requests?
• Do you have a lightweight scope-change note template ready?
• Are acceptance criteria required for non-trivial feedback?

Constraints

• A redesign preview can accelerate alignment, but it doesn’t replace discovery for complex requirements.
• If the source site is hard to crawl or has complex components, outputs (and iteration speed) can vary.
• Stakeholder-heavy teams need a decision-maker, or revisions become negotiation-by-comment.
• Late content and asset changes can invalidate earlier approvals unless your gates are enforced.
• “Quick tweaks” still have coordination cost; bundling feedback is the lever that keeps things moving.

Practical Example (Illustrative)

Situation: You share a Revamp demo link. The client replies:

• “Make it more premium.”
• “Also can we add a new pricing page and a partner portal?”

Decision path:

• “More premium” → ask for concrete direction (examples, adjectives translated into design traits) → treat as revision only if it stays within the approved goals.
• “New pricing page” → if not in deliverables → treat as scope change (new deliverable).
• “Partner portal” → treat as new functionality (scope change, likely discovery needed).

How you respond (policy-driven):

• Confirm which items are refinements vs scope changes.
• Ask for bundled feedback on the current demo focused only on direction.
• Log the scope additions separately with impacts and tradeoffs, then get approval to proceed.

FAQ

What should count as a revision vs. new scope?

A revision is refinement within an approved direction (polish, small layout adjustments, copy edits). New scope changes deliverables, goals, or functionality (new pages, new audiences, integrations, portals).

How do we stop “just one more tweak” cycles?

Enforce bundling (single consolidated feedback), require acceptance criteria for meaningful changes, and use sign-off gates so “approved” locks the direction.

Who should be allowed to give feedback?

Anyone can comment, but only the designated decision-maker should submit the final bundled feedback and approve gates.

Can a Revamp demo link be used for approvals?

Yes—treat the live preview link as the single artifact stakeholders review, then document direction sign-off before moving to implementation.

What if stakeholders disagree?

Require the client/team to resolve conflicts internally (via the decision-maker) before you implement changes. Conflicting feedback is a project risk, not a design task.