"I don't love it" and "can you make it pop more" are genuinely common pieces of design feedback, and both are close to useless as instructions, not because the person giving them is doing anything wrong, but because they describe a reaction rather than a direction, and a designer or developer can't reliably turn a reaction into a specific change.
Why Vague Feedback Produces Frustrating Revision Cycles
When feedback describes how something feels without saying why or what to change, a designer has to guess at the underlying meaning, make a change based on that guess, and hope it lands. If it doesn't, another round of vague feedback follows, and the cycle repeats. This is the actual source of most drawn-out, frustrating design revision rounds, not designers failing to deliver, but feedback that gives them nothing concrete to actually act on.
Start With the Goal, Not the Reaction
The single most useful shift in giving design feedback is anchoring it to what the design is actually supposed to accomplish, rather than how it makes you feel in isolation. "This feels too corporate" is a reaction. "We're trying to feel approachable and friendly to first-time customers, and this feels more like a bank than a neighbor" ties the same reaction to a real, specific goal, which gives a designer something concrete to work toward.
Point at Specific Elements, Not the Whole Thing
"I don't like the header" is far more useful than "I don't like it," and "the header text feels too small compared to the hero image below it" is more useful still. The more precisely feedback identifies exactly which element is the issue, and what specifically about it isn't working, the less guessing a designer has to do about what to change.
Describe the Problem, Not the Solution
This surprises a lot of people, but the most effective feedback usually describes what's wrong or unclear rather than prescribing a specific fix. "I couldn't find where to book an appointment" is more useful than "make the button bigger and red," since the actual problem, a visitor can't find the primary action, might have several possible solutions, and a designer is usually better positioned to choose the right one than a non-designer prescribing one specific fix without full visibility into everything else on the page.
Use Real Reference Points
"Something more like this site's checkout page" with an actual link gives a designer a concrete, shared reference that no amount of abstract description matches, and it doesn't need to be from your own industry. A specific layout, color palette, or interaction from a completely different site can still communicate exactly the direction you're reaching for.
Separate Gut Reaction From Considered Feedback
Both are useful, and worth distinguishing. A genuine first reaction, "this felt confusing the moment I saw it," is real, valuable data about how a real visitor might respond. A considered piece of feedback, "after looking closer, the navigation labels don't match how our customers actually describe our services," is different and complementary. Labeling which kind of feedback you're giving helps a designer weigh it appropriately rather than treating an offhand reaction and a considered concern as identical in weight.
Consolidate Feedback Before Sending It
Feedback arriving in a scattered stream of separate messages over several days, sometimes contradicting earlier ones, is much harder to act on than a single, organized round of consolidated feedback, ideally reviewed once for consistency before sending. If multiple stakeholders are involved, agreeing internally on a single unified set of feedback before it reaches the designer avoids the common, painful situation of a designer receiving conflicting direction from different people on the same team.
Say What's Working Too
Feedback consisting entirely of problems gives a designer no information about what to preserve, and revisions can sometimes accidentally change or remove something that was actually working well. Explicitly noting what's genuinely working, "the color palette feels right, keep that," prevents unintended changes to good elements while addressing the ones that actually need work.
A Simple Structure That Works
What I was trying to do or understand when I looked at this, the real goal behind the reaction.
What specifically worked or didn't work, pointing at specific elements, not the design as a whole.
Why, in terms of the goal, not just personal taste.
Any reference examples that communicate direction more clearly than words alone can.
This takes a few extra minutes per round of feedback and consistently produces faster, more accurate revisions than an unstructured "here's what I think" message ever does.
Frequently Asked Questions
What if I genuinely can't articulate why something doesn't feel right? That's completely normal and worth saying directly, "something about this feels off, but I can't pinpoint it." A good designer can often help identify the specific issue through a few questions, and being honest about uncertainty is more useful than inventing a specific-sounding reason that doesn't actually reflect what's bothering you.
Is it okay to just say I don't like something without explaining why? A gut reaction is still valid information, and a designer would rather know about it than not. It just works best as a starting point for a conversation, "this feels wrong to me, can we talk through why," rather than as the entire feedback, since it doesn't give a clear direction on its own.
How many rounds of revisions is reasonable to expect? This depends on the agreed scope, covered in an earlier post on contract terms, but clear, specific, consolidated feedback typically reaches a good result in fewer rounds than vague, scattered feedback does, which is the practical, tangible benefit of investing a little more effort in each round.
If you're working through a design review and want help translating a gut reaction into feedback a designer can actually use, I'm happy to help.
Get in touch: https://pixelanas.com/contact
Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751
