How to Give Design Feedback That Improves the Work

TL;DR: What You Will Learn

• Vague reactions like “make it pop” waste redesign cycles because they carry no direction.
• Ground every comment in what you observe, then explain the rationale behind it.
• Ask questions before you prescribe solutions, so you understand the designer’s intent.
• Offer suggestions as options, not orders, and always agree on a clear follow-up.
• Deliver it face-to-face where you can, and separate personal taste from project goals.

Why Design Feedback So Often Fails

Before I hand you any technique, I want to diagnose why so much feedback goes wrong in the first place. Most of the time it is not that people are careless; it is that they react instead of respond.

Picture a common Singapore scenario. A startup marketing manager opens a Slack thread at 6 PM, sees a landing page draft from the designer, and fires off “hmm, I don’t like the blue, can we make it pop more?” No brief attached, no goal stated, just a reaction typed between meetings.

The designer now has to guess what “pop” means, why blue was rejected, and what problem the page is actually meant to solve. That guessing is where projects quietly lose days.

Feedback as Opinion Versus Direction

The single biggest reason design feedback fails is that we give opinions when the work needs direction. “I don’t like blue” is a preference. “Our checkout button isn’t getting clicks, so the primary action needs to stand out more” is direction.

Opinions invite endless back and forth because there is no shared standard to measure against. Direction points at the outcome, which lets the designer solve the problem their own way.

This matters even more when you confuse craft with purpose. If you are unsure why a screen looks the way it does, it helps to understand the difference between UI and UX, because a colour comment is a UI reaction while a conversion problem is a UX concern.

Missing Shared Goals

Feedback also fails when nobody agrees on what “good” looks like before the work starts. In that Slack thread, the manager and designer never confirmed whether the landing page was optimising for signups, credibility, or launch speed.

Without a shared goal, every reviewer becomes a self-appointed judge, and each brings a different yardstick.

I have watched a single design go through five review rounds simply because the founder, the sales lead, and the marketer each optimised for something different, and none of it was written down anywhere.

The Cost of Vague Comments in Rework Hours

Vague feedback is expensive, and the bill arrives as rework. Every “make it more premium” or “it feels off” sends the designer back to explore directions that may miss the actual concern entirely.

Multiply that by a small team billing client hours, and you can lose most of a working week to comments that could have been precise in the first place.

This is exactly why structured teams, including those trained through SkillsFuture-supported UX courses, treat feedback as a repeatable process rather than a mood. They anchor every comment to a goal and a rationale.

The rest of this article gives you that structure, so your next review moves the work forward instead of in circles.

Anchor Every Comment to the Goal

The fastest way to derail a design review is to open with “I don’t like the blue.” When I coach teams on how to give design feedback, the first shift I push for is simple: start from the design’s objective, not your personal taste.

Start From the Brief, Not Your Gut

Every design exists to solve a problem for a user and to move a business metric. Both of those should have been agreed upon at the brief stage, so that is where your feedback should live.

Before you type a single comment, ask yourself one question: what is this screen meant to achieve? If you cannot answer that, you are not ready to give feedback yet; you are ready to reread the brief.

I keep the original problem statement pinned at the top of every review doc. When someone drifts into “I’d have used a carousel here,” I point back to it and ask how that helps the stated goal.

A Singapore Checkout Example

Picture a small Singapore e-commerce team optimising a Shopee-style checkout to lift conversion. The agreed goal at the brief stage was clear: reduce cart abandonment by cutting friction at payment.

Now every comment gets judged against one yardstick: does this reduce friction? “Move the PayNow option above credit card because most of our shoppers pay that way” is anchored to the goal. “I think the button should be teal” is not.

That single filter changes the tone of the whole session. Instead of ten people voicing preferences, you get ten people testing ideas against the same question, which is far easier to resolve.

You can see the same discipline in a content marketing strategy that supports your goals: the work is only good if it serves the objective, and feedback should measure exactly that.

Give the Designer a Yardstick to Push Back

Goal-anchored feedback does something powerful for the designer too: it gives them a fair way to defend their choices.

When you say “this layout doesn’t support the conversion goal,” the designer can respond with evidence, perhaps a user-testing note showing the current flow tested well. That is a real conversation, not a standoff of opinions.

Compare that to “I just don’t like it.” There is no yardstick, no evidence, and no way for the designer to push back except to guess what you actually mean.

So keep bringing every comment home to the goal. It strips out the emotion, keeps the review objective, and turns feedback into something the designer can actually act on with confidence.

Be Specific Enough to Act On

If there is one thing I have learned about how to give design feedback that actually moves the work forward, it is this: a designer cannot act on a feeling. They can only act on a precise, located observation.

Vague reactions like “this feels off” or “make it pop” send the designer guessing. Precise feedback hands them a clear target.

