The Design Critique Framework: 4 Steps to Giving and Receiving Actionable Feedback
Here's a scene that plays out in design teams everywhere:
Designer presents their work:
"Here's the new checkout flow I've been working on."
Stakeholder: "I don't like the blue. Can we make it purple?"
Product manager: "This feels cluttered."
Another designer: "I would have done it differently."
30 minutes later:
The designer leaves with 12 conflicting opinions, no clear direction, and a growing sense that design is just subjective preference.
Sound familiar?
Here's the problem: Most design critiques devolve into one of two failure modes:
-
Personal preference masquerading as feedback
- "I don't like this color"
- "I prefer the old version"
- "This doesn't feel right to me"
-
Vague, non-actionable comments
- "This is confusing"
- "Something feels off"
- "Can you make it pop more?"
Neither helps the designer improve the work.
In fact, bad critiques waste time, lower morale, and produce worse designs.
But here's the good news:
With the right framework, you can transform chaotic opinion-sharing sessions into productive, actionable conversations that actually improve the design.
In this post, I'll share the 4-Step Design Critique Framework — both for presenters (how to ask for feedback) and reviewers (how to give feedback).
This framework has transformed design reviews at multiple companies I've worked with, turning 60-minute circular debates into focused 20-minute problem-solving sessions.
Let's dive in.
The Critique Problem: Why Most Design Reviews Fail
Before we get to the solution, let's understand why critiques go wrong.
Failure Mode 1: Design by Committee
What happens:
- Designer presents work
- Everyone shares their personal preference
- Designer tries to incorporate all feedback
- Final design is a Frankenstein compromise that satisfies no one
Example:
Designer: "Here's the new homepage hero section."
Stakeholder A: "Make the headline bigger"
Stakeholder B: "Actually, make it smaller"
Stakeholder C: "Can we add an animation?"
Stakeholder D: "I think we need more white space"
Stakeholder E: "Actually, this feels too empty"
Designer: *screams internally*
The result: A design that's been watered down by conflicting opinions, with no clear rationale.
Failure Mode 2: The HiPPO Effect
HiPPO = Highest Paid Person's Opinion
What happens:
- Multiple people give feedback
- Executive gives their opinion
- Everyone defers to the executive
- Designer implements executive's preference, even if it's wrong
Example:
Designer: "User research shows that tabbed navigation works better here."
Senior Designer: "I agree, the data supports this."
Executive: "I don't like tabs. Make it a dropdown."
[Everyone nods]
Designer: "Okay, I'll change it to a dropdown."
The result: Design decisions based on authority, not user needs.
Failure Mode 3: Ego Defense
What happens:
- Designer presents work
- Reviewer gives critical feedback
- Designer becomes defensive
- Conversation devolves into argument
Example:
Reviewer: "I think users will struggle to find the search bar here."
Designer: "No they won't. I did research."
Reviewer: "But it's not following the F-pattern..."
Designer: "That's an outdated heuristic."
Reviewer: "Well, I think it's wrong."
Designer: "Then why don't you design it?"
[Awkward silence]
The result: Damaged relationships, no design improvements.
Failure Mode 4: Solution Jumping
What happens:
- Reviewer immediately suggests solutions without understanding the problem
- Designer feels their autonomy is threatened
- Original design intent gets lost
Example:
Designer: "Here's the new sign-up flow."
Reviewer: "You should make the form a modal."
Designer: "But I intentionally made it a full page because—"
Reviewer: "Trust me, modals convert better."
Designer: "Okay..." *reluctantly implements*
The result: Band-aid solutions that don't address root problems.
The Solution: A Structured Framework
The key to great critiques is structure.
When everyone follows the same framework, you transform subjective opinions into objective, actionable feedback.
Here's the framework in two parts:
Part 1: The Presenter's Framework (How to Ask for Feedback)
- Context
- Constraints
- Specific Question
- Timer
Part 2: The Reviewer's Framework (How to Give Feedback)
- Clarify Goal
- State Observation
- State Hypothesis
- Suggest Action
Let's break down each part.
Part 1: The Presenter's Framework (How to Ask for Feedback)
The principle: The quality of feedback you receive is directly proportional to the quality of your setup.
If you present without context, you'll get unfocused feedback.
Here's how to frame your presentation.
Step 1: Start with Context
What to include:
1. The problem statement
- What user problem are you solving?
- Why does this problem matter?
2. The goal/success metric
- What does success look like?
- How will you measure it?
3. Where you are in the process
- Is this a rough concept or final design?
- What iteration is this?
Bad example:
"Here's the new checkout flow. What do you think?"
Good example:
"The problem: Users are abandoning cart at the shipping address step
(48% drop-off rate).
The goal: Reduce drop-off to 30% by simplifying data entry.
Where I am: This is iteration 2, tested with 5 users last week.
Feedback was positive, but I want to validate the flow with the team
before building."
Why this matters:
When reviewers understand the context, they can give feedback aligned with your goals instead of random opinions.
Step 2: State Your Constraints
What to include:
1. What's fixed (not open for feedback)
- Brand colors, logo, required legal text
- Technical limitations
- Business requirements
2. What's flexible (open for feedback)
- Layout, hierarchy, interactions
- Specific user flows
- Edge cases
Bad example:
"Let me know what you think about everything."
Good example:
"What I can't change:
- Must include all 6 form fields (legal requirement)
- Must use brand colors (red/white/black)
- Must fit on mobile screens
What I'm looking for feedback on:
- Form field order
- Visual hierarchy
- Error message placement"
Why this matters:
By defining constraints upfront, you prevent wasted time on non-actionable feedback like "Can we remove this required field?"
Step 3: Ask a Specific Question
The rule: One critique session = One focused question
Bad questions (too broad):
❌ "What do you think?"
❌ "Any feedback?"
❌ "Does this work?"
Good questions (specific and focused):
✅ "Does the user understand the difference between the two pricing tiers?"
✅ "Is the primary CTA clear enough on mobile?"
✅ "Do the icons help or hurt comprehension?"
✅ "Does this flow feel too long, or is the step-by-step approach helpful?"
Why this matters:
Specific questions yield specific feedback. Vague questions yield vague feedback.
Framework for crafting specific questions:
"Does [specific user] understand [specific concept] in [specific context]?"
or
"Will [specific interaction] help users achieve [specific goal]?"
Examples:
✅ "Does a first-time user understand where to click to start the checkout process?"
✅ "Will the sticky header help users navigate between product categories on mobile?"
✅ "Does the progress indicator reduce anxiety during the multi-step form?"
Step 4: Set a Timer
The rule: Time-box the discussion to 15-20 minutes
Why this matters:
- Prevents rambling — Forces people to prioritize their feedback
- Respects everyone's time — Shows you value efficiency
- Creates urgency — Encourages focused, actionable feedback
How to implement:
"I have 15 minutes for this critique. Let's focus on the primary question:
Does the user understand the tier differences?"
[Start timer visible to everyone]
Bonus: If you don't get through all feedback, schedule a follow-up for remaining questions.
Part 2: The Reviewer's Framework (How to Give Feedback)
Now let's flip to the reviewer's perspective.
The principle: Separate observation from interpretation from solution.
Most bad feedback conflates these three. Great feedback explicitly separates them.
Step 1: Clarify the Goal
Before giving feedback, repeat back what you heard:
"Just to confirm: The goal is to reduce cart abandonment at the shipping
step, and you're looking for feedback on form field order. Is that right?"
Why this matters:
- Ensures alignment — You're giving feedback on what the designer asked for
- Shows respect — You listened and understood
- Prevents misalignment — No feedback on irrelevant aspects
If you're unclear, ask clarifying questions:
"What was the drop-off rate before this iteration?"
"What did users say in testing about the address entry?"
"Is the goal to speed up entry or reduce errors?"
Step 2: State Your Observation (No Judgment)
The rule: Describe what you see objectively, without interpretation.
Bad (contains judgment):
❌ "This is confusing"
❌ "The CTA is in the wrong place"
❌ "This won't work"
Good (pure observation):
✅ "I notice the primary CTA is below the fold on a 1366x768 screen"
✅ "I see that the form has 12 fields visible at once"
✅ "I observe that the pricing table uses different font sizes for each column"
Why this matters:
Observations are facts. They're not arguable. This prevents the designer from becoming defensive.
Framework:
"I notice [specific element] is [specific attribute]"
or
"I see [specific behavior/layout]"
Examples:
✅ "I notice the 'Save' button is gray, while the 'Cancel' button is blue"
✅ "I see that the error messages appear at the top of the page, not next to the field"
✅ "I observe that the mobile menu requires 3 taps to access the support page"
Step 3: State Your Interpretation/Hypothesis
The rule: Link your observation to a potential user impact.
Framework:
"I think [user type] might [behavior] because [reason],
which could [business impact]"
Examples:
✅ Observation: "I notice the primary CTA is below the fold on mobile."
Hypothesis: "I think mobile users might miss it and not complete the purchase, which could reduce conversion by 10-20%."
✅ Observation: "I see that the tier comparison uses technical jargon."
Hypothesis: "I think non-technical users might not understand the difference and choose the wrong tier, which could increase support tickets."
✅ Observation: "I observe that the form has 12 visible fields."
Hypothesis: "I think users might feel overwhelmed and abandon the form, which could increase drop-off at this step."
Why this matters:
By explicitly stating your hypothesis, you:
- Make your reasoning transparent — The designer can evaluate if your assumption is valid
- Invite discussion — "Do we have data on this?"
- Connect to business impact — Shows you're thinking strategically
Bonus: Use "I" statements
Instead of: "Users will be confused"
Say: "I think users might be confused"
This frames it as your hypothesis, not an absolute truth. It's less confrontational.
Step 4: Suggest an Action
The rule: Offer a potential solution, but frame it as one option, not the only option.
Bad (prescriptive):
❌ "You need to move the CTA above the fold"
❌ "Just make it a modal instead"
❌ "Change the color to blue"
Good (suggests options):
✅ "One option might be to move the CTA into a sticky footer on mobile"
✅ "Have you considered breaking this into a multi-step form?"
✅ "What if we tested a version with the primary CTA in green?"
Why this matters:
By framing suggestions as options, you:
- Preserve the designer's autonomy — They're still the decision-maker
- Invite collaboration — "What do you think?"
- Encourage exploration — Opens up other possibilities
Framework:
"One option might be [suggestion]. Have you considered [alternative]?"
or
"What if we tried [suggestion]? Curious what you think."
Examples:
✅ "One option might be to use progressive disclosure — show 3 fields initially, then reveal more. Have you considered that approach?"
✅ "What if we tested a version with the tier differences highlighted in a comparison table? Curious if that would improve comprehension."
✅ "Another approach could be to add tooltips next to technical terms. Would that help without cluttering the UI?"
The Complete Framework in Action
Let's see how this looks end-to-end with a real example.
Scenario: Checkout Flow Critique
Presenter (Designer):
Step 1: Context
"The problem: We're seeing 48% cart abandonment at the shipping address step.
User research shows people are frustrated with the amount of manual data entry.
The goal: Reduce abandonment to 30% by simplifying address entry.
Where I am: This is iteration 3. I've tested with 8 users and got positive feedback
on the overall flow. Now I want team validation before building."
Step 2: Constraints
"What I can't change:
- Must collect all 6 address fields (shipping requirement)
- Must validate addresses in real-time (fraud prevention)
- Must work on mobile (60% of traffic)
What I'm looking for feedback on:
- The address autocomplete pattern
- Field order
- Error message placement"
Step 3: Specific Question
"My specific question: Does the address autocomplete pattern make sense
to first-time users? Will they understand how to use it?"
Step 4: Timer
"I have 20 minutes for this critique. Let's focus on the autocomplete UX first,
then field order if we have time."
[Starts timer]
Reviewer (Senior Designer):
Step 1: Clarify Goal
"Just to confirm: You want feedback on whether first-time users will understand
the address autocomplete feature. And the goal is to reduce manual entry friction
to lower the 48% abandonment rate. Did I get that right?"
Designer: "Yes, exactly."
Step 2: State Observation
"I notice that the autocomplete dropdown appears after typing 3 characters,
and it shows full addresses including zip code.
I also see that there's a small helper text that says 'Start typing your address'
but it disappears after the user starts typing."
Step 3: State Hypothesis
"I think some users might not notice the autocomplete feature on first use
because the helper text disappears. They might manually type the full address,
which defeats the purpose of the autocomplete.
This could mean we don't achieve the friction reduction we're hoping for,
especially for first-time users who aren't familiar with address autocomplete."
Step 4: Suggest Action
"One option might be to keep the helper text visible even after they start typing,
maybe as a persistent label above the field.
Another approach could be to show a visual indicator (like a location icon) that
reinforces the autocomplete functionality.
Have you considered either of these, or tested whether users discover the
autocomplete feature without additional cues?"
Designer:
"That's a great point. In my usability tests, 6 out of 8 users discovered it,
but 2 didn't notice until I prompted them. I hadn't considered keeping the
helper text visible. Let me try that in the next iteration."
Result: Actionable feedback that improves the design without derailing the conversation or hurting feelings.
Good vs. Bad Feedback Examples
Let's look at more examples to solidify the framework.
Example 1: Homepage Hero Section
❌ Bad Feedback:
"I don't like the color scheme. Can you try something brighter?"
Problems:
- Personal preference ("I don't like")
- No observation
- No hypothesis about user impact
- Solution with no rationale
✅ Good Feedback:
"I notice the hero section uses dark blue (#1A1A3B) with white text.
I think users with visual impairments might struggle to read the text,
especially on lower-quality screens, which could increase bounce rate.
One option might be to increase the contrast ratio to meet WCAG AA standards
(at least 4.5:1). Have you checked the contrast ratio?"
Why it's good:
- Specific observation (color, contrast)
- Clear hypothesis (user impact)
- Suggested action framed as option
- Invites discussion
Example 2: Mobile Navigation
❌ Bad Feedback:
"The hamburger menu is bad UX. Everyone knows that."
Problems:
- Broad generalization
- No context about this specific case
- Dismissive tone
- No alternative suggested
✅ Good Feedback:
"I notice the main navigation is hidden in a hamburger menu, which requires
2 taps to access any page.
I think frequent users who visit specific sections often (like Pricing or Support)
might find this frustrating, which could slow down task completion.
One option might be to expose the 3 most visited pages in a bottom tab bar on
mobile, and keep less common pages in the hamburger menu. Have you looked at
analytics to see which pages get the most traffic?"
Why it's good:
- Specific observation (2 taps, hidden nav)
- Hypothesis tied to user behavior
- Solution based on data
- Asks for existing insights
❌ Bad Feedback:
"This form is confusing. Simplify it."
Problems:
- Vague ("confusing")
- No specific observation
- No actionable direction ("simplify")
- Dismissive
✅ Good Feedback:
"I notice the error messages appear at the top of the form, rather than
next to the fields with errors.
I think users might have to scroll up to see the error, then scroll back down
to fix the field, which could cause frustration and increase form abandonment.
One option might be to show inline error messages directly below each field
as users fill it out. What was the rationale for putting errors at the top?"
Why it's good:
- Specific observation (error placement)
- Clear user friction hypothesis
- Specific suggestion
- Asks for rationale (respectful)
Common Mistakes and How to Avoid Them
Mistake 1: Giving Feedback on Something You Weren't Asked About
What happens:
Designer: "I'd like feedback on the button placement."
Reviewer: "I think the typography is wrong. You should use a different font."
Why it's bad:
- Wastes time
- Distracts from the focused question
- Frustrates the designer
How to avoid:
Reviewer: "I have a thought about typography, but I know that's not what
you're asking about. Should I save that for another session?"
Mistake 2: Starting with the Solution
What happens:
Reviewer: "Just make it a modal instead of a full page."
Why it's bad:
- Assumes you understand the problem
- Skips observation and hypothesis
- Feels prescriptive
How to avoid:
Follow the framework: Observation → Hypothesis → Suggestion
"I notice this is a full-page form. I think users might feel committed to
completing it, which could increase pressure and anxiety. One option might
be a modal to make it feel more low-commitment. What was your thinking
behind the full-page approach?"
Mistake 3: Using Vague Language
What happens:
❌ "This feels off"
❌ "Something's not right here"
❌ "It's not popping"
Why it's bad:
- Not actionable
- Designer can't fix "feels off"
- Wastes everyone's time
How to avoid:
Force yourself to be specific:
Instead of "This feels off"
Say: "I notice the CTA has the same visual weight as the secondary button,
which might cause users to click the wrong one."
Instead of "It's not popping"
Say: "I think the headline might get lost because it's the same size as
the body text. One option might be to increase the size or weight."
Mistake 4: Design by Democracy
What happens:
5 people give 5 different opinions
Designer tries to incorporate all of them
Final design satisfies no one
How to avoid:
Presenter: Set clear decision-making criteria upfront.
"I'll be prioritizing feedback based on:
1. Does it address the core user problem?
2. Is it supported by data or research?
3. Is it feasible within our constraints?
I appreciate all feedback, but I may not be able to incorporate everything."
Mistake 5: Becoming Defensive
What happens:
Reviewer: "I think users might not see the CTA."
Designer: "Yes they will. I did research."
[Conversation derails]
Why it's bad:
- Shuts down dialogue
- Prevents learning
- Damages relationships
How to avoid:
Designer: Assume good intent. Ask questions.
"Interesting point. In my research, 7 out of 8 users clicked it without
prompting. What makes you think they might miss it? I'm curious about
your reasoning."
Or:
"That's a good hypothesis. I tested it with 8 users, but maybe I missed
something. Can you help me understand what you're seeing that I might
have overlooked?"
Implementing This Framework in Your Team
Ready to use this framework? Here's how to roll it out.
Step 1: Share the Framework
Option A: Team workshop (1 hour)
-
Explain the problem (10 min)
- Show examples of bad critiques
- Discuss how they've experienced this
-
Teach the framework (20 min)
- Presenter's 4 steps
- Reviewer's 4 steps
- Show examples
-
Practice (30 min)
- Mock critique session
- Everyone practices both roles
- Debrief what worked
Option B: Written guide + async practice
- Share this post with the team
- Ask everyone to read it before next critique
- Try it in the next design review
- Debrief afterward: What worked? What didn't?
Step 2: Create a Template
Make it easy by providing a template:
For Presenters:
DESIGN CRITIQUE TEMPLATE
Context:
- Problem: [What user problem are you solving?]
- Goal: [What does success look like?]
- Stage: [Where are you in the process?]
Constraints:
- Fixed: [What can't change?]
- Flexible: [What's open for feedback?]
Specific Question:
[One focused question you want answered]
Time: [15-20 minutes]
For Reviewers:
FEEDBACK TEMPLATE
1. Clarify: [Restate the goal]
2. Observe: "I notice [specific observation]"
3. Hypothesis: "I think [user] might [behavior] because [reason], which could [impact]"
4. Suggestion: "One option might be [suggestion]. Have you considered [alternative]?"
Step 3: Assign Roles
For each critique session, assign:
Facilitator:
- Keeps time
- Ensures framework is followed
- Redirects off-topic discussion
Notetaker:
- Documents feedback
- Summarizes action items
- Shares notes after
Presenter:
- Shares work
- Asks specific question
- Leads discussion
Reviewers:
- Follow feedback framework
- Ask clarifying questions
- Offer suggestions
Step 4: Debrief and Iterate
After each critique, spend 5 minutes:
✅ What worked well?
✅ What was challenging?
✅ How can we improve next time?
Refine the process based on feedback.
Advanced: Async Design Critiques
This framework also works for async critiques (Figma comments, Slack threads).
Async Presenter Template:
📋 Design Critique Request
Context:
Problem: [Brief description]
Goal: [What success looks like]
Stage: [Concept / In progress / Final review]
Constraints:
❌ Not open for feedback: [List]
✅ Open for feedback: [List]
Specific Question:
[One focused question]
Feedback Deadline: [Date]
How to review: [Link to Figma / prototype]
---
Please use this format when giving feedback:
1. Observation: "I notice..."
2. Hypothesis: "I think users might..."
3. Suggestion: "One option could be..."
Async Reviewer Template:
Feedback on [Design Name]
Clarify: [Restate the goal to confirm understanding]
Observation: I notice [specific detail]
Hypothesis: I think [user type] might [behavior] because [reason], which could [impact]
Suggestion: One option might be [suggestion]. Have you considered [alternative]?
[Optional: Screenshot with annotations]
Conclusion: Design Critique is About the Problem, Not the Artifact
Here's the key insight:
Great critiques aren't about the design. They're about the problem.
When you focus on the problem:
- Feedback becomes objective (does this solve the problem?)
- Egos stay out of it (we're all solving the same problem)
- Solutions emerge naturally (what's the best way to solve this?)
When you focus on the artifact:
- Feedback becomes subjective (I like / I don't like)
- Egos get involved (defending "my" design)
- Solutions are personal preferences (I would do it this way)
The framework helps you stay focused on the problem.
For presenters:
- Context → What problem am I solving?
- Constraints → What are the boundaries?
- Specific Question → What do I need to validate?
- Timer → Let's solve this efficiently
For reviewers:
- Clarify Goal → What problem are we solving?
- Observe → What do I see objectively?
- Hypothesize → How might this impact the user?
- Suggest → What options might address this?
The result:
Critiques that are:
- ✅ Focused (not rambling)
- ✅ Objective (not opinion-based)
- ✅ Actionable (not vague)
- ✅ Respectful (not confrontational)
- ✅ Efficient (not time-wasting)
And designs that are:
- ✅ Validated against user needs
- ✅ Refined through structured feedback
- ✅ Supported by clear rationale
- ✅ Aligned with team and business goals
Key Takeaways
For Presenters (How to Ask):
- Context — Start with problem, goal, and stage
- Constraints — State what's fixed vs. flexible
- Specific Question — Ask one focused question
- Timer — Time-box to 15-20 minutes
For Reviewers (How to Give):
- Clarify Goal — Restate what you heard
- Observe — Describe what you see without judgment
- Hypothesize — Link observation to user impact
- Suggest — Offer options, not prescriptions
Common mistakes to avoid:
- Giving feedback on things you weren't asked about
- Starting with solutions before stating observations
- Using vague language ("feels off")
- Design by democracy
- Becoming defensive
To implement:
- Share framework with team
- Provide templates
- Assign roles (facilitator, notetaker)
- Practice and iterate
Your next design critique:
Use this framework. Watch what happens.
You'll have shorter, more focused sessions. You'll get better feedback. Your designs will improve faster.
And most importantly, your team will learn to have productive conversations about design instead of subjective debates about personal taste.
Because great design isn't about opinions. It's about solving problems.
And great critiques help you do exactly that.
