Gather every opinion at the first draft, then name one person who can say final — late feedback is what turns two revision rounds into eight. The people commenting aren’t the problem; the timing is.
The moment it happens
When the whole family reviews your website design — son, wife, the friend who knows computers — it usually happens at 80% completion, because that’s the first version anyone finds worth showing.
By then the design has been approved once, built out across pages, and the developer considers it settled. The feedback arriving now is often genuinely useful. It is also, functionally, a second brief.
Why it lands late
The early version doesn’t look finished. Nobody wants to show a wireframe or a first draft to their spouse, so the review happens when it’s presentable — which is when changes are expensive.
The son or nephew becomes the technical authority. A younger family member who “understands computers” is often asked to check the work, and their comments carry weight with the owner even when they’re stylistic rather than functional. Developers experience this as a second client appearing in week three.
Nobody was told they’d be consulted. The people commenting had no idea a decision was being made, so they comment as if the design is still open — because from their side, it is.
The fix, which costs nothing
- Decide now who’s involved. Write down the two or three people whose opinions will actually change your mind. Not everyone who’ll see it.
- Show them the first draft, not the finished build. Even if it looks unfinished — explain that’s the point.
- Name one approver. One person, probably you, who says “this is final”. Tell the developer who it is.
- Collect feedback in one pass. Get everyone’s comments in the same window, consolidate them into one list, send once.
- Separate function from taste. A wrong phone number is a defect. A colour preference is taste. Send defects as must-fix and preferences as a shorter, ranked list.
| Feedback timing | Cost to change | Effect on timeline |
|---|---|---|
| At first draft | Low — nothing is built yet | Usually none |
| After design approval, before build | Moderate | Days |
| At 80% completion | High — pages must be reworked | Weeks |
| After launch | Depends; small edits are fine | Ongoing if unmanaged |
When the feedback is right but late
It happens. Your brother-in-law notices the phone number is hard to find on mobile, and he’s correct. That’s worth fixing regardless of timing.
The way to handle it without stalling the project: put it on the must-fix list if it affects whether a customer can contact you, and on an after-launch list if it doesn’t. Launching with a colour someone dislikes is fine; launching with a buried phone number isn’t.
If the late feedback is genuinely a change of direction — different layout, different structure — expect it to be quoted as new work rather than a revision, at any price level. That’s fair, and knowing it in advance keeps the conversation calm.
What to say to your developer
One message at the start:
[Name] will give final approval. I’ll share the first draft with two others and send all comments together as one list. After the design is approved I’ll keep further changes to genuine issues.
Vendors read this as a project that will run smoothly, which is usually reflected in how they schedule it.
What to do this week
- Write down who genuinely gets a say. Keep it to three people.
- Ask your developer for the earliest draft you can share, even if rough.
- Tell the developer who the approver is.
- Set one date for consolidated feedback, and hold everyone to it.
- Mark every comment as defect or preference before sending.
If you want it done the certain way
We ask who the approver is before starting and share an early draft precisely so opinions arrive when changes are cheap. Prices are published, revision rounds are stated, and the delivery date is written with a refund behind it. WhatsApp us; we reply in about five minutes between 9am and 7pm.
Related reading
- “Unlimited revisions” — does anyone mean it?
- What counts as a “small change” and what doesn’t
- “Same-to-same bana do”: why copying a rival’s site fails
- The final payment standoff
FAQ
How do I handle conflicting opinions on my website design?
Name one approver before design starts, collect everyone else’s comments in a single early round, and separate defects from preferences. Conflicting taste at 80% completion is what causes the extra rounds.
Should I let my son or nephew review the website?
Their input can be genuinely useful, especially on mobile usability. Involve them at the first draft rather than at the end, and be clear with the developer about who has final say.
What if the design feedback comes after approval?
Fix anything that affects contactability or accuracy immediately; hold preferences for after launch. A change of direction will normally be quoted as new work, which is reasonable.
