How to Give Design Feedback That Actually Helps

Design feedback is one of the most common points of failure in founder-designer relationships. Not because founders give bad feedback intentionally, but because feedback that feels clear and direct to you often looks like noise to the designer — and feedback that is genuinely useful is harder to write than it looks.

The result is either a designer who makes changes you didn't want because your feedback was misread, or a designer who ignores your feedback because they don't understand the reasoning behind it. Either way, the revision cycle is longer than it needs to be and the output is worse than it could be.

This post covers how to give feedback that actually helps.

---

The Fundamental Distinction: Direction vs. Opinion

The most important concept in design feedback is the difference between a direction and an opinion.

An opinion is about your personal reaction. "I don't like the blue," "this feels too corporate," "I prefer more whitespace." These are valid signals — you know your brand better than the designer does — but they're not actionable by themselves. The designer doesn't know whether to change the blue, why you don't like it, or what you'd like instead.

A direction is about outcomes, users, or goals. "Users won't understand what this button does without more visual context," "the value proposition isn't clear enough in the first 5 seconds," "this looks too similar to our competitor — we need to differentiate more."

Directions give the designer something to solve. Opinions give the designer a preference to react to. Good feedback is a mix of both — the direction (what's not working and why) with your preference as signal (what kind of solution feels right to you).

Reframe your feedback like this: before you write "I don't like X," ask yourself: "What is the problem X is causing for the user or the goal?" Then write that.

---

How to Frame Feedback Around Goals, Not Aesthetics

Every design deliverable was made to accomplish something: get users to complete a flow, communicate a value proposition, reduce confusion at a decision point. Feedback that connects to those goals is useful. Feedback that doesn't connect to them is noise.

Before you write feedback, remind yourself what the design was supposed to accomplish. You should have this from the brief (see how to brief a designer) — the success criteria you defined before the work started. Teams working with a design subscription service tend to get better output by establishing a consistent feedback rhythm from the first sprint.

Then evaluate the design against those criteria:

• Does the primary CTA stand out clearly?
• Is the user likely to understand the next step without guidance?
• Does this match the tone we need for enterprise buyers?
• Can a new user figure this out in under 2 minutes?

Feedback from this angle sounds like:

• "The primary action isn't visually prominent enough — I'd expect the eye to go there first but it goes to the side panel instead."
• "The empty state doesn't tell the user what to do next. Someone seeing this for the first time will be stuck."
• "This is great for power users but the entry point for new users is still unclear."

Compare those to pure aesthetic feedback like "the colors feel off" or "this is too busy." The goal-oriented versions tell the designer exactly what to fix. The aesthetic versions require the designer to guess what the underlying concern is.

---

The Difference Between Solving and Diagnosing

One of the most common feedback mistakes is proposing a solution instead of diagnosing a problem. This sounds harmless but it actually limits the quality of the outcome.

"Move the button to the top right" tells the designer what you want them to do. It doesn't tell them why. And it removes the designer's ability to propose a better solution than moving the button.

"The button is hard to find — users probably lose it because it sits below the fold" tells the designer the problem. They might move it to the top right. They might make it more visually prominent where it is. They might add an affordance that draws attention to it. You get three possible solutions instead of one.

There are times when specifying the solution is right — when there's a technical constraint, a design system rule, or a business requirement that determines the answer. In those cases, say that explicitly: "The button needs to be in the top right because of our existing layout convention." That's a constraint, not feedback.

When it's not a constraint, describe the problem and let the designer solve it.

---

Async vs. Sync Feedback

The best format for feedback depends on the complexity of what you're reviewing and how aligned you and the designer are.

When async feedback works well

• Straightforward revisions (one specific change, clear direction)
• When you've worked together long enough that context is shared
• When the feedback is better expressed in writing than speech (precise language, specific elements)
• When you're in different time zones

Good async feedback is written in a way that anticipates questions and addresses the "why" proactively. If the designer has to ask a clarifying question, you've left something important out.

When sync feedback works better

• First review of a new concept where there's a lot to discuss
• When the feedback is complex and involves multiple interdependent concerns
• When you're misaligned on direction and need to get on the same page quickly
• When the work isn't working at all and you need to have an honest conversation about why

A 30-minute call can compress what would be 3 rounds of async revision into one. Don't use sync feedback for simple revisions — that's inefficient — but don't avoid it when alignment is genuinely needed.

---

What Good Written Feedback Looks Like

Written feedback has a specific challenge: tone is invisible. Feedback that reads as blunt or dismissive in text was probably meant to be direct and constructive. For most designer-founder relationships, the easiest way to solve this is to be explicit about intent: "This is good overall — I have a few things I want to work through on the main flow." Then the notes don't feel like an indictment.

Good written feedback:

• Is specific about location. "The header" is vague. "The H1 on the hero section" is specific. In Figma, point to the exact frame or element.
• Says what isn't working and why. Not just "change this" — tell the designer what the underlying problem is.
• Distinguishes between must-fix and nice-to-have. "This is blocking" vs. "if there's time, I'd love to see..."
• Separates concerns. One note per issue. Don't bundle three things into one paragraph.
• Ends with a clear ask. What do you want to see in the next version? Revised screens? Options? Just one element updated?

Example of weak written feedback:

"This doesn't feel right. The main page seems busy and the navigation is confusing. Can we try something different?"

The designer now has to guess what "doesn't feel right" means, what specifically is busy, why the navigation is confusing, and what "something different" refers to.

Example of useful written feedback:

"A few things:

1. Hero section — the value proposition isn't landing. The headline is vague and a first-time visitor won't know what the product does from the headline alone. Can we try a version that names the specific outcome? (Example: instead of 'Intelligent revenue operations,' something like 'Close more pipeline with less manual tracking.')

2. Navigation — the dropdown has 8 items, which is a lot. Can you explore a version where the secondary items are deprioritized or grouped? Don't need solutions yet — just want to see your thinking.

3. CTA button — this is working well. Keep it.

The overall visual direction is right — I just want the copy to do more work. No need to revisit the layout."

---

How Many Rounds of Revision Is Too Many?

Revision rounds are normal. Design rarely lands perfectly on the first attempt. But if you're on round 5 or 6 on a single deliverable, something has gone wrong — and it's almost always either the brief or the feedback.

Brief problems that cause excessive revision:

• The brief didn't clearly define success criteria, so each round of feedback reveals a new goal
• The brief had conflicting requirements that weren't resolved upfront
• Multiple stakeholders are giving feedback and they're not aligned

Feedback problems that cause excessive revision:

• Feedback is too vague (the designer guesses, guesses wrong, gets corrected)
• New feedback is introduced in each round rather than addressing the current design
• Aesthetic opinion is driving revisions without a clear endpoint

Two to three revision rounds is normal for complex work. For simpler deliverables, one should often be enough if the brief was clear. If you're consistently going beyond three rounds, stop and diagnose: is the problem in the brief, the feedback, or the alignment between stakeholders?

---

The Stakeholder Consolidation Problem

One of the most common friction points in design reviews is feedback from multiple stakeholders arriving separately at the designer — and conflicting with each other.

The CEO says "the colors are too dark." The CMO says "it needs more energy and impact." The VP of Product says "we need to focus on clarity, not aesthetics."

The designer is now expected to reconcile three contradictory mandates. They can't. What usually happens is they make a compromise that satisfies none of them, and round three looks very similar to round two.

Fix this before it starts: assign one person to consolidate all stakeholder feedback before it goes to the designer. That person's job is to resolve internal disagreements (not pass them to the designer), prioritize the notes, and send a single unified set of feedback.

This is uncomfortable — it means someone has to say "the CEO's color note is overruled by the product clarity goal" — but it produces dramatically better output.

---

Feedback on Work You Don't Like vs. Work That Doesn't Work

These are different situations that require different responses.

Work that doesn't work is a design that fails at its goal: users won't understand the flow, the hierarchy is wrong, the layout doesn't support the primary action. This is feedback territory — describe what isn't working and why, and ask for a revision.

Work you don't like is a design that achieves its goal but isn't to your personal taste. This requires more self-awareness. Ask yourself: is this a user problem, a business problem, or a personal preference? If it's a personal preference, say so explicitly ("this is a personal taste note, not a functional one") and trust the designer to weigh it appropriately.

Senior designers will sometimes push back on personal taste feedback — particularly when it conflicts with what's right for the user. That pushback is valuable. A designer who just does whatever you ask is a Figma operator. A designer who pushes back with reasoning is a partner.

Learn to tell the difference between the designer being stubborn and the designer being right.

---

A Simple Feedback Template

For async feedback on a design review:

Overall: [One sentence on overall direction — is this close or not close?]

What's working: [At least one thing — don't skip this, even if the work needs significant changes]

What needs to change:

• [Specific element] — [What's not working and why] — [Is this a must-fix or nice-to-have?]
• [Next element]

What I'd like to see next: [What format should the revision take? Full screens? Just one element? Options?]

When do I need it: [Date, and why if relevant]

This format takes five minutes to fill out and saves everyone hours of guessing.

---

Frequently Asked Questions