Why Design Clients Send Vague Feedback (and How to Get Specific Notes)

You send the homepage design on Friday afternoon. On Monday, the reply says, "Feels a bit off. Can we make it pop?" You have no idea what to change, so you guess, and the next round of guessing begins.

To get better client feedback on design, share the brief and goals before the work, ask specific questions tied to those goals instead of "What do you think?", and collect comments in a fixed format: where, what's wrong, and what outcome you need.

My view is that vague feedback is mostly a process problem, not a client problem. Clients don't have the time or vocabulary to explain taste, so the studio has to supply the structure. Don't try to turn clients into designers. Give them a form that does the thinking for them.

Why do design clients send vague feedback?

Design is subjective, and most clients don't have the time or the vocabulary to explain what they like or dislike. They react to the work the way anyone reacts to a room or a song, and then they try to translate that reaction into a note.

Taste is hard to put into words

Rasmussen University's roundup of frustrating client feedback lists the greatest hits: "I like purple, make it more purple," "Can we make this more [insert vague adjective here]?" and "Just keep designing, I'll know it when I see it." Those are illustrative quotes, not survey data. But if you've done client work for more than a month, you've received all three.

The same article quotes a creative director who points out that clients struggle to separate what they personally like from what will work for their audience. That's one expert's view, but it matches my experience. A client who says "I don't like the blue" is usually telling you how they feel, not whether the design will work.

Vague feedback usually starts upstream

When I trace a "make it pop" comment backward, I almost never find a client who's being difficult. I find one of four gaps:

• No shared goals, so the client has nothing to judge the design against.
• A thin brief, so "good" means whatever the client feels that morning.
• Files dropped cold in an email with no explanation of the thinking.
• Several reviewers, each with a different opinion, merged into one muddy note.

Picture a studio that emails a homepage PDF to a founder with the message "Attached, let us know your thoughts!" The founder opens it on a phone between meetings, forwards it to a cofounder, and replies with "Feels off, can we make it pop?" The studio never told them what the page was supposed to achieve, so the founder fell back on instinct. That isn't a feedback problem. It's a setup problem.

How do you set up the review before the design is shown?

Frame the context, the problem, and the goals before you ask for feedback. A discussion in r/UXDesign makes the same point: whoever is asking for input should lay out the context, the problem, and the goals first. It's community advice rather than research, but it holds up in practice.

Lock the brief and references first

Before you show anything, confirm the brief with the client in writing. Goals, audience, and constraints should be on the page so feedback has something to anchor to. If your briefs come back thin, here's how to write a creative brief clients will actually fill in.

Ask for references early too. Eleken suggests that clients give feedback before the work starts by commenting on pieces from the designer's portfolio or on reference examples. That gives you a shared vocabulary before there's anything to react to.

Decide who gives feedback and where

Agree on two things up front: who reviews, and who consolidates. One person on the client side should own the final list of comments. Otherwise you'll receive three conflicting emails and have to referee.

Pick one channel as well. Webvizio, a vendor that sells visual feedback tools, argues that clear communication protocols and easy visual feedback tools are the foundation of web design feedback. Treat the tool pitch with a grain of salt, but the protocol point is sound. Feedback scattered across Slack, text messages, and email threads is where notes go to die.

Finally, think about what you show. One community answer on Quora recommends sharing a flat image or a prototype instead of raw design files, which limits endless tinkering. It's one practice, not a law. But I've seen raw Figma access invite pixel-level comments on work that wasn't ready for them.

The four-stage design review process, step by step

This is the process I'd run on any design project: brief check, first concept review, revision round, final sign-off. Each stage has one job, and it keeps feedback from jumping ahead of the work.

Stage 1: Brief check

Confirm goals, audience, and references before any design is shown. Send a short summary ("Here's what we're solving, who it's for, and the references you liked") and ask the client to correct it.

Why: it's the cheapest moment to find a disagreement. Example: a client says the page should target enterprise buyers, but their reference sites are all aimed at freelancers. You catch it now, not in round three.

Stage 2: First concept review

Show a flat image or prototype along with your reasoning, then ask two or three targeted questions tied to the brief. Explain why the layout leads the eye where it does and what you chose to emphasize.

Why: Big Duck's discussion of effective design feedback frames good feedback as a mix of clarity, collaboration, and strategy. That summary comes from a podcast episode, so take it as perspective rather than proof. Your reasoning gives the client something to react to besides their gut.

Stage 3: Revision round

Collect notes in a fixed format: location, problem, desired outcome. Then reply with exactly what you'll change, and what you won't, and why.

Why: the reply closes the loop. It stops the client from discovering three days later that their note was interpreted differently than they meant it.

Stage 4: Final sign-off

Confirm the finished work against the brief and ask for one clear approval. Not "looks good!" buried in a thread, but a single yes you can point to later. For the mechanics of keeping sign-off moving, see our approval process that doesn't stall when clients go quiet.

If you'd rather not run this by hand, Dora's approvals give clients one-click sign-off from the portal or their inbox, nudge quiet clients, and can auto-approve after a number of days you choose.

Which questions get specific design feedback?

Ask questions tied to the brief instead of "What do you think?" Open-ended prompts invite taste. Targeted prompts invite judgment against a goal, and that's the kind of feedback you can act on.

Questions to replace "What do you think?"

Paste these into your review requests. Use the ones that fit and cut the rest:

