![](data:image/svg+xml,<svg display="block" role="presentation" viewBox="0 0 53 32" xmlns="http://www.w3.org/2000/svg"><g opacity="0.6"><g d="M 42.373 19.03 L 42.378 19.038 L 42.384 19.045 L 47.119 24.593 L 44.472 22.715 L 41.801 19.588 L 41.801 18.118 L 41.836 18.088 Z M 36.176 8.381 L 36.176 29.102 L 41.53 27.154 L 41.53 17.941 L 41.814 17.702 L 42.45 18.824 L 47.657 24.926 L 52.7 23.088 L 52.7 2.316 L 47.345 4.263 L 47.345 9.675 L 47.345 15.086 L 47.079 15.34 L 46.234 14.071 L 45.402 12.783 L 41.098 6.541 Z M 37.819 4.244 L 32.978 6.004 L 36.088 8.266 L 40.929 6.431 Z M 49.476 0 L 44.15 1.941 L 47.272 4.128 L 52.588 2.192 Z M 35.979 8.413 L 32.867 6.158 L 32.867 26.886 L 35.979 29.079 Z M 44.039 2.096 L 44.039 10.499 L 47.104 15.065 L 47.153 15.014 L 47.153 4.277 L 44.039 2.096 Z M 3.46 0 L 0.11 2.946 L 6.457 5.266 L 9.783 2.294 Z M 16.007 4.56 L 12.661 7.519 L 18.949 9.802 L 22.306 6.838 Z M 34.163 11.181 L 28.43 9.09 L 25.1 12.044 L 30.836 14.139 L 34.163 11.181 Z M 6.326 5.501 L 0 3.198 L 5.572 25.044 L 12.729 27.648 L 15.229 18.965 L 15.539 19.075 L 18.074 29.593 L 25.104 32.153 L 30.662 14.351 L 24.907 12.257 L 21.985 22.307 L 21.731 22.215 L 18.816 10.032 L 12.468 7.73 L 9.518 17.767 L 9.265 17.68 Z M 11.616 9.853 L 9.833 2.426 L 6.507 5.401 L 9.367 17.513 L 9.437 17.541 Z M 22.352 6.969 L 19.006 9.936 L 21.816 22.041 L 21.908 22.062 L 24.077 14.329 Z M 15.301 19.092 L 12.976 27.414 L 16.201 24.543 L 16.456 23.66 L 15.441 19.146 Z M 30.864 14.289 L 34.071 11.451 L 28.601 28.997 L 25.359 31.915 Z" fill="transparent" height="32.152625408812725px" id="PGzfd7m5d" width="52.69999877537268px"><path d="M 0.572 0.942 L 0.577 0.95 L 0.583 0.957 L 5.318 6.505 L 2.671 4.627 L 0 1.5 L 0 0.03 L 0.035 0 Z" fill="rgb(92, 0, 54)" height="6.505303756663473px" id="ZMg4x2fTW" stroke-dasharray="" stroke-linecap="butt" stroke-linejoin="miter" stroke-miterlimit="10" stroke-width="0.19" stroke="rgb(92, 0, 54)" transform="translate(41.801 18.088)" width="5.318330120143685px"/><path d="M 0 6.064 L 0 26.786 L 5.354 24.838 L 5.354 15.625 L 5.638 15.385 L 6.274 16.508 L 11.48 22.61 L 16.524 20.772 L 16.524 0 L 11.169 1.947 L 11.169 7.359 L 11.169 12.77 L 10.903 13.024 L 10.057 11.754 L 9.226 10.467 L 4.922 4.225 Z" fill="rgb(184, 0, 107)" height="26.786207513450194px" id="rMKI443wV" stroke-dasharray="" stroke-linecap="butt" stroke-linejoin="miter" stroke-miterlimit="10" stroke-width="0.19" stroke="rgb(184, 0, 107)" transform="translate(36.176 2.316)" width="16.523881832013302px"/><path d="M 4.842 4.244 L 0 6.004 L 3.11 8.266 L 7.952 6.431 Z M 16.499 0 L 11.172 1.941 L 14.294 4.128 L 19.61 2.192 Z" fill="rgb(243, 105, 183)" height="8.266021855918975px" id="af_gBpTc3" stroke-dasharray="" stroke-linecap="butt" stroke-linejoin="miter" stroke-miterlimit="10" stroke-width="0.19" stroke="rgb(243, 105, 183)" transform="translate(32.978 0)" width="19.610106192577888px"/><path d="M 3.112 6.317 L 0 4.062 L 0 24.79 L 3.112 26.984 Z M 11.172 0 L 11.172 8.403 L 14.236 12.97 L 14.286 12.919 L 14.286 2.181 L 11.172 0 Z" fill="rgb(92, 0, 54)" height="26.983852954210295px" id="sv9RJ6J8D" stroke-dasharray="" stroke-linecap="butt" stroke-linejoin="miter" stroke-miterlimit="10" stroke-width="0.19" stroke="rgb(92, 0, 54)" transform="translate(32.867 2.096)" width="14.285595181436378px"/><path d="M 3.349 0 L 0 2.946 L 6.346 5.266 L 9.672 2.294 Z M 15.897 4.56 L 12.551 7.519 L 18.839 9.802 L 22.196 6.838 Z M 34.053 11.181 L 28.32 9.09 L 24.99 12.044 L 30.726 14.139 L 34.053 11.181 Z" fill="rgb(102, 213, 224)" height="14.138904749969562px" id="t2LEAKSHO" stroke-dasharray="" stroke-linecap="butt" stroke-linejoin="miter" stroke-miterlimit="10" stroke-width="0.19" stroke="rgb(102, 213, 224)" transform="translate(0.11 0)" width="34.052974775250505px"/><path d="M 6.326 2.302 L 0 0 L 5.572 21.845 L 12.729 24.449 L 15.229 15.767 L 15.539 15.877 L 18.074 26.395 L 25.104 28.954 L 30.662 11.153 L 24.907 9.059 L 21.985 19.109 L 21.731 19.016 L 18.816 6.834 L 12.468 4.532 L 9.518 14.569 L 9.265 14.481 Z" fill="rgb(26, 147, 163)" height="28.954127398177345px" id="lZnQzHmuH" stroke-dasharray="" stroke-linecap="butt" stroke-linejoin="miter" stroke-miterlimit="10" stroke-width="0.19" stroke="rgb(26, 147, 163)" transform="translate(0 3.198)" width="30.662345915406377px"/><path d="M 5.109 7.427 L 3.326 0 L 0 2.974 L 2.86 15.086 L 2.93 15.115 Z M 15.845 4.543 L 12.499 7.509 L 15.309 19.615 L 15.401 19.636 L 17.57 11.903 Z M 8.794 16.666 L 6.468 24.987 L 9.694 22.116 L 9.949 21.233 L 8.934 16.719 Z M 24.357 11.862 L 27.564 9.024 L 22.093 26.57 L 18.852 29.489 Z" fill="rgb(0, 73, 82)" height="29.489049135808706px" id="vdgmBINbC" stroke-dasharray="" stroke-linecap="butt" stroke-linejoin="miter" stroke-miterlimit="10" stroke-width="0.19" stroke="rgb(0, 73, 82)" transform="translate(6.507 2.426)" width="27.56355206905053px"/></g></g></svg>)
DESIGN QUALITY
DESIGN QUALITY
From Opinion to Actionable Feednack
The later product issues are discovered, the more expensive they become—whether the problem is missing requirements, poor usability, or costly implementation surprises. Design reviews should catch those risks early, but too often they devolve into opinion-driven critiques that leave designers with vague, unhelpful feedback. I set out to create a more effective review model: one that surfaced business, user, and technical concerns earlier, gave designers clearer direction, and improved the work without turning every review into a performance referendum.
From Opinion to Actionable Feednack
The later product issues are discovered, the more expensive they become—whether the problem is missing requirements, poor usability, or costly implementation surprises. Design reviews should catch those risks early, but too often they devolve into opinion-driven critiques that leave designers with vague, unhelpful feedback. I set out to create a more effective review model: one that surfaced business, user, and technical concerns earlier, gave designers clearer direction, and improved the work without turning every review into a performance referendum.
From Opinion to Actionable Feednack
The later product issues are discovered, the more expensive they become—whether the problem is missing requirements, poor usability, or costly implementation surprises. Design reviews should catch those risks early, but too often they devolve into opinion-driven critiques that leave designers with vague, unhelpful feedback. I set out to create a more effective review model: one that surfaced business, user, and technical concerns earlier, gave designers clearer direction, and improved the work without turning every review into a performance referendum.
Rethinking the Critique
I applied a design-thinking lens to the review process itself, working directly with stakeholders to understand what they needed from design reviews and where the current model was falling short. By building empathy across product, design, and engineering, I identified the biggest breakdowns and shaped a more useful review process around the team’s real needs.
Rethinking the Critique
I applied a design-thinking lens to the review process itself, working directly with stakeholders to understand what they needed from design reviews and where the current model was falling short. By building empathy across product, design, and engineering, I identified the biggest breakdowns and shaped a more useful review process around the team’s real needs.
ACTIVITY BREAKDOWN
BEST PRACTICE RESEARCH
40%
STAKEHOLDER INTERVIEWS
40%
EMPATHY LISTENING SESSIONS
20%
Stakeholder Interviews with Product and Engineering
I met with product managers and engineers in informal settings to discuss rework and collaboration challenges. These conversations surfaced design-related issues, gaps in review participation, and opportunities to improve alignment through more consistent feedback and ongoing collaboration.
Empathy Listening Sessions with Designers
I met one-on-one with designers to surface frustrations with the design review process, distinguishing constructive from demoralizing feedback and identifying ways to reduce tension so reviews felt more supportive and productive.
Researched Design Review Best Practices
I studied design review best practices, focusing on how to prepare designers and facilitate productive discussions. This informed a more structured, supportive approach that improved feedback quality and overall review effectiveness.
Stakeholder Interviews with Product and Engineering
I met with product managers and engineers in informal settings to discuss rework and collaboration challenges. These conversations surfaced design-related issues, gaps in review participation, and opportunities to improve alignment through collaborative feedback.
Empathy Listening Sessions with Designers
I met one-on-one with designers to surface frustrations with the design review process, distinguishing constructive from demoralizing feedback and identifying ways to reduce tension so reviews felt more supportive and productive.
Researched Design Review Best Practices
I studied design review best practices, focusing on how to prepare designers and facilitate productive discussions. This informed a more structured, supportive approach that improved feedback quality and overall review effectiveness.
Stakeholder Interviews with Product and Engineering
I met with product managers and engineers in informal settings to discuss rework and collaboration challenges. These conversations surfaced design-related issues, gaps in review participation, and opportunities to improve alignment through more consistent feedback and ongoing collaboration.
Empathy Listening Sessions with Designers
I met one-on-one with designers to surface frustrations with the design review process, distinguishing constructive from demoralizing feedback and identifying ways to reduce tension so reviews felt more supportive and productive.
Researched Design Review Best Practices
I studied design review best practices, focusing on how to prepare designers and facilitate productive discussions. This informed a more structured, supportive approach that improved feedback quality and overall review effectiveness.
Problems to Solve
Problems to Solve
This work surfaced four issues the new design review process needed to address
This work surfaced four issues the new design review process needed to address
Right Review, Wrong Time
Reviews often happened too early to evaluate meaningful work or too late to influence the design without costly rework.
Too Few Voices
Design reviews lacked input from product, engineering, and business stakeholders, narrowing feedback to design opinion alone.
Helpful or Heavy-Handed?
Feedback needed to guide designers toward stronger solutions without becoming overly prescriptive or undermining their ownership of the work.
Divorced from the User
Feedback often focused on internal preferences rather than whether the design met real user needs, business goals, and technical constraints.
The Solution
To make design reviews more useful, I replaced one big critique with a series of smaller reviews timed to key stages in the sprint. Early reviews focused on functionality, mid-sprint reviews evaluated user experience and visual design, and final reviews validated interactions and delivery readiness. I also introduced a structured agenda that grounded feedback in business goals, user needs, and task flows—shifting the conversation away from opinion and toward problems the designer could meaningfully solve.
MEETING AGENDA
•
DESIGN REVIEW VARIATIONS
The Solution
To make design reviews more useful, I replaced one big critique with a series of smaller reviews timed to key stages in the sprint. Early reviews focused on functionality, mid-sprint reviews evaluated user experience and visual design, and final reviews validated interactions and delivery readiness. I also introduced a structured agenda that grounded feedback in business goals, user needs, and task flows—shifting the conversation away from opinion and toward problems the designer could meaningfully solve.
MEETING AGENDA
DESIGN REVIEW VARIATIONS
Leave Bias at the Door
Leave Bias at the Door
I created and rolled out a structured design review framework that aligns teams on key decisions, reviews designs from the user’s perspective, and separates personal preferences from design critique—turning feedback into clear priorities and actionable next steps.
Staged Design Reviews
Staged Design Reviews
I broke traditional design reviews into a series of focused, stage-based reviews throughout the sprint—aligning teams on functionality, experience, and interaction from wireframes to final, production-ready designs.
01
Functional Review
Early sprint reviews of mid-fidelity wireframes focus on clarifying functionality—what users can see and do—while validating requirements and uncovering new ideas before progressing to high-fidelity design.
KEY TOPICS
User Interactions
Gaps in functionality
Ideas for enhancement
02
Experience
Review
02
Experience Review
Mid-sprint UI reviews use visual comps to evaluate how the experience works, focusing on usability, visual quality, and consistency with brand and system patterns.
KEY TOPICS
User experience quality
Visual and brand alignment
Design system consistency
03
Interaction Review
03
Interaction Review
End-of-sprint interaction reviews showcase how the design behaves—covering workflows, interactions, and microinteractions—to support development planning and effort estimation.
KEY TOPICS
Workflow behavior
Interaction and motion
Development effort and readiness
01
Functional Review
Early sprint reviews of mid-fidelity wireframes focus on clarifying functionality—what users can see and do—while validating requirements and uncovering new ideas before progressing to high-fidelity design.
KEY TOPICS
User Interactions
Gaps in functionality
Ideas for enhancement
02
Experience Review
Mid-sprint UI reviews use visual comps to evaluate how the experience works, focusing on usability, visual quality, and consistency with brand and system patterns.
KEY TOPICS
User experience quality
Visual and brand alignment
Design system consistency
03
Interaction Review
End-of-sprint interaction reviews showcase how the design behaves—covering workflows, interactions, and microinteractions—to support development planning and effort estimation.
KEY TOPICS
Workflow behavior
Interaction and motion
Development effort and readiness
01
Functional Review
Early sprint reviews of mid-fidelity wireframes focus on clarifying functionality—what users can see and do—while validating requirements and uncovering new ideas before progressing to high-fidelity design.
KEY TOPICS
User Interactions
Gaps in functionality
Ideas for enhancement
02
Experience Review
Mid-sprint UI reviews use visual comps to evaluate how the experience works, focusing on usability, visual quality, and consistency with brand and system patterns.
KEY TOPICS
User experience quality
Visual and brand alignment
Design system consistency
03
Interaction Review
End-of-sprint interaction reviews showcase how the design behaves—covering workflows, interactions, and microinteractions—to support development planning and effort estimation.
KEY TOPICS
Workflow behavior
Interaction and motion
Development effort and readiness
Key Results
The Design Quality Review process made product, engineering, and business approval part of the definition of done for each sprint. Structured feedback throughout the sprint gave teams time to resolve issues, complete the committed scope, and secure sign-offs before the deadline. During the period the process was used, approved designs moved into development with no unplanned rework after sign-off. The work taught me that the timing and purpose of a review matter as much as the feedback itself. Separate functional, experience, and interaction reviews brought the right perspectives in while changes were still practical. Giving each review a clear focus helped teams ground feedback in user needs, business goals, and technical realities—and gave designers useful direction without taking ownership of the work away from them.
Key Results
The Design Quality Review process made product, engineering, and business approval part of the definition of done for each sprint. Structured feedback throughout the sprint gave teams time to resolve issues, complete the committed scope, and secure sign-offs before the deadline. During the period the process was used, approved designs moved into development with no unplanned rework after sign-off. The work taught me that the timing and purpose of a review matter as much as the feedback itself. Separate functional, experience, and interaction reviews brought the right perspectives in while changes were still practical. Giving each review a clear focus helped teams ground feedback in user needs, business goals, and technical realities—and gave designers useful direction without taking ownership of the work away from them.
Key Results
The Design Quality Review process made product, engineering, and business approval part of the definition of done for each sprint. Structured feedback throughout the sprint gave teams time to resolve issues, complete the committed scope, and secure sign-offs before the deadline. During the period the process was used, approved designs moved into development with no unplanned rework after sign-off. The work taught me that the timing and purpose of a review matter as much as the feedback itself. Separate functional, experience, and interaction reviews brought the right perspectives in while changes were still practical. Giving each review a clear focus helped teams ground feedback in user needs, business goals, and technical realities—and gave designers useful direction without taking ownership of the work away from them.