5 exercises — rewrite vague feedback as specific, actionable critique, and practise professional design review and response language.
0 / 10 completed
1 / 10
Rewrite the vague feedback "This looks bad" into specific, actionable, evidence-based critique for a low-contrast button.
Specific, actionable, non-personal feedback — the foundation of professional design critique. Compare the two responses:
• "This looks bad" — subjective, gives no reason, offers no path forward, and reads as a judgment of the designer rather than the design • "Contrast ratio is 2.8:1, below the 4.5:1 WCAG AA requirement..." — cites a measurable standard, explains exactly what fails and why it matters, and proposes concrete next steps
The formula for evidence-based critique: [specific observation] + [why it matters / who it affects] + [a proposed direction, phrased as a question or suggestion, not a command].
Other examples of the same pattern: • Instead of "the spacing feels off" → "there's only 4px between these two sections, but 16px everywhere else on this screen — was that intentional?" • Instead of "the copy is confusing" → "'Submit' doesn't tell users what happens next — would 'Send for review' be clearer?"
Specific feedback is also faster to act on: a designer can immediately open their contrast checker and fix a stated ratio, but cannot act on "this looks bad" without a follow-up conversation.
2 / 10
In a design review, you disagree with a layout choice but want to keep the conversation collaborative. Which phrase best opens that feedback?
Design review vocabulary — professional phrases for raising disagreement without shutting down collaboration:
• "I'd like to explore an alternative approach to…" — opens a discussion rather than declaring a verdict; invites the designer to think through options together • "My concern is that…" — names the underlying reasoning/risk rather than just rejecting the surface choice, which helps the designer understand the real problem to solve (here: scalability, not "I dislike tabs") • "What if we tried…?" — frames a suggestion as a question, leaving room for the designer to push back with information you might not have
Avoid absolute, dismissive language in reviews: "this is wrong," "whoever did this," "obviously" — these attack the work personally and tend to produce defensive reactions rather than better design. The goal of a review is a better outcome, not a verdict on the designer's competence.
Additional review-opening phrases: "Walk me through the thinking behind…", "Have we considered…?", "I want to make sure we've stress-tested this against [edge case]."
3 / 10
The "feedback sandwich" technique wraps critique between positive framing. Which version below correctly applies it to feedback on a signup form?
Feedback sandwich — a structure for delivering critique: (1) genuine, specific positive observation, (2) specific, actionable concern, (3) closing that reinforces confidence or next steps. It is NOT about padding real criticism with fake praise — the first layer must be a genuine, specific strength, not empty flattery, or the technique backfires and reads as insincere.
Anatomy of the good example: 1. Specific positive: "visual hierarchy is clean, CTA stands out" — names exactly what works 2. Specific concern, framed as a gap not a failure: "error states aren't shown" — identifies a missing piece of the design, not a personal failing 3. Closing: "otherwise the flow feels intuitive, we're close" — signals confidence in the overall direction while flagging what remains
Vague positives ("nice work!") or vague negatives ("needs work") both fail the sandwich technique — every layer needs to be concrete enough that the designer knows exactly what to keep and exactly what to change.
4 / 10
A teammate gives you feedback: "The mobile spacing between these two cards is too tight — 8px feels cramped when everything else uses 16px." What is the most professional way to accept this feedback?
Accepting feedback professionally — how you respond to critique shapes whether teammates continue giving you honest, useful input.
"Thanks for the callout. I'll revisit the spacing on mobile" does three things well: • Acknowledges the input ("thanks for the callout") without being defensive • Commits to a concrete next step ("I'll revisit the spacing"), showing the feedback was heard, not dismissed • Ties the fix back to a shared standard ("bring it in line with the 16px scale"), reinforcing that decisions are grounded in the system, not personal preference
If you disagree with feedback, professional language still applies: "I hear the concern about spacing — I chose 8px here deliberately because these two cards are meant to read as a single group; happy to explain the reasoning or explore an alternative if it's still not landing." This pushes back with a reason, not a dismissal, and stays open to further discussion.
Vocabulary for gracefully engaging with critique: "That's fair," "Good catch," "I hadn't considered that," "Let me sit with that and get back to you."
5 / 10
Rewrite this personal, non-actionable comment into professional design review language: "You always make the buttons too big."
Removing "you always/never" language — one of the most important shifts in design critique: replace generalized statements about the person with specific statements about this instance of the work.
• "You always make X too big" — a pattern accusation about the person, unfalsifiable, and likely to trigger defensiveness • "This button is 56px, our standard is 44px — was there a reason?" — a specific, checkable fact about this one instance, plus an open, curious question that leaves room for a legitimate explanation (e.g., an accessibility requirement) you might not know about
The rewritten version also demonstrates assuming positive intent — instead of assuming the size is a mistake, it asks whether there was a deliberate reason. This matters because design decisions sometimes have context the reviewer doesn't have (a client requirement, a research finding, a technical constraint).
General rule for professional critique: talk about this artifact, not this person's track record. "Always" and "never" statements belong in a 1:1 conversation about working patterns, not in a design review of a specific screen.
6 / 10
Sarah: 'This button is confusing!'
As a senior designer reviewing Mark's PR for the new e-commerce checkout flow, which of the following responses best communicates your concerns while maintaining a collaborative tone?
The best response acknowledges the issue ('not immediately clear') and seeks to understand Mark's reasoning rather than simply dismissing his feedback. Option A is dismissive and doesn't encourage discussion. Option C is too blunt and lacks context. Option D avoids addressing the concern altogether. Option B invites a constructive conversation by requesting clarification.
7 / 10
You're reviewing an API response for a product search endpoint. The response includes a field called 'suggestions'. The documentation states: 'Suggestions are ranked by relevance and popularity.'
Which of the following is the most effective way to provide feedback on this?
Option 1 directly addresses the documented ranking criteria – relevance and popularity. It's specific and actionable. Options 2 and 3 shift the focus to metrics (click-through rate) or data which might be outside the scope of initial feedback. Option 4 is a generic affirmation without addressing potential issues.
8 / 10
David: 'The font size on this modal window is too small.'
You are providing feedback via Slack. Which of the following responses best communicates your concern while maintaining professionalism?
Option 1 is too informal and lacks specific language. Option 2 identifies a potential problem (accessibility) and suggests a concrete solution (increase font size). Options 3 and 4 are dismissive and don't offer any constructive feedback. Using 'accessibility issues' adds weight to your comment.
9 / 10
Emily: 'This form is too long!'
You are writing a PR description for a design change. Which of the following statements would be most appropriate to include?
Option 1 simply states the problem without explaining the rationale. Option 2 provides context—that the redesign aimed to improve user flow and reduce friction – justifying the changes. Options 3 and 4 are subjective opinions and don't explain the design decisions. A PR description should focus on *why* a change was made, not just *what* changed.
10 / 10
John: 'The color palette is inconsistent across these screens.'
You are in a daily standup meeting. Which of the following responses would be most effective?
Option 1 is a directive and doesn't invite further discussion. Option 2 prompts John to provide specific examples, which is crucial for collaborative problem-solving during a standup. Options 3 and 4 avoid addressing the issue or taking ownership, respectively.
What will I practice in "Design Feedback Language — Product Design Exercises"?
This is a Product Design exercise set. It walks through 10 scenario-based multiple-choice questions built around real usage of product design terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 10 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the product design vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Product Design exercises?
See the Product Design exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — product design vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.