How to Manage Website Design Revisions Without Losing the Project Scope

Website design revisions become difficult when several different conversations arrive in one message. A client might point out an incorrect phone number, ask for a different heading style and request an entirely new booking flow. Treating all three as the same kind of feedback makes scheduling and approval harder than they need to be.

A useful revision process separates corrections, unresolved design decisions and additions to the agreed scope. This is a working framework for organizing the conversation. Your project agreement still determines what is included, how changes are approved and whether additional work is chargeable.

Start with the version being reviewed

Before interpreting feedback, confirm which design the client saw. Record the page, layout and revision name alongside the preview link. A note about the desktop homepage may not apply to the mobile product page, and a screenshot from last week may describe something already corrected.

Send one clear review request: “Please review Homepage V3 for content accuracy and the placement of the enquiry form. Navigation structure was agreed in the previous round.” This gives the client a useful boundary without preventing them from raising an important problem outside that boundary.

In Swelik, the public preview link can remain the same when the owner replaces the mockup. Still name the revision in your message. A stable address reduces link confusion, but it does not replace an explanation of what changed.

Sort feedback into three groups

Corrections bring the design back into line with agreed information or requirements. Examples include an incorrect address, a missing supplied testimonial or a button label that contradicts approved copy. Record the original requirement so the correction is easy to verify.

Open decisions concern something that has not yet been settled. A client may be choosing between two hero compositions or deciding which service deserves priority. Give each decision an owner and a clear question. Avoid repeatedly adjusting an element while nobody has authority to choose its direction.

New requests introduce additional work or change an agreed direction. A new page, an extra language or a new checkout journey may affect design, content and development. Describe the implications before promising a delivery date. A request can be valuable while still needing a separate estimate or agreement.

Use a revision note that can be acted on

A useful note contains the location, observation, desired outcome and owner. For example: “Mobile product page, delivery section: the delivery estimate appears below the main purchase area. Buyers need to understand timing before deciding. Please propose a clearer placement for review by Friday.”

Compare that with “make delivery more obvious.” The longer note explains the problem without prescribing an arbitrary visual fix. It also gives the designer room to suggest a solution that fits the rest of the page.

You can use this compact template: “Version: __. Page and device: __. Current issue: __. Expected outcome: __. Category: correction / decision / new request. Owner: __. Next review: __.” Keep the agreed response beside the original observation.

Resolve conflicting requests before editing

If one stakeholder wants a shorter page and another asks for three additional sections, the designer needs a priority decision. Ask the project owner which audience, message or business goal should take precedence. Do not silently pick the loudest comment or implement both requests in a way that makes the page incoherent.

Collect related feedback into one revision list, preserve the original meaning and flag conflicts explicitly. Our guide to website design feedback questions helps turn preferences into questions that a project owner can answer.

Close the round with evidence

When the revision is ready, summarize what changed, what remains open and what was moved into a separate request. Update the preview from the private management page, then send the public link with a specific next action. Keep the management link private because it grants editing access.

Ask for confirmation against the revised items, rather than a vague “all good?” A decision should identify the version and scope being accepted. A visual review decision does not automatically approve implementation behavior, legal copy or functionality that the mockup cannot demonstrate.

Worked example: a homepage review with mixed requests

Imagine a small consultancy reviewing its second homepage concept. The client sends five comments: the office address is wrong, the service names need updating, the hero feels too formal, a booking calendar would be useful and a partner wants a separate recruitment page. A designer who immediately starts editing risks treating factual corrections and new functionality as equivalent tasks.

Begin by checking the brief and the approved content. The address is a correction if the correct address was already supplied. The service names may be a correction or newly changed information; identify which. The hero feedback needs clarification because “too formal” does not explain the desired impression. The calendar and recruitment page require a scope discussion if they were not part of the agreed deliverables.

Send a response that groups the work: “I can correct the address in this revision. Please confirm the final service names. For the hero, would you like the message to feel more approachable, or is the concern specifically the image? I will outline the effort and dependencies for booking and recruitment separately.” This acknowledges every request without making an accidental commitment to all of it.

Decide the response before estimating the work

For each item, identify whether you can act now, need information or need a decision about scope. This is a more useful first pass than attaching a price to every sentence. An apparently small visual adjustment might depend on approved copy, while a large-looking section could be straightforward if its content and pattern already exist.

Estimate only after the requested outcome is clear enough. State assumptions beside the estimate, including who supplies content and which layouts are included. If the request changes the page structure, explain what previously reviewed material may need another look. Keep commercial discussion separate from the feedback record so the design notes remain readable.

Use a revision ledger that distinguishes decisions from tasks

A simple ledger can contain a reference number, version, section, original observation, agreed response, owner, status and review date. Write the original observation in the client's terms, then add the agreed interpretation separately. That preserves context when a short comment such as “simplify this” becomes a more precise instruction after discussion.

Use statuses that describe real progress: needs clarification, ready to revise, revised for review and confirmed. “Done” can be ambiguous because the designer may mean the edit exists while the client assumes it was accepted. A separate confirmation state makes the difference visible without requiring a complicated project-management system.

An example entry might read: “R12 / Homepage V2 / Services / Descriptions feel repetitive / Rewrite the three descriptions around distinct customer needs / Client supplies draft copy / Needs content.” That record identifies the dependency instead of leaving the designer responsible for inventing business information.

Handle a revision that reverses an earlier choice

Sometimes a client sees the full composition and changes their mind about an approved direction. First ask what new information prompted the change. Perhaps the offer changed, a decision maker joined late or the original approval was based on a misunderstanding. Understanding the reason helps distinguish a necessary correction from a recurring preference cycle.

Show the earlier decision and its rationale neutrally. Then describe the consequences of reopening it. For example, changing the page's primary audience may affect the hero, proof points and enquiry flow, not just one paragraph. Ask the approval owner to choose a direction before making several dependent edits that could be reversed again.

Close the loop without hiding unresolved work

When the next preview is ready, send a compact revision summary with three groups: changed, awaiting input and proposed separately. Link each change to the relevant section. Avoid burying an unresolved business decision inside a long list of completed spacing adjustments, because the client may assume the page is ready to move on.

If a requested change was not made, explain why. You may have retained a description because another stakeholder needs to confirm its accuracy, or left the booking feature out pending scope agreement. Transparency is more useful than quietly omitting the request and hoping it will not come up during the next review.

A copyable response to an out-of-scope request

“Thanks, this could be useful for the page. The current review covers __. The new request adds __ and depends on __. I will keep the agreed corrections moving while we confirm whether to include this addition now or schedule it separately. Please have __ confirm the priority before I revise the affected sections.”

Adapt the wording to your agreement and relationship. The purpose is to preserve momentum while making the choice explicit. It should not sound like a refusal to consider a good idea, and it should not imply that a new feature has already been accepted into the current delivery.

Check the result before sending the next link

Reopen the exact export the client will see, compare it with the ledger and confirm that your summary matches the visible changes. Check that desktop feedback was not accidentally applied to the wrong device layout. A short, accurate change summary gives the next review a clear starting point and makes the stable preview URL genuinely useful.

Frequently asked questions

How many revision rounds should a website project include?

There is no universal number. Agree on the review stages, decision makers and included work before the project starts. More rounds cannot compensate for an unclear brief or conflicting approval authority.

Should every small change become a new quote?

Use the actual agreement and your judgment. The purpose of categorization is to make consequences visible, not to create friction over every word. Group related additions and discuss their impact together.

What should I send with a revised mockup?

Send the public preview, the revision label, a short change summary and the decision you need next. For a repeatable record, use a website design revision log.