A design critique — whether for a UI mockup, an API shape, or a system architecture — only works if the feedback is specific enough to act on. Vague comments (“I don’t love this”) waste the meeting; specific ones (“this button placement conflicts with the existing pattern on the dashboard”) move the design forward. This guide gives you the language to critique clearly without sounding harsh.
Key Vocabulary
Grounding feedback in a goal or user need — connecting your critique to a specific objective (usability, consistency, a user story) rather than personal taste, which makes the feedback harder to dismiss and easier to act on. “I grounded my feedback in the user need: new users specifically struggle to find the settings menu in testing, so I’d suggest moving it somewhere more visible rather than nesting it two levels deep.”
Separating observation from opinion — describing what you see factually before offering your judgment on it, so the presenter can evaluate the observation independently of your take. “I separated observation from opinion: I noted that the form has eleven required fields, and only then said I think that’s too many for a first-time signup.”
Offering a specific alternative — proposing a concrete change instead of only pointing out a problem, which turns criticism into something the presenter can actually use. “Rather than just saying the naming was confusing, I offered a specific alternative: calling it ‘draft’ instead of ‘pending’ would match the terminology used everywhere else in the product.”
Asking instead of asserting — phrasing a concern as a genuine question when you’re not fully sure it’s a problem, which invites explanation rather than forcing a defense. “I asked instead of asserting: ‘what happens if a user has zero projects — does this empty state still make sense?’ rather than declaring it broken outright.”
Common Phrases
- “One thing I noticed is [observation] — have you considered [alternative]?”
- “This works well for [scenario], but I’m not sure it holds up for [edge case].”
- “I like the direction overall; my main concern is [specific issue].”
- “What was the thinking behind [specific decision]?”
- “If it’s helpful, one pattern I’ve seen work well is [alternative approach].”
Example Sentences
Opening with something positive and specific before the concern: “The overall flow makes sense, and I especially like how the confirmation step reduces accidental submissions. My one concern is the error state — right now it just says ‘something went wrong,’ which won’t help users self-serve.”
Grounding a critique in a concrete user need: “For users on a slow connection, this page loads all the images before showing any content, which could mean a blank screen for several seconds. I’d suggest a skeleton loader or lazy-loading the below-the-fold images.”
Asking a clarifying question instead of asserting a flaw: “I might be missing context — is there a reason the delete action doesn’t have a confirmation step? Given how destructive it is, I’d expect one, but I want to check if that was intentional.”
Offering an alternative rather than just criticizing:
“Instead of a single long form, what if we split this into three shorter steps with a progress indicator? That tends to reduce drop-off on longer signups.”
Professional Tips
- Ground every critique in a goal or user need — “I don’t like it” is opinion; “new users get lost here in testing” is evidence.
- Separate what you observed from what you think about it — state the fact, then your take, so the presenter can weigh them independently.
- Whenever possible, offer a specific alternative, not just a problem — it shows you’re invested in the outcome, not just pointing out flaws.
- Use questions instead of assertions when you’re genuinely unsure whether something is a problem or a deliberate choice.
- Lead with something genuine and specific that works, before raising concerns — critique lands better when it’s clearly balanced, not just a list of complaints.
Practice Exercise
- Write a critique of a hypothetical login form using the observation-then-opinion structure.
- Draft a question (not an assertion) about a design choice you’re unsure is intentional.
- Rewrite the vague comment “this feels cluttered” as a specific, groundable critique.
Navigating Nuance: Refining Feedback Delivery for Clarity
Let’s face it – delivering constructive criticism, especially in a group setting, can be daunting. It’s one thing to understand the principle of giving feedback effectively, but quite another to translate that understanding into natural-sounding phrases and actions when you’re actually in the moment. For non-native English speakers, this challenge is often amplified by differences in directness and formality expectations across cultures. A key element of professional communication isn’t just what you say, but how you say it – conveying respect and a genuine desire to help improve the design.
One common pitfall is offering overly broad statements like “This looks bad” or “It’s confusing.” While perhaps intended as critical, these phrases lack specifics and can feel dismissive. Instead, focus on observable details and their impact. For example, instead of saying “The navigation isn’t intuitive,” try something more targeted like: “I noticed that users often click the ‘About Us’ link when trying to access the pricing page. Perhaps a clearer visual hierarchy could help guide them.” This demonstrates you’ve observed a specific issue and are suggesting a potential solution. Similarly, in Slack conversations discussing a pull request, avoid simply stating “This needs work.” Instead, draft messages like: “I’m seeing some inconsistencies with the branding here – could we align with the style guide?” or “Could we discuss the placement of this element? It feels slightly out of context.”
Another crucial area is framing feedback positively. Start by acknowledging what is working well before addressing areas for improvement. This establishes a collaborative tone and demonstrates you’re seeing the value in the design. For instance, “The color palette is really vibrant and engaging – I just think we could streamline the information architecture slightly to improve usability.” Remember that your goal isn’t to tear down the work but to build upon it. Practicing phrases like “Perhaps…” or “It might be helpful to consider…” softens criticism and invites discussion. Furthermore, when providing feedback in a PR description, use action-oriented language – “Refactor the styling for…” is far more effective than “The styling needs improvement.”
Finally, remember that active listening is just as important as offering your own feedback. Truly understand the designer’s rationale before responding, and ask clarifying questions to ensure you’re on the same page. A simple “Can you walk me through your thinking behind this layout?” can often uncover underlying assumptions or constraints you hadn’t considered. Building a culture of open dialogue is paramount for effective design critique and professional growth within any team.
Keep practising
Turn this article into muscle memory
Five-minute exercises with instant feedback — built from the same kind of real IT language.
What to read next
Frequently asked questions
What will I learn from "How to Give Feedback in a Design Critique in English"?
This is a Intermediate-level Communication article covering communication, design, feedback and speaking. Learn the English phrasing for giving useful, specific feedback in a UX or architecture design critique, balancing honesty with tact in front of the whole team.
Is this article free to read?
Yes. Every article on CoderSlingo, including this one, is free to read with no account, sign-up, or paywall.
How is reading this article different from doing an exercise?
Articles like this one explain concepts and vocabulary in context through prose, while exercises are interactive drills — fill-in-the-blank, matching, and multiple-choice — that test and reinforce specific terms. Reading builds understanding; exercises build recall.
Can I practice the vocabulary used in this article?
Yes — this article's topic lines up with our communication exercises. Use the "Practice this vocabulary" link below to jump straight into a matching drill.
How long does "How to Give Feedback in a Design Critique in English" take to read?
About 7 min. Most CoderSlingo articles, including this one, are written to be read in one sitting, without needing a dictionary open in another tab.
Do I need to create an account to read or save this article?
No account is required to read any article. If you complete exercises elsewhere on the site, your progress is saved locally in your browser — no login needed.
What if I don't understand a technical term used in this article?
Check the site Glossary for plain-English definitions of common IT terms, or browse the #communication tag page for other Communication articles that use the same vocabulary in different contexts.
Can I share or link to "How to Give Feedback in a Design Critique in English"?
Yes — use the Twitter/X or LinkedIn share buttons at the end of the article, or copy the page URL directly. Attribution back to CoderSlingo is appreciated but the content is free to reference.
When was this Communication article published?
This article was published in 2026. New Communication articles are added regularly — visit the #communication tag page to see the full, continuously updated list.
Where can I find more articles like this one?
See "How to Run a Mob Programming Session in English", "How to Ask for Clarity on Vague Performance Feedback in English", "How to Give Feedback in a 360 Review as an Engineer in English" in the Related Articles section below, or browse all Communication articles from the main Blog index.