Website Design Feedback vs a Change Request: How to Tell the Difference
11/4/2026 · 4 minute read · By Swelik
A practical way to separate defects, refinements, preference changes and new scope so designers and clients can agree on the next step.
Not every comment on a website design means the same thing. “The supplied phone number is wrong” is a correction. “Can we move the contact button higher?” may be a refinement. “Can we add a booking system?” may be new scope. Treating each one alike makes it harder to estimate work and set expectations.
Four useful categories
- Defect or mismatch: The design fails an agreed requirement, uses incorrect supplied information, or does not match the approved direction.
- In-scope refinement: A change within the agreed deliverable and review round, such as adjusting spacing or clarifying a label.
- Preference change: A stakeholder wants a different direction even though the current design meets the brief. Discuss the reason and decide whether to revise.
- Change request: A new page, feature, audience, content requirement or interaction that was not part of the agreed scope.
Use a short decision test
- Was the expected outcome written in the brief, acceptance criteria or prior approval?
- Does the current design contradict that agreement, or is the request introducing a new outcome?
- Does the change affect page count, functionality, content, schedule or dependencies?
- Who is authorized to approve the impact?
This test does not decide contract terms. Use the project agreement to determine pricing, included rounds and formal change control.
Example requests
“The header uses the old logo.” If the new logo was supplied and approved for use, treat it as a correction.
“Can we make the booking link more visible?” If the booking action is in the brief, this may be an in-scope refinement. Clarify the design goal.
“Can you add a members-only dashboard?” If no account area was included, this likely needs a scope and estimate discussion before design continues.
“I changed my mind about the brand direction.” This is a new decision, even if it changes only colors at first. Identify affected assets and downstream work.
Respond without arguing about labels
Ask what outcome the requester needs, compare it with the agreed scope and explain the impact. A helpful response might be: “We can make that change. It adds a booking flow beyond the current page design. I’ll outline the schedule and estimate impact for approval before we add it.”
Keep the review record together
For each item, note the page, category, decision owner, agreed action and status. Close out accepted feedback in the next version and keep unanswered questions visible. A website design revision log can help keep the history readable.
Use examples to prevent surprises
Correction: “The footer address is outdated; use the address in the approved brief.” The source information exists, so this is a factual fix.
Refinement: “The primary action is difficult to distinguish from the secondary link. Can we increase its prominence while retaining the approved brand palette?” The request improves an agreed goal within the same page direction.
New scope: “Can the contact form route enquiries to three departments and show a different set of questions for each?” This introduces conditional behavior that may require new design, development and testing.
New direction: “We now want to target enterprise buyers instead of local households.” The audience has changed, so messaging, imagery and page hierarchy may all need reconsideration.
Assess impact before agreeing on timing
A small visual change can have a large downstream effect if a component appears across many pages. A seemingly small feature can require data, integrations or permissions. Ask which screens, content and technical dependencies are affected. Estimate the change before promising a delivery date, then get the authorized person’s approval.
Use a simple change-request record
- Requester and date.
- Page, component or journey affected.
- Reason and desired outcome.
- Whether the request matches the agreed brief.
- Impact on design, implementation, cost and schedule.
- Decision, approver and next action.
Keep this record respectful and factual. Categorizing an item is not a way to dismiss client needs. It helps both sides understand whether to fix a mismatch, refine the design or formally expand the work.
For included rounds and limits, read the project agreement alongside Swelik’s revision-scope guide. The contract governs what is included.
Frequently asked questions
Can a client change their mind?
Yes. The practical question is how that decision affects scope, work already completed and timing. Discuss the impact rather than treating a change of mind as a personal failure.
Is every extra request billable?
That depends on the agreement. Refer to the contract and get approval for any changed estimate before proceeding.
Put this into practice with Swelik’s mockup sharing and review tools.