How to give design feedback that is clear, kind and usable

Most bad design feedback is not rude, it is vague. Turning "it feels off" into a note a designer can use the same afternoon takes three parts and a label.

By the VeoRec team · Oct 3, 2026 · 12 min read

If you have ever left a comment like "can we make it pop a bit more?" you already know the problem. The designer reads it, nods, and has no idea what to change. Learning how to give design feedback is mostly learning to replace reactions with information: what you looked at, what you expected, what happened, and why it matters to the person who will use the thing.

You do not need to be a designer to do this well. Product managers, engineers, founders and clients often give the most useful notes, because they know the goal and the users better than anyone in the design team. The method is the same whether you are looking at a checkout flow in a design file, a landing page on staging or a pricing card pasted into a slide, and it needs no jargon.

How to give design feedback: start from the goal, not your taste

Every useful critique begins with the same question: what is this design supposed to do? A sign-up screen might exist to get people through in under a minute. A pricing page might exist to make the middle plan the obvious choice. Until you know the goal, your feedback can only be about whether you like it.

Adam Connor and Aaron Irizarry's book Discussing Design treats critique as analysis anchored in the objectives: what the work is trying to achieve, which choices serve that, and whether they succeed. Nielsen Norman Group's guide to design critiques makes the same point from the facilitator's side: agree on the objectives first, then tie each comment back to them.

In practice this changes the shape of what you say. "I don't like the green" becomes "the goal is to get people to the trial, and the green button sits at the same weight as the secondary link, so I wasn't sure which one to press." Same observation, but now the designer can test it against the goal instead of arguing about green.

Find out what kind of feedback is wanted right now

A rough wireframe and a pixel-ready mockup need different reviews. Commenting on font weights in a grey-box sketch wastes everyone's time, and questioning the whole information architecture the day before handoff to developers is usually too late to be useful (unless it is genuinely broken, in which case say so plainly).

Erin Casali, writing about asynchronous design critique for A List Apart, separates the stage of the work from the depth of review the designer wants. A designer might be asking only "does this flow make sense?" while the visuals are placeholders. Respect that scope. If you notice something outside it, park it in a separate line marked "for later" rather than mixing it in.

• Early concepts: is this the right problem, the right flow, the right content order?
• Mid-fidelity: is the hierarchy clear, does each screen have one obvious next step, what is missing?
• High-fidelity: states, copy, spacing, contrast, consistency with the rest of the product.
• Built or staging: does it behave like the design, on real devices, with real data?

Separate problems from preferences

You are allowed to have taste. The mistake is presenting taste as a defect. A problem is something you can tie to a user, a goal, a constraint or a standard. A preference is something you would do differently but cannot connect to any of those.

Both are worth saying, as long as they are labelled. "Personal taste, ignore if you disagree: I'd try a warmer photo here" gives the designer permission to keep their choice. Leave the label off and the same sentence becomes an instruction, especially if you are senior or the client.

Write each note as observation, impact, question

A practical formula comes from Casali's companion piece on giving feedback: observation plus impact plus question. It works because each part answers something the designer would otherwise have to ask you.

1. Observation: what and where Name the screen, the element and the state. "On the payment step, the Apply button next to the promo code field" is an observation. "The checkout" is not.
2. Impact: why it matters Say what effect it had, or would have, on the person using it. "I pressed it expecting to pay, and nothing happened except the field turned red." Impact is where you show this is a problem and not a preference.
3. Question or option: where it could go End with an open question or one possible direction, not an order. "Could Apply be a text link so the only filled button on the page is Pay?" The designer may find a better fix; let them.

The question at the end matters more than it looks. Directives such as "move this to the left" skip the reasoning and hand the designer a solution they did not choose and may not agree with. A question leaves the craft with the person who has the most context, and it still makes your concern impossible to miss.

Name what works, just as specifically

Praise is not padding. It tells the designer what to protect in the next round. Without it, a designer who receives eight problems may reasonably rework the parts you liked too.

Generic praise ("looks great!") carries almost no information. Specific praise does: "The progress bar on the onboarding steps made it obvious I was nearly done; please keep that." Some teams use the design-thinking prompt I like, I wish, what if to make sure positives are spoken out loud; whatever the format, the point is that strengths are named as precisely as problems.

Specific praise is a note that says: do not change this.

Point at the exact thing

A lot of feedback confusion is about location. "The button at the top" could be three different buttons depending on the screen size. Put the note where the thing is: a comment pinned to the frame in the design file, a numbered screenshot, or a note at a specific moment in a recording.

Include the state too. Many design issues only show up in one state: the empty cart, the error message, the hover, the second line of a long product name. "On the card with a long title, the price wraps under the button" is a note someone can find in ten seconds.

Interactions are hard to describe in text. If your feedback is about motion, timing or a sequence of screens, a short screen recording with your voice is faster for you and much clearer for the designer. In VeoRec, a screen recorder for designers, each comment carries its time in the video and, if you want, a point on the frame, so "0:42, this spinner" is attached to the spinner itself. Threads can be marked resolved once they ship.

If you record your feedback, give it a shape

A feedback video can go wrong in a new way: two minutes of you clicking around and thinking aloud, with the one important note buried at 1:50. Use the same order you would in writing. Say the goal and the stage you are reviewing in one sentence. Then go through your notes in severity order, blocking first, and for each one put the cursor on the element, say what you expected and what happened, and ask your question. End with the thing to keep.