Name the Exact Element and Location

Start by pointing to the specific thing you are reacting to and where it sits on the screen.

“The CTA button below the fold” is useful. “The button” is not, especially on a page with four of them.

I once reviewed a government service portal form, the kind Singapore residents use to renew a licence or apply for a scheme. My first instinct was to say the form “felt hard to fill in”. That helped nobody.

When I looked properly, the real issue was that the field labels sat too far from their input boxes, so people were unsure which label belonged to which field. Naming that exact element pointed the designer straight to the fix.

Describe the Observed Effect, Not a Label

The second habit is to describe what you actually noticed happening, rather than slapping on a summary word like “cluttered” or “messy”.

Compare these two comments. “This hero feels cluttered” is a label. “The three competing headings in the hero make it unclear where to look first” describes the effect and the cause.

The second version does the designer’s diagnostic work with them. It tells them the problem is visual hierarchy, not that they need to delete something at random.

When you describe the effect, you also open a real conversation. The designer might reply that two of those headings are placeholders, and now you are solving the right problem together.

Quantify Where You Can

Numbers turn opinion into something testable, so reach for them whenever the observation allows.

Instead of “the spacing looks tight”, try “there are only a few pixels between the label and the input, which is why they read as one blur”. If you know a little about spacing and layout from something like these Figma design basics every beginner should master, you can point to the specific gap or alignment that needs adjusting.

Here is a quick way to pressure test your own feedback before you send it:

• Have I named the exact element and where it appears on the screen?
• Have I described what I observed, not just labelled it?
• Can I attach a number, a count, or a distance to make it checkable?

Specificity is not pedantry. It is respect for the designer’s time.

When I give a located, described, and quantified note, the designer usually fixes it in one pass instead of three. Vague feedback triggers long revision loops where everyone guesses; specific feedback shortens them dramatically.

That is the heart of the method, and everything else builds on it.

Always Give the Reason Behind the Comment

The single biggest upgrade I made to my own feedback was simple: I stopped giving instructions and started giving reasons.

When you say “make the button blue” or “move this to the top,” you are handing over a solution and asking the designer to guess at the problem. A comment without a why forces guesswork, while a comment with a why lets the designer solve the real problem their own way.

The Observation Plus Rationale Pattern

Here is the pattern I lean on every single time. State what you observed, then state why it matters.

“The primary and secondary buttons look almost identical (observation), so users cannot tell which action you actually want them to take (rationale).”

Notice what this does. I have not told the designer to change the colour, add a border, or shrink the secondary button. I have named the real problem, and now they can reach for whatever solution fits their design system best.

That is the difference between feedback that creates dependency and feedback that builds capability. When you keep handing over pixel-level fixes, the designer learns to wait for you. When you hand over the reasoning, they learn to catch the same issue themselves next time.

Tie Rationale to Outcomes The Team Cares About

Rationale gets far more persuasive when you connect it to a business outcome the whole team is watching.

I once reviewed the onboarding flow for a Singapore fintech app where new users had to link a bank account before they could do anything useful. My comment was not “this screen feels cluttered.” It was: “There are five input fields and no progress indicator here, so users cannot tell how close they are to finishing, and that uncertainty is exactly where we tend to see drop-off in onboarding.”

Suddenly, the feedback was not my taste against the designer’s taste. It was both of us against the drop-off rate. That reframing turned a defensive conversation into a shared problem-solving session.

Cite Principles and Data, Not Just Opinion

You strengthen your rationale enormously when you anchor it to something outside yourself.

• A usability principle, such as visual hierarchy, contrast, or recognition over recall.
• Real user data, like session recordings, support tickets, or funnel analytics.
• An accessibility standard, for example, insufficient colour contrast failing WCAG guidance.

“I do not like this shade of grey” is an opinion, and a designer can reasonably disagree. “This grey text on a white background is hard to read for older users, which matters given our customer base” is a case grounded in something real.

Give the reason, and your feedback stops being a command and starts being an argument the designer can actually learn from.

Separate the Problem From the Solution

The single most useful habit I have learned about how to give design feedback is this: name the problem you see, then stop. Resist the urge to hand over your fix.

When you jump straight to a solution, you accidentally hide the real issue and box the designer into your idea.

Why 'Make the Logo Bigger' Hides the Real Issue

“Make the logo bigger” is the classic. It sounds concrete, but it tells the designer almost nothing about what is actually wrong.

Usually the real problem is that the brand feels invisible, or a first-time visitor cannot tell whose website this is within a few seconds. That is a very different brief.

Once the designer knows the underlying problem, a bigger logo might be one answer, but so might a stronger colour, a clearer tagline, or better placement in the header. You have opened doors instead of closing them.

