Quick answers
- What is a design review?
- A meeting where the team reviews a design and gives feedback before implementation.
- How do I give feedback in a design review?
- Be specific: state the concern, why it matters, and suggest alternatives when possible.
- What if I don't understand the design?
- Ask for clarification: "Can you walk me through what happens when [scenario]?"
What it is
Design reviews can cover product mockups, UX flows, or technical architecture. The designer or architect presents, and the team asks questions, raises concerns, and suggests improvements. The goal is to align before building.
Why it matters
Good design reviews catch issues early. Asking clear questions and giving constructive feedback shows you're engaged and thorough. Practice helps you phrase concerns without sounding harsh.
Instead of → Say
| Instead of | Say |
|---|---|
| This won't work | I'm concerned about the edge case when the user has no payment method. How should we handle that? |
| The design is wrong | From a technical perspective, this flow would require an extra API round-trip. Could we simplify? |
| I don't like it | I'd suggest we consider [alternative] because of [reason]. What do you think? |
| That's confusing | I want to make sure I understand—does this screen appear before or after checkout? |
| It's too complex | The current scope might delay the release. Could we ship phase 1 first? |
Example dialogue
Designer: Here's the new checkout flow. Questions?
You: I have one. What happens if the user closes the tab during the payment step?
Designer: We'd save the cart and show a recovery message when they return.
You: Got it. And from an engineering standpoint, the three-step flow means three API calls. Would a single-step option work for returning users?
Designer: We could explore that for v2. For now we're optimizing for first-time users.
You: Makes sense. I'm good to proceed.
Common mistakes
- Criticizing without suggesting alternatives
- Asking vague questions—"what about edge cases?"
- Focusing only on technical feasibility and ignoring UX
- Not asking for clarification before objecting
- Drowning the discussion in details
Frequently asked questions
- How do I give constructive feedback on a design?
- Be specific: "I'm concerned about [X] because [Y]. Could we consider [Z]?"
- What if I don't understand the design?
- Ask: "Can you walk me through what happens when [scenario]?"
- How do I raise a technical concern?
- Frame it as a constraint: "Implementing this as designed would require [effort]. Would [simpler approach] work?"
- Should I mention UX issues if I'm an engineer?
- Yes. Cross-functional input is valuable. Phrase it as a user concern: "As a user, I might find [X] confusing."
- What if I disagree with the approach?
- Offer an alternative: "I see it differently. What if we [suggestion]? That could address [concern]."
Ready to practice?
Start practicing with our available scenarios and get instant feedback.
Start practicing