How to Give Design Feedback That Actually Helps

Design feedback is one of the most valuable things a team can give each other — and also one of the most commonly done badly. Vague, prescriptive, or taste-based feedback doesn't help the designer improve the work. It just adds noise and erodes trust.

Here's how to give feedback that's actually useful.

Critique vs criticism

These words get used interchangeably, but they mean different things in a design context.

Criticism judges the work — "this looks cheap," "I don't like the layout," "the colors are off." It's evaluative without being constructive.

Critique analyzes the work against its goals — "the hierarchy doesn't direct the eye to the primary action," "the spacing feels inconsistent between these two sections." It's specific, grounded in intent, and gives the designer something to work with.

Your job as a feedback giver is to critique, not criticize. That means understanding what the design is trying to do before you say anything about it.

The feedback framework: specific, actionable, not prescriptive

Every piece of useful feedback has three properties.

Specific means it references something real — a component, a flow, a piece of copy. "The onboarding flow feels long" is too vague. "Steps 3 and 4 in the onboarding flow both ask for account details — could they be combined?" is specific.

Actionable means the designer can do something with it. "This doesn't feel right" isn't actionable. "The button label says 'Submit' but the action is creating an account — a more specific label like 'Create account' might reduce hesitation" is.

Not prescriptive means you're flagging the problem, not dictating the solution. "Make the header smaller" is prescriptive. "The header is competing with the primary CTA for attention" identifies the problem and lets the designer solve it their way. The exception is when you genuinely have a specific solution to suggest — in which case frame it as a suggestion, not a directive: "One option would be to reduce the header size, but you might have another approach."

Ask questions instead of giving directives

Questions are underrated as a feedback tool. They create dialogue instead of monologue, and they often surface information that changes what feedback is even relevant.

Before saying "I think the navigation should be on the left," try "What led you to put the navigation at the top?" The answer might be that mobile-first design drove that decision, or that user testing already showed it working. Now you're having a conversation instead of a standoff.

Good questions to have ready:

• "What were you trying to solve with this?"
• "Have you explored any alternatives to this pattern?"
• "How does this handle [edge case]?"
• "What would a new user see the first time they land here?"

Separating personal preference from UX problems

This is where feedback most often goes wrong. Personal taste ("I prefer rounded corners to square ones") isn't the same as a usability problem ("the form error messages aren't visible enough for users with low vision").

Before giving feedback, ask yourself: is this about my taste, or is this about whether the design works for the user? If it's taste, either skip it or flag it explicitly — "this is just personal preference, but..." If it's a real UX or product issue, give it weight.

The test: can you connect your feedback to a user goal, a business requirement, or an accessibility standard? If yes, it's worth saying. If you can only connect it to your own preference, be honest about that.

Written vs verbal feedback

Both have their place.

Verbal feedback (in a review session) is better for exploratory, high-level discussion. It allows back-and-forth, lets you read the room, and is good for alignment conversations where the direction isn't locked yet. The downside: it's hard to track, gets forgotten, and can become a debate rather than a working session.

Written feedback (async, via Figma comments or a Notion doc) is better for specific, detailed notes on a design that's closer to done. It creates a record, forces clearer thinking (you can't ramble as easily), and lets the designer process notes at their own pace before responding.

The best flow: use a brief verbal review to align on goals and direction, then follow up with written notes on the details.

Async feedback in Figma comments

Figma comments let you pin feedback directly to the relevant part of a design. Used well, this is one of the most efficient ways to give detailed notes.

A few rules for Figma comments:

• Pin the comment to the exact element you're referencing, not just the general frame
• Write a complete thought — don't just write "?" and expect the designer to guess
• Distinguish between questions, suggestions, and blocking issues. "Question: how does this state handle empty data?" reads differently than "Blocker: this state has no empty data handling"
• Resolve comments once they're addressed so the thread stays clean

Try Figma Free

For larger feedback threads — like a full design review — you might prefer to consolidate notes in a Notion doc. A simple table with columns for the screen, the feedback, the priority, and the status keeps everything findable and trackable through revision cycles.

The thing most feedback skips

Before diving into details, acknowledge what's working. Not as a compliment sandwich technique, but because it's genuinely useful information — the designer needs to know which decisions to keep, not just which ones to change. "The error states are well thought out here, especially the inline validation" tells them that part is done.

Good feedback takes practice. The more you give it, the more precise you get.