Phrase the Problem So the Designer Owns the Solution

The trick is to describe your experience, not to issue an instruction. I try to say what I felt, saw, or could not do, and let the designer decide how to respond.

Compare these two comments on the same screen:

• “Move the button to the top.” (a solution, and possibly the wrong one)
• “I couldn’t find where to sign up; I scrolled past it twice.” (a problem the designer can solve)

The second version respects the designer’s craft. It says, “Here is the goal; you know the tools better than I do.”

I picture a Singapore agency reviewing a landing page for an SME retail client. The client keeps saying “add three more banners” and “use a red button”. The designer calmly reframes it: the real goal is more enquiries during a promotion, so we test a single clear offer and a prominent enquiry form instead. The client, once they hear the goal stated back, almost always relaxes and trusts the designer to find the strongest route.

When a Suggestion Is Welcome, and When It Oversteps

Suggestions are not banned. They just work best framed as options, not orders.

I like to say, “One option might be pinning the nav bar, but you may have a cleaner idea.” That signals a possibility while leaving ownership with the designer, who is often exploring variations in Figma anyway (it helps to understand what Figma is used for in real design teams before you assume a fix is simple).

This is not just my preference; it is how some of the most respected creative teams work. Ed Catmull, the Pixar co-founder behind the studio’s famous “Braintrust” review sessions, makes the same case in his book Creativity, Inc. A good note, he argues, names what is wrong, missing, or unclear, but “doesn’t even have to include a proposed fix.” Where it does suggest one, that suggestion is only there to hint at a direction, never to dictate it, which keeps ownership of the solution with the person who actually has to build it.

You overstep when you dictate colours, layouts, or type as if they are non-negotiable. Hold back the prescription, trust the process, and you will consistently get more creative, more effective work than the fix you would have forced.

Ask Questions Instead of Issuing Verdicts

When you tell a designer “the menu is wrong,” you close the conversation before it starts. When you ask, “What led you to place the menu here?” you open one.

That difference is the heart of how to give design feedback that actually improves the work rather than just asserting your taste over someone else’s.

The Designer Has Probably Thought About It Already

Here is something I have learned the hard way over years of reviewing design: the thing you spotted in ten seconds, the designer likely wrestled with for hours.

A verdict assumes you know better. A question assumes there might be a reason you cannot yet see, and it invites the designer to show you.

Let me walk you through a scenario of the kind I have seen play out in Singapore SME website reviews.

The reviewer, a marketing manager, wanted to open with “the primary call to action button is buried too far down the homepage.” Instead, she asked, “What shaped the decision to place the sign-up button below the hero image?”

The designer explained that most of this retailer’s traffic came from mobile, so the layout was built mobile-first. On a phone screen, the button sat comfortably within the first scroll. The reviewer had been looking at a desktop mockup and had missed the constraint entirely.

Had she led with a verdict, she would have sent the team chasing a fix for a problem that did not exist on the device most of their customers actually used.

Questions Build Safety Across Seniority Gaps

There is a second reason questions matter, and it is about people, not pixels.

In many Singapore workplaces, a junior designer will rarely push back on a director’s blunt “change this.” They will simply comply, even when they disagree, and the work quietly gets worse.

An open question lowers that pressure. It signals that you are curious rather than commanding, and it gives the more junior person permission to explain their reasoning without feeling they are contradicting someone above them.

That is psychological safety in practice, and it turns a one-directional handover into a genuine two-way dialogue.

Slot The Question Into The Sequence

The question is not a replacement for the rest of your feedback. It is one step in a sequence: observation, rationale, question, then suggestion.

You still name what you noticed and why it matters to you. But before you leap to your fix, you pause to ask what the designer was solving for.

A well-placed question can save you from a suggestion you would have regretted. More often than not, the answer either sharpens your feedback or dissolves the concern completely, and both outcomes leave the work better than a verdict ever would.

Prioritise What Matters Most

Picture a Singapore product team pushing to ship an MVP before a sprint deadline. The designer submits a checkout flow for review, and by lunchtime the Figma file has thirty comments, all sitting at the same weight.

That is not feedback. That is paralysis dressed up as thoroughness.

The single most important skill in learning how to give design feedback is knowing what to fix first. When everything is urgent, nothing is, and the designer burns hours guessing which comments actually threaten the launch.

Separate Blockers From Nice-To-Haves

Before you type anything, ask one question of each comment: does this stop the MVP from shipping, or is it a preference you would like to see one day?

A broken PayNow confirmation state on that checkout flow is a blocker. The button corner radius being 6px instead of 8px is a nice-to-have.

On a tight sprint, blockers get fixed this round, and nice-to-haves go into a backlog note. Mixing the two forces the designer to context-switch between saving the release and polishing details that no user will notice at launch.

