"Make it pop more." "I'll know it when I see it." "Can you make it feel more premium?"

If you have ever found yourself saying something like this to a designer, and then watching their face do that polite-but-slightly-pained thing, you are not alone. Giving feedback on design work is one of the most common pain points in any client-agency or founder-designer relationship, and it goes both ways. Designers struggle to act on vague feedback, and clients struggle to articulate what is bothering them about a design they cannot quite put into words.

The good news is that giving useful design feedback is a skill, not a talent, and it does not require any design background. This post walks through how to give feedback that designers can actually act on, so revisions move faster and the end result is closer to what you actually wanted.

Why Design Feedback Goes Wrong So Often

Before getting into how to do it well, it helps to understand why it tends to go badly.

Feedback Often Describes Feelings, Not Problems

Phrases like "it doesn't feel right" or "something is off" are honest reactions, but they are not actionable. A designer receiving this feedback has to guess what specifically is causing that reaction, which color, layout, spacing, or element, and may guess wrong, leading to a revision that still does not address the actual issue.

Feedback Often Jumps Straight to Solutions

A common pattern is feedback like "make the button red" or "move the logo to the right." These are solutions, not problems. The issue is that the person giving feedback is not always right about which solution actually fixes the underlying problem, and jumping to a solution skips over information the designer needs: what is the actual issue this is meant to solve?

Feedback Often Arrives Without Context

A comment like "I don't like this screen" tells a designer almost nothing. Is it the colors? The layout? The amount of text? Compared to what? Without context, designers are left trying to read between the lines, which slows everything down.

The Core Principle: Describe the Problem, Not the Fix

The single most useful shift in how to give design feedback is this: focus on describing what is wrong or what is not working, and let the designer propose the solution. This is not about deferring to the designer out of politeness, it is about giving them the information they actually need to solve the problem well, because they may know solutions you have not thought of.

Instead of This, Try This

"Make it pop more" becomes "This section feels like it blends in with everything else on the page, and I want it to stand out as the main thing someone notices first." "Make the button bigger" becomes "I tried clicking this on my phone and almost missed it, it felt easy to overlook." "Can you make it feel more premium?" becomes "Compared to [competitor or reference], this feels more playful than I expected for our brand. Can we explore something that feels a bit more polished or established?"

In each case, the second version gives the designer a goal and a reason, rather than a specific instruction that may or may not actually solve the underlying issue.

How to Structure Feedback So It Is Easy to Act On

Beyond the core principle, a few structural habits make a big difference in how quickly and accurately feedback gets addressed.

Be Specific About Location

"The text on the homepage is too small" is better than "the text is too small," but "the body text under the main heading on the homepage feels too small to read comfortably on mobile" is even better. The more precisely you can point to what you are referring to, the less time gets spent on back-and-forth clarification.

Separate Must-Fix From Nice-to-Have

Not all feedback carries the same weight. A button that is genuinely too small to tap on mobile is a different priority than a personal preference about a shade of blue. When giving a batch of feedback, it helps to indicate which items are blocking issues and which are preferences or suggestions, so the designer can prioritize accordingly.

Give Feedback on the Whole, Not Just the Parts

It is easy to fall into the trap of commenting on individual elements, this color, that spacing, without stepping back to evaluate whether the overall design achieves its goal. Before diving into details, it can help to ask: does this screen do what it needs to do? Does it make the next step obvious? Does it feel consistent with the rest of the product? Then move into specifics.

Reference Real Examples When Possible

If you have seen a design pattern elsewhere that captures what you are looking for, sharing it is far more useful than trying to describe it in words. This is not about copying another product, it is about giving the designer a concrete reference point for the kind of feeling, layout, or interaction you mean.

What to Avoid When Giving Feedback

A few common habits tend to slow down the design process or create friction, even when the intent behind them is reasonable.

Avoid Feedback Based on Personal Preference Alone

It is natural to have personal opinions about colors, fonts, or styles. But it is worth pausing to ask whether a reaction is based on what works for the target users, or simply a personal taste that may not reflect how your audience will respond. Framing feedback around the user's experience, rather than your own preference, tends to lead to better outcomes.

Avoid Giving Feedback in Isolation From the Goal

A design choice that looks unusual in isolation might make complete sense in the context of the overall user flow. Before flagging something as a problem, it can help to consider it within the full journey: does this choice cause a problem for the user trying to complete a task, or does it just look different from what you expected?

Avoid Reopening Settled Decisions Without New Information

If a decision was discussed and agreed upon earlier in the project, revisiting it repeatedly without new information, such as user testing results or a changed business requirement, slows down progress and can frustrate a design team that has already moved past that stage. If something genuinely needs to change, it helps to explain what has changed since the original decision was made.

A Simple Framework for Structuring Feedback

When reviewing a design, it can help to organize feedback into three categories:

What is working well. This is often skipped, but it matters. Knowing what to keep helps a designer avoid accidentally changing something that was actually fine while addressing other issues.

What is not working, and why. This is the core of useful feedback, described in terms of the problem, not the solution, and as specific as possible about what part of the design is involved.

Open questions or things you are unsure about. Sometimes you know something feels off but are not sure why, or you are torn between two directions. Saying so explicitly, rather than picking one and presenting it as a firm decision, gives the designer room to explore and suggest options.

This structure takes roughly the same amount of time as writing unstructured feedback, but it gives a designer far more to work with, and tends to result in fewer revision rounds overall.

When You Genuinely Do Not Know What Is Wrong

Sometimes a design just feels off and you cannot articulate why, and that is a perfectly valid starting point. In these cases, it is more useful to say that directly rather than inventing a specific critique to sound more decisive. "Something about this doesn't feel right to me, but I can't pinpoint what, can we look at it together?" gives a good designer something to work with: they can walk through their reasoning, point out specific choices, and often help surface what is actually bothering you.

This kind of collaborative back-and-forth, rather than a one-way list of instructions, tends to produce better results than either side guessing in isolation.

The Bottom Line

Good design feedback is not about having the right vocabulary or design knowledge. It is about describing problems clearly, being specific about what you are referring to, and giving the designer room to propose solutions rather than dictating them outright.

The next time you find yourself about to say "make it pop" or "I'll know it when I see it," try pausing and asking: what specifically is not working, and for whom? That single shift in framing tends to be the difference between a design process that drags through endless revisions and one that converges quickly on something everyone is happy with.