1. Does this layout support the goal we agreed on in the brief? If not, where does it fall short?
2. Looking at the first screen, what do you notice first? Is that what you want visitors to notice first?
3. Is there anything that feels off for your audience specifically? Point to where.
4. Which element feels least like your brand, and what would make it feel right?
5. What's one thing that's working that we shouldn't change?
6. Is anything missing that a customer would need to take the next step?
7. If you could change only one thing before we move on, what would it be and why?

A couple of tweaks make these sharper. UX Planet suggests that commenting on the effort or process behind a design makes feedback more specific, so question 2 or 4 can be rephrased as "What do you think we were trying to achieve with this layout?" Also, Launch the Damn Thing recommends avoiding the word "like" when giving designers feedback. I'd treat that as a tip, not a rule, because it's a good nudge from "I like it" toward "this works for our buyers."

If a client says the design "looks poor," don't get defensive. A Graphic Design Stack Exchange thread suggests asking them to explain what makes it poor. "Which part feels poor, and what do you expect it to do that it isn't doing?" usually turns a verdict into a note.

Stryve Marketing's tips are also a handy checklist for clients: be specific, keep it impersonal, ask all your questions, and keep the brief in mind.

One tangent worth clearing up: the 70/30 rule and the 3-5-7 rule people search for alongside this topic are composition guidelines for balance and arrangement. They're not feedback methods. Don't use them to run a review.

Good feedback comments vs vague ones

Notice the pattern: each good comment names a place, a problem, and what the client needs. Also notice that when you're the one replying, the same principles apply. Keep your reply private to the person who raised the issue, be specific about what you'll change, and state the objective it serves.

A reusable design feedback template and common mistakes

Give clients a short template with fields, not a lecture on how to give feedback. My contrarian take: don't tell clients to "be more specific," and don't send a long feedback etiquette guide. Clients rarely read rules, but they will fill in fields, and the fields do the coaching.

The five-field feedback template

This is our recommendation, not a standard. Copy it as is:

Feedback note

1. Goal: What is this piece supposed to achieve?
2. Audience: Who needs to understand or act on it?
3. Location: Where exactly is the change? (page, section, element)
4. Problem: What do you see or feel that isn't working?
5. Desired outcome: What should be true after the change?

Here's a filled-in example for a landing page hero:

1. Goal: More visitors start a free trial.
2. Audience: Operations managers at small agencies.
3. Location: Hero section, headline and main button.
4. Problem: The headline feels cramped against the button, and the button blends into the photo.
5. Desired outcome: The button is the first thing people see, and the headline is easy to scan.

To convert a vague note, reply with the template rather than a pushback. "Thanks! To make sure we change the right thing, can you fill in these five fields for the 'make it pop' note?" Most clients answer within minutes because it takes less effort than explaining.

Mistakes that bring vague feedback back

• Sending files cold. No context, no reasoning, no questions. You get a reflex reaction.
• Collecting feedback across Slack, email, and text. Notes get lost and contradict each other.
• Accepting solution-only notes. "Make the logo bigger" hides the real problem. Ask what the logo needs to do.
• Too many reviewers. One consolidated list beats five separate threads.
• No end point. Without a defined final sign-off, "just one more tweak" never stops. Many of these slips show up in the client portal mistakes small agencies make too.

The tradeoff is real. You'll spend a few minutes of setup per project, and you'll need the discipline to politely send unstructured notes back.

How to know it's working

I don't have measured results to share, and the advice above comes from expert opinion and blog guidance, not controlled research. So test it yourself. First, baseline: for your last five projects, count revision rounds per deliverable, and tag by hand the share of comments that name both a location and a problem. Second, run the four-stage review and the template on your next five projects. Third, compare after six to eight weeks. You're looking for fewer revision rounds per deliverable and a higher share of actionable comments. A spreadsheet or request-thread tags is all the instrumentation you need.

If you'd rather not chase clients for missing details yourself, Dora lets clients ask in plain words, then asks for what's missing and writes the brief, so feedback arrives with context from the start. Your first client is free, forever. What's the vaguest note you've ever received, and what did it turn out to mean?

FAQ

How do you get better client feedback on design?

Share the goals and brief first, show a flat concept with your reasoning, and ask targeted questions tied to the brief. Then collect notes in a fixed format covering location, problem, and desired outcome. Structure does the work that clients usually can't do themselves.

How do you give feedback to a client?

Keep it private, prepare your specific points, state the objective, and tie each comment to the brief. The same applies when you reply to an unclear note: say what you understood, what you'll change, and what you need clarified. Avoid group threads for anything corrective.

What are examples of good design feedback comments?

Good comments name the location, the problem, and the outcome. For example: "This text feels cramped against the button; we need it easier to scan." Another: "The tone feels too playful for a finance audience; we want it to read as trustworthy."

What should you do when a client says "make it pop"?

Don't guess. Ask which element, what feels missing, and what outcome they want. Or send the five-field feedback template and let them fill it in. A structured prompt is faster for them than trying to explain taste in a paragraph.

What is the 70/30 rule in graphic design?

It's a composition guideline about proportion, such as how much space one element takes compared with another. It isn't a method for collecting client feedback. For feedback, use a staged review, targeted questions, and a fixed note format.

How many revision rounds should a design project include?

There's no universal number. Set the rounds in your scope, track your baseline revisions per deliverable, and use the four stages to cap them. Each stage has one job, so a round is used for real changes, not for discovering what the brief should have said.