A client tells you to "make it pop." You have about three seconds before you either agree, push back, or silently die inside and change the wrong thing. We have been in that room enough times to build an actual system around it — one that keeps the client happy and the work intact.
Client feedback is not the enemy of good work. Unfiltered client feedback applied without a framework is. There is a real difference between the two. The job is not to defend your work against the client. The job is to separate what they are actually asking for from the words they happened to use to ask for it, then respond to the real ask in a way that serves the project.
This is the process we run on every project. It is not complicated. It requires discipline to stick to it when feedback arrives fast and emotions are high, but the logic underneath it is straightforward.
The ground rules we set before feedback starts
- Every project starts with a written Vision Document. One page. The goal, the audience, the tone, three things we are and three things we are not. Every piece of feedback gets measured against it.
- Feedback rounds are scheduled, not continuous. No Slack messages asking to "just tweak this one thing." Feedback happens in defined windows so it can be processed properly.
- We acknowledge every piece of feedback in writing. Even if we are going to push back on it, the client gets confirmation that it was received and that a response is coming.
- Every revision comes with a short explanation of what changed and why. Not a justification — a record. So the client can see their feedback translated into action, and so we can refer back to it later if direction shifts.
The four types of feedback we actually receive
Not all feedback is the same kind of problem. Before we respond to anything, we categorize it. Each type has a different right answer and a different failure mode if you treat it the wrong way.
"I don't like that colour / font / image."
This is the most common type and the easiest to mishandle. The instinct is to change whatever they pointed at. The problem is that aesthetic preferences are often stand-ins for something more specific — the client might be saying the page feels too corporate, or too casual, or too loud, and they just grabbed the nearest visual element to point at.
Our response: ask one question before making any change. "What feeling were you hoping for here?" Almost always the answer gives us the real brief. Sometimes after that conversation, the colour they said they hated turns out to be exactly right and they know it.
"Our users won't understand this."
This is the highest-value feedback type and the one we take most seriously, even when we initially disagree with it. The client knows their audience better than we do, especially in the first few weeks of a project. A functional concern points at a real usability or communication risk, and those risks compound in production.
Our response: treat it as a brief to test. If we can validate or invalidate it with a fast user test or a reference to research, we do that first. If the concern holds up, we revise. If it does not, we share the evidence and make the call together. We never dismiss functional feedback without at least exploring it.
"Our CEO / board / other department prefers X."
This is real and it cannot be ignored. Someone with authority over the project has a preference and that preference is going to affect decisions regardless of whether it is the right call creatively. Pretending otherwise is not professional — it is naïve.
Our response: get the stakeholder in the room or on a call, once, before any changes are made. Not to talk them out of their preference, but to understand the weight they are putting on it. A CEO who "prefers navy" because it is their brand colour is giving a different kind of feedback than one who has a genuine emotional attachment to a design direction from 2015. We need to know which one we are dealing with before we know how to respond.
"While we're at it, could we also add…"
This arrives disguised as feedback but it is actually a change request. It is not malicious — clients are engaged with the work and ideas naturally generate more ideas. But left unaddressed, scope additions compound. Three "small changes" in week two become twelve changes by week five, none of which were in the original brief, and the project is now late and over budget with no clear explanation of why.
Our response: acknowledge the idea, note it in the project log, and evaluate it formally at the next scope review. We use a simple test: does this serve the Vision Document, and is there budget and timeline for it? If yes to both, it goes into a change order. If not, it goes into the backlog for a future phase. The idea never dies — it just moves to the right lane.
What they say vs. what they mean
We keep an internal cheat sheet. These translations took years to collect and they have saved more projects than any design framework we have ever used.
Feedback is a translation problem. The client is describing a feeling in the only words they have. Your job is to find the actual brief hiding inside the words they chose.
The four ways feedback derails a project
We have been on the wrong side of all of these. They are preventable, but only if you recognise the pattern early enough to interrupt it.
Responding to feedback without categorising it first
You change the colour because the client said "change the colour." Three rounds later the page is a different shade of the original problem and nobody knows why.
Letting feedback accumulate between rounds
Async feedback on a live Figma file without a defined review schedule. Every day brings a new comment. By the time you sit down to revise, there are twenty-seven notes with no clear priority order.
Not referencing the Vision Document in your response
You push back on feedback without anything to anchor the pushback to. The client hears "we don't want to change it" instead of "here is why this change would move us away from what we agreed to build."
Saying yes to everything to avoid conflict
The path of least resistance. Each individual change seems small. Collectively they sand down everything that made the work worth doing. The final deliverable is technically everything the client asked for and nothing anyone would show in a portfolio.
Saying yes to everything is not client service. It is a slow way of delivering work that neither side is proud of.
Does the process actually hold up
It does, with one caveat: it requires the client to have agreed to it upfront. When we walk a new client through the Vision Document, the feedback schedule, and the change order process at the start of a project, we are not being bureaucratic. We are building the shared infrastructure that makes honest conversation possible later.
Clients who understand the framework give better feedback. Not because they suddenly become design experts, but because the structure gives them a safe way to say what they actually mean without feeling like they are criticising the work or the team. Good feedback infrastructure makes the creative relationship better for everyone.
The Vision Document is the single most important tool in the process. Not because it stops feedback — it does not and should not. But because it gives both sides a neutral reference point. When a revision conversation gets heated, we come back to the one page we both signed off on at the start. It redirects the conversation from "I vs you" to "us vs the problem."
If you take one thing from this article, make it that: write the Vision Document before a single design decision is made, get explicit sign-off on it from the person who will be giving feedback, and keep it visible throughout the project. It is the difference between feedback that sharpens the work and feedback that unravels it.