Afterwards, paste a three-line written summary next to the link: the blocking note, the should-change notes, and the keep. The designer can then plan their afternoon from the text and watch the video for the detail, instead of scrubbing back and forth to make a to-do list of their own.

Know what to look for, layer by layer

Reviewers who are not designers often say they "don't know what to look at". It helps to go through a design in layers, from the ones that are expensive to change to the ones that are cheap. Stop at the layer the designer asked about.

• The job: can you tell in five seconds what this screen is for and what you are supposed to do next? If you cannot, nothing below matters yet.
• The flow: does each step lead to the next, can you go back, and what happens if you leave halfway and return tomorrow?
• Hierarchy: is the most important thing the most visible thing? Squint at the screen; whatever still stands out is what users will see first.
• Content: is the copy specific, consistent with the rest of the product, and written in words your users use? Placeholder text hides real problems, so ask for real copy when you can.
• States: empty, loading, error, success, very long text, zero results. Most designs are reviewed only in their happiest state.
• Accessibility: is text readable against its background, is anything conveyed by colour alone, are tap targets big enough?
• Visual polish: alignment, spacing, consistency with the design system. Useful, but last.

For legibility, you do not have to rely on your eyes. The W3C's contrast guideline asks for a ratio of at least 4.5:1 for normal text and 3:1 for large text, and any contrast checker will tell you the ratio for two colours. "The helper text is 3.1:1, below the 4.5:1 minimum" is a note nobody argues with.

Rank your notes so the important ones are not buried

Ten notes of equal weight force the designer to guess which ones matter. Nielsen Norman Group's guidance on expert reviews puts a severity rating on every finding for exactly this reason; they often use a plain high, medium, low scale. You do not need a formal process to borrow the idea.

Put the blocking notes first. If you have more than about three of them, the design probably needs a conversation, not a list of comments. Say that instead.

Choose the right room for the feedback

Live critiques are good for big questions and early work, where a five-minute exchange can reshape the direction. They are bad at precision: people forget what was said, the loudest voice wins, and the designer leaves with notes scribbled during the discussion. Written or recorded feedback is better for detail, because it is pinned to the work and can be read twice.

Group dynamics need care in both. When a senior person or a client speaks first, others tend to agree. NN/g's critique guide suggests going round the room or setting quotas (for example, two strengths and one problem per person) so every reviewer contributes. In async review the equivalent is asking reviewers to leave notes before reading anyone else's.

If you are on the presenting side, our guide to presenting design work asynchronously covers how to frame the request so reviewers give you this kind of feedback in the first place.

Check a note before you send it

It takes about twenty seconds to reread a comment as the designer will read it. Run your longest or most critical note through this scorecard. If it scores low, rewrite before it goes out; fixing a vague note now is cheaper than a reply thread later.

Tone is the last check. Feedback aimed at the work ("this label reads as a link") lands differently from feedback aimed at a person ("why did you make this a link?"). Casali also suggests checking your intent: if a note mostly exists to show you noticed something, cut it.

Close the loop after the designer replies

Feedback is a conversation, and the designer gets the last word on craft. If they reply "I kept it, because the tag colour is shared with the badge system", that is a legitimate answer. Accept it, or escalate the underlying goal if it really matters, but do not repeat the same note louder.

Keep feedback in one place so decisions do not scatter across chat, email and calls. When a note is addressed, mark it resolved where it lives; when it is declined, leave the reason in the thread. For website reviews in particular, the same discipline applies to pages instead of frames; see how to collect website feedback without endless email threads.

A worked example: one review of a sign-up screen

This is what a full set of notes looks like for a mid-fidelity sign-up screen, where the designer asked: "Is the flow clear, and is anything missing before I move to visuals?" Notice that it stays inside that scope, ranks the issues and ends with what to keep.

1. Blocking: Step 2, password field. There is no rule shown until after you submit, so I failed twice before learning it needs a symbol. Our goal is sign-up in under a minute; could the rules sit under the field from the start?
2. Should change: Step 3 asks for company size before you have seen the product. I wasn't sure why it mattered and nearly closed the tab. Is this needed now, or could it move to onboarding?
3. Consider: After the confirmation email is sent, the screen has no next step. What if it offered to open the inbox, or let people continue while they wait?
4. For later (visuals, outside this round): the step indicator and the Next button are close in size; worth checking hierarchy when you do the visual pass.
5. Keep: The single-column layout and the plain-language error on the email field were both clear. The "back" link on every step made me confident I could fix mistakes.

Five notes, each with a location and an effect, one clearly parked for later. The designer can work through it top to bottom without a meeting. Compare that with the usual alternative, a call where three people react to the screen at once and someone types "password stuff, company size?, polish" into a doc.

What to do next

Before your next review, get two answers: what the design must achieve, and what stage it is at. Then write your notes in three parts (what and where, what effect, a question), label severity and taste, and name one thing to keep. Reread the worst note with the scorecard above before you hit send.

If the review involves movement, flows or anything you would otherwise describe in a long paragraph, record it instead: two minutes of you clicking through and talking usually beats ten sentences. VeoRec records a tab or your screen with your voice, and the link is copied when you stop, so the designer can watch and reply on the frame.