I tell reviewers to write the nice-to-haves down somewhere visible, so the designer knows you saw them and chose to defer them. That reassurance matters for morale.

Tag Comments By Severity

Give every comment a label so intent is unmistakable. I use three tiers:

• Critical: Breaks the flow, blocks the release, or creates a PDPA or accessibility risk. Fix now.
• Major: Meaningfully hurts usability or conversion but will not stop shipping. Fix this round if time allows.
• Minor: Polish, preference, or future improvement. Log it and move on.

When a designer opens a file and sees five comments tagged critical and the rest tagged minor, they know exactly where to start. This kind of triage instinct is also what strong candidates demonstrate, and it shows up in the UX designer interview questions hiring managers ask when they probe how someone handles competing priorities under pressure.

Cap Your High-Priority Items Per Round

Even with good tags, a wall of critical comments overwhelms. Discipline yourself to no more than three to five high-priority items per review cycle.

If you genuinely have ten critical issues, that is a signal the direction needs a conversation, not a comment thread. Book a fifteen-minute call instead.

Limiting the top-priority list is a courtesy, not a compromise. It tells the designer that you respect their time and the deadline, and it lets them ship the version that protects the release rather than chase every note at once.

Prioritised feedback speeds delivery and keeps the team sane. That is worth far more than a comprehensive list nobody can act on.

Close the Loop by Following Up

Here is the mistake I see most often: someone gives thoughtful feedback, then walks away and assumes the work will magically improve. It rarely does.

Feedback is not finished the moment you hit send. The real value of learning how to give design feedback comes from closing the loop, confirming the designer understood you, and checking that the revision actually solved the problem.

Confirm The Interpretation Before The Redraw

The most expensive rework happens when a designer misreads your comment and spends a day fixing the wrong thing.

So before the next round starts, I ask the designer to play back what they heard. A quick “here is how I plan to change this” confirms you are aligned on both the problem and the direction.

That small pause saves hours. It also surfaces cases where the designer disagrees, which is often where the best solutions come from.

Track Every Item From Raised to Resolved

I worked with an in-house product team here in Singapore that ran everything through a shared Figma comment thread. Each piece of feedback lived as a pinned comment right on the artboard.

They treated every comment like a mini ticket with a clear status: raised, interpreted, revised, resolved. When the designer pushed an update, they replied on the same thread so the reviewer could compare the fix against the original ask without hunting through Slack.

When you review the revised work, hold it against the exact comment you made. Did the new spacing solve the crowding you flagged, or did it just move it somewhere else? If you are new to working inside these threads, a step-by-step Figma tutorial for beginners will help you keep comments and versions organised.

And when a designer nails a fix, say so. Acknowledging good work is not fluff; it tells the person which instincts to keep repeating.

Document Decisions So They Become Standards

Every resolved comment is a small decision. If you throw it away, you will debate the same thing next month.

So capture the recurring ones. When a team keeps flagging inconsistent button padding or the same weak call to action, that pattern belongs in a shared style guide or component library, not in a hundred separate comment threads.

That is how one-off feedback turns into a team standard. The follow-up stops being a chore and starts being how your team gets better.

Consistent follow-up, reinforced by structured training such as SkillsFuture-funded design courses, is what converts scattered comments into lasting skill growth. The individual feedback fades, but the standards and the habits stay.

Conclusion

Remember the frustration we started with: rounds of revisions that circle the same problems, a designer who looks a little more deflated each time, and a final product that still misses the mark.

None of that comes from a lack of talent. It comes from feedback that points in no clear direction.

The good news is that how to give design feedback well is a repeatable method, not a personality trait you are either born with or not. Every strong reviewer I have watched, whether a product manager in a Singapore fintech or a marketing lead at an SME, works through the same moves.

To recap, the method works like this: anchor every comment to the goal you agreed on rather than personal taste; be specific about what you are reacting to and give your rationale; separate the problem from your proposed solution, and ask questions before you prescribe; and prioritise ruthlessly so the designer knows what matters most, then follow up to close the loop.

When you do this, the wasted cycles fall away. Your designer stops guessing, starts solving the right problem, and begins to trust that your feedback makes the work better rather than just longer.

You do not need to adopt all of this at once. Pick one habit this week, perhaps opening each review by restating the goal, and notice how the conversation changes.

Reading about better feedback is one thing; building the structured thinking behind it is another. If you want to work confidently from user problems to tested solutions, and give critique that consistently moves the work forward, that is exactly what a formal design practice teaches you.

Take the next step: explore the UX/UI Design Career Programme at Equinet Academy to build those skills end to end, or start with the Design Thinking Course if you want to sharpen how you frame problems and evaluate design decisions first. Either way, you will leave the guessing behind and start giving feedback that makes the work better, not just longer.