Running Design Reviews
Design reviews maintain quality by catching issues before they reach users. The best reviews have clear structure: they happen at defined project stages, focus on the right level of feedback, and involve the right people. Done poorly, reviews become bureaucratic blockers; done well, they catch edge cases and elevate craft.
The Guide
6 key steps synthesized from 8 experts.
Use a three-stage review process
Structure reviews around three checkpoints: first principles (what are you building and why?), approach (how will you solve it?), and readiness (is this ready to ship?). This prevents micromanagement while ensuring quality at each critical inflection point.
Featured guest perspectives
"Ideally in a perfect world, there's three check-in moments. There is the first principles check-in. What are you trying to build... What is the most important thing?... Once you've aligned on that, then it's like, all right, what approach are we going to use?... And then it's like, all right, this is ready to ship. Let's check in again."— Nickey Skarstad
"The inflection points are the kickoff... design concept review. Then, the products spec. Then, the full experience review or design crit of the end-to-end experience and launch."— Paige Costello
Set expectations and request specific feedback
At the start of every review, state where you are in the process and what type of feedback is helpful. Require presenters to specify exactly what they're seeking input on and highlight the key risks and tradeoffs being made. Match prototype fidelity to the type of feedback you need.
Featured guest perspectives
"I usually find that if you're going to go in and run a design critique or review session, it's helpful to start off front by saying, 'Here's where we are in the process. This is the most important set of things we want to validate.'"— Julie Zhuo
"Any large rock that we have on the roadmap needs to be brought into the product review process... it needs to be structured in a way where you are asking specifically for what type of feedback you need and you're highlighting the key risks and tradeoffs that you're making implicitly in that review."— Geoff Charles
Use the Value-Ease-Delight hierarchy
Prioritize feedback in layers: first, validate whether the design solves the problem (value). Then focus on ease of use. Only after those are solid should you discuss delight and aesthetics. Disregard feedback about minor details until the core value proposition is validated.
Featured guest perspectives
"The first thing that's most important to address is, well, is this thing actually valuable, is this solving the problem?... Then once we do that, then let's focus on the next layer which I think about as ease of use... And then finally, if it is valuable, it's easy to use, then I think we get into is it joyful to use."— Julie Zhuo
"Always think big picture before you think minutiae, because sometimes people think that... They'll throw a bunch of minutiae stuff at me, but it's because they haven't really stopped to think about what is the overall thing that's bothering them."— Jessica Hische
Have senior leadership review 100% of shipped screens
Maintain a high quality bar by having founders or senior leaders review every user-facing screen before shipping. This isn't about micromanagement - it's about catching edge cases, ensuring consistency, and maintaining craft standards across the product.
Featured guest perspectives
"Essentially founders of the company, they still review a hundred percent of screens that are being shipped and everything that you will see in the app pass this review. And there are a lot of eyeballs that were scrutinizing this and thinking of all possible edge cases."— Dmitry Zlokazov
"I still run the design team, so I do see some of the designs on a weekly basis and then, or one of the other co-founders or head of product, we are basically the sponsors for the projects. So then we are responsible reviewing the work."— Karri Saarinen
Do a final hands-on stress test before launch
Before shipping, leaders should do a personal 'click-through' trying all states, edge cases, and animations. Be willing to delay a launch by a few days to fix janky interactions discovered during testing. The final review should be experiential, not just visual.
Featured guest perspectives
"But then before we are launching it, I might just go in and try it out and try the different states and click it around. And sometimes I find things... I just captured those things and send it to the team. And so we had to pull back the release a little bit until those things were fixed."— Karri Saarinen
Perform post-ship quality triage
After features ship, conduct a binary 'high quality vs. low quality' review. Use specific examples of what fell short to calibrate the team's taste and standards. This creates organizational learning about the difference between acceptable and excellent work.
Featured guest perspectives
"Our design leadership team does a triage of everything that got shipped into high quality or not high quality. It's just like a binary function... The reason why we believe it's not high quality is because A, B, C, D, E and we're making it available to other designers so they can actually start to build that telemetry."— Varun Parmar
Common Mistakes
- Giving feedback on aesthetics before validating the core value proposition
- Not specifying what type of feedback you're seeking at each stage
- Skipping the hands-on stress test and only reviewing static mockups
- Using reviews for all decisions instead of focusing on 'large rocks'
- Not learning from shipped work through post-ship quality reviews
Signs You're Doing It Well
- Reviews catch edge cases and quality issues before they reach users
- Teams know exactly what feedback they need at each project stage
- Senior leaders can review all shipped screens without becoming a bottleneck
- The team's shared sense of 'quality' improves over time through post-ship learning
All Guest Perspectives
Deep dive into what all 8 guests shared about running design reviews.
Dmitry Zlokazov
"Essentially founders of the company, they still review a hundred percent of screens that are being shipped and everything that you will see in the app pass this review. And there are a lot of eyeballs that were scrutinizing this and thinking of all possible edge cases and nuances that we need to consider to make sure that every single customer will be happy in this product, in this flow."
- Implement a review process where 100% of shipped screens are scrutinized by leadership
- Focus reviews on edge cases and nuances to ensure customer happiness
Geoff Charles
"I think we're relating now is any large rock that we have on the roadmap needs to be brought into the product review process, where myself and the head of design are present and giving feedback, but it needs to be structured in a way where you are asking specifically for what type of feedback you need and you're highlighting the key risks and tradeoffs that you're making implicitly in that review."
- Only bring 'large rocks' or high-risk decisions to formal reviews.
- Require presenters to specify exactly what type of feedback they are seeking.
- Use Loom walkthroughs of Figma prototypes to motivate teams and anchor the vision.
Jessica Hische
"The best thing is just seeing what's there and really being able to understand what's not working about it and what your goals are... Always think big picture before you think minutiae, because sometimes people think that... They'll throw a bunch of minutiae stuff at me, but it's because they haven't really stopped to think about what is the overall thing that's bothering them. You just never get there if you're always trying to address detail before you address the big picture stuff."
- Ask 'What is the overall thing that's bothering me?' before commenting on specific elements like letters or colors.
- Use 'blurred eyes' to look at a brand's overall cohesiveness rather than focusing on individual pixels.
Julie Zhuo
"The first thing that's most important to address is, well, is this thing actually valuable, is this solving the problem?, is it doing the job correctly... Then once we do that, then let's focus on the next layer which I think about as ease of use... And then finally, if it is valuable, it's easy to use, then I think we get into is it joyful to use, is it pleasurable."
- Disregard feedback about aesthetics or minor details until the core value proposition is validated
- Categorize feedback into 'Value', 'Ease of Use', and 'Delight' buckets to prioritize changes
"I usually find that if you're going to go in and run a design critique or review session, it's helpful to start off front by saying, 'Here's where we are in the process. This is the most important set of things we want to validate.'"
- Explicitly state if you are looking for feedback on high-level concepts or low-level execution
- Match the fidelity of the prototype to the type of feedback you are seeking
Karri Saarinen
"I still run the design team, so I do see some of the designs on a weekly basis and then, or one of the other co-founders or head of product, we are basically the sponsors for the projects. So then we are responsible reviewing the work. And so we might just have a meeting where we go through, okay, well let's go through the demo and people can explain what's going on and how they think about it and why."
- Assign a founder or senior leader as a 'sponsor' for every major project to oversee quality.
- Conduct reviews via live demos rather than static slide decks to see real interactions.
"But then before we are launching it, I might just go in and try it out and try the different states and click it around. And sometimes I find things... I just captured those things and send it to the team. And so we had to pull back the release a little bit until those things were fixed."
- Perform a final 'click-through' of all edge cases and animations before general release.
- Be willing to delay a launch by a few days to fix janky interactions discovered during testing.
Nickey Skarstad
"Ideally in a perfect world, there's three check-in moments. There is the first principles check-in. What are you trying to build... What is the most important thing?... Once you've aligned on that, then it's like, all right, what approach are we going to use?... And then it's like, all right, this is ready to ship. Let's check in again."
- Stage 1: Review first principles and problem definition
- Stage 2: Review the proposed approach and technical architecture
- Stage 3: Final readiness check before shipping
Paige Costello
"The inflection points are the kickoff... design concept review. Then, the products spec. Then, the full experience review or design crit of the end-to-end experience and launch."
- Conduct a design concept review after narrowing down the problem space.
- Perform a full experience review (design crit) of the end-to-end experience before launch.
Varun Parmar
"Our design leadership team does a triage of everything that got shipped into high quality or not high quality. It's just like a binary function... The reason why we believe it's not high quality is because A, B, C, D, E and we're making it available to other designers so they can actually start to build that telemetry."
- Perform a monthly post-ship review of all features to classify them as 'high quality' or 'not.'
- Use specific examples of 'not high quality' work to teach the team the difference between acceptable and great design.
Install This Skill
Add this skill to Claude Code, Cursor, or any AI coding assistant that supports Agent Skills.
Download the skill
Download SKILL.mdAdd to your project
Create a folder in your project root and add the skill file:
.claude/skills/running-design-reviews/SKILL.md Start using it
Claude will automatically detect and use the skill when relevant. You can also invoke it directly:
Help me with running design reviews Related Skills
Other Design skills you might find useful.