Design Critiques: Structured Feedback for Better Designs

The most effective design critique format separates what is observed from what is evaluated. Without this separation, critique sessions become debates about subjective preferences.

Liz Lerman Critical Response Process (adapted for product design):

Step 1: Statements of Meaning (5 min)

• Reviewer shares what they found interesting, surprising, or effective
• No criticism, no 'but', no suggestions — only positive observations
• Forces reviewers to look at the design before forming opinions
• Designer hears what is working before hearing what is not

Step 2: Designer Questions (10 min)

• Designer asks the reviewers specific questions about the design
• Only the designer asks questions — reviewers answer, not riff
• Questions designer should ask: 'Does the hierarchy feel right?'

'Is the checkout flow clear enough?' 'Where do you feel uncertain?'

• Forces the designer to identify their own doubts

Step 3: Neutral Questions (10 min)

• Reviewers ask genuine questions to understand the design
• Cannot contain embedded opinions: 'What made you choose blue?' not 'Why is this blue when blue is so overused?'
• Good: 'What happens when the user doesn't enter a valid email?'
• Bad: 'Did you consider using a different color? Blue is so generic.'

Step 4: Opinions (10 min)

• Reviewers share opinions, but only when the designer asks to hear them
• Designer controls: 'I'd like to hear opinions on the navigation pattern'
• Designer can say: 'Not ready for opinions on the color palette yet'
• Prevents the loudest voice from dominating the critique

Total time: ~35 minutes for a focused critique.

Why this format works:

• Designers hear positive observations first (reduces defensiveness)
• Questions surface blind spots without prescribing solutions
• Opinions are invited, not imposed — designer controls the scope
• Everyone participates (not just the most opinionated person)

Developers see design from a unique perspective: implementation complexity, performance implications, accessibility gaps in the interaction model, and browser behavior edge cases. This perspective is valuable in critique — when framed correctly.

What developers should contribute in critique:

1. Implementation complexity signals:

Do not say: 'That animation is too hard to build'

Instead: 'I want to flag that this animation requires a third-party library (Framer Motion) and will add ~50KB to the bundle. Is there a simpler interaction that achieves the same goal?'

1. Accessibility gaps:

Do not say: 'This is not accessible'

Instead: 'I notice the filter panel has no keyboard interaction defined. For WCAG compliance, we need to specify how keyboard users open and close it — should it be a modal with focus trap, or inline with arrow-key navigation?'

1. Edge cases the design does not address:

Do not say: 'What about empty state?'

Instead: 'I am curious — what should users see if they have no enrolled courses? The design shows the recommendation section, but that requires enrollment data to work.'

1. Platform constraints:

Do not say: 'That is impossible on mobile'

Instead: 'On iOS Safari, there is a known bug with position: sticky inside overflow: hidden containers. The floating header pattern here will not work on mobile Safari. Can we explore an alternative?'

Developer critique participation guidelines:

• Raise technical concerns as questions, not blockers
• Offer alternative approaches when raising concerns
• Distinguish between 'impossible' and 'expensive' — both are valid but require different responses
• Ask what is most important to the user experience, not what is easiest to build
• Support the designer's direction once concerns are acknowledged

When to speak in critique:

• After the designer presents the design (not during)
• In the neutral questions phase: 'I'm wondering how the loading state works here...'
• In the opinions phase only if invited

The framing of feedback determines whether it is received as collaborative improvement or personal attack on the designer's work.

Feedback framing techniques:

'I notice...' — observation-based, non-judgmental:

• 'I notice the action button and the cancel link have the same visual weight'
• 'I notice the form has 9 fields — I wonder if that feels overwhelming'

'I wonder if...' — opens exploration:

• 'I wonder if we could reduce cognitive load by splitting this into two steps'
• 'I wonder if the user understands that this button submits the form'

'How might we...' — collaborative problem framing:

• 'How might we communicate urgency without using red text on both errors and time-sensitive info?'
• 'How might we let users filter without leaving the page?'

'From the user's perspective...' — reframes around user needs:

• 'From a user's perspective, I am not sure what happens after clicking this'
• 'From the user's perspective, is the difference between these two buttons clear?'

Feedback to avoid:

• 'I don't like the color' → preference, not feedback
• 'Make it cleaner' → prescribes direction without identifying problem
• 'This is wrong' → opinion stated as fact
• 'My previous company did it differently' → irrelevant reference
• 'Can't you just...' → minimizes complexity

Feedback sandwich: always avoided:

• 'This is great, but...' → the 'but' negates everything before it
• Better: separate positive observations (step 1) from concerns (step 4)

Written feedback template (for async critique):

1Context: [what I was looking at]
2Observation: [what I noticed, without judgment]
3Question: [what I am curious about]
4Suggestion (optional): [one approach that might address my concern]

Distributed teams across time zones cannot always gather synchronously for critique. Asynchronous critique formats maintain feedback quality while respecting team schedules.

Figma comment critique:

• Designer shares Figma link with 'critique requested' in Slack
• Reviewers add comments pinned to specific elements within 48 hours
• Designer reads all comments, marks resolved or responds
• Optional: 30-min sync to discuss unresolved comments

Figma comment format for async critique:

1[Type: Observation | Question | Concern | Suggestion]
2
3Example:
4[Question] I notice the category filter is a horizontal list — on mobile at 375px,
5what happens when a user has 8+ categories? Does it scroll horizontally or wrap?
6I want to make sure we design for the overflow state.
7
8[Observation] The course rating display (stars + count) is immediately recognizable.
9The size contrast between the star rating and the review count creates good hierarchy.
10
11[Concern] The "Delete account" option is in the same menu as "Edit profile".
12For a destructive action, I would expect it to be separated (different section, different color)
13to prevent accidental deletion. How do we feel about the current placement?

Loom video critique:

• Designer records a 5-minute screen walkthrough in Loom
• Reviewers record 3-5 minute response videos or leave time-stamped comments
• Works well when tone and nuance matter but schedules do not align

Async critique structure:

1Designer shares:
2  'Course Detail v1 ready for critique — focus areas:
3   1. Lesson list information density (is it too much?)
4   2. Enrollment CTA placement (above or below lesson list?)
5   3. Progress visualization on enrolled state
6   Please add Figma comments by EOD Thursday.'
7
8Reviewers respond:
9  - Pin comments to specific elements (not the overall frame)
10  - Use observation → question → suggestion format
11  - One comment per concern (not a list comment)
12
13Designer closes:
14  - Replies to all comments (acknowledged / will change / no change + reason)
15  - Creates Figma version: 'v1 — Post-critique revisions'
16  - Posts update: '8 comments addressed, here is what changed'