Turning Design Critique into a structured quality ritual
Creating the conditions for better design feedback
Design Critique was already part of the team's routine, but it had gradually become an informal review rather than a structured critique.
Without a shared way to prepare topics and direct feedback, discussions often depended on what happened to come up during the meeting. The ritual had the potential to do more than review work in progress. It could help designers test their thinking, expose decisions earlier, and build a more shared understanding of quality across the team.
This project focused on turning Critique into a lightweight but structured practice that made feedback more intentional without slowing product work.
Problem
The existing format created several recurring issues.
The agenda was unclear before the meeting. Presenters did not have a consistent structure for introducing the project, its maturity, or the decisions still open. Participants often lacked the project context needed to give useful feedback. Because the expected feedback was not defined, discussions could focus on the wrong level of detail: visual polish too early, broad product questions too late, or Design System details before the flow was even stable. And because next steps were not always captured clearly, the value of the conversation could get lost after the meeting.
Critique was taking time from the team, but it was not consistently creating better decisions, clearer next steps, or stronger product quality.
Challenge
The challenge was to introduce enough structure to improve feedback without making critique harder to adopt.
I needed a format that could help presenters frame their work, help reviewers understand the right level of feedback, and encourage designers to bring work before it felt finished.
It also had to stay realistic for a busy product design team. If the process felt too formal, people would stop using it.
Solution overview
Rather than inventing a new ritual from scratch, I looked at how other product teams approached Design Critique. Different formats solved different problems, so I combined the practices that best matched our team's needs instead of adopting one model as-is.
I redesigned the ritual around four stages, from preparing the discussion to making sure the outcomes remained actionable afterwards.
1. Preparing the discussion before the meeting
The team needed visibility on the agenda before the session, not when the meeting started.
I created a Slack workflow where designers could register by reacting to an announcement with an emoji. This automatically triggered a direct message asking for the presentation title, expected duration and critique focus. The information was then shared back with the team, making the agenda visible before the session without requiring manual coordination.
This removed the weekly coordination overhead while giving everyone visibility on upcoming topics.
2. Giving reviewers the right context
The session needed to begin with a clear framing of the project, rather than moving directly into screens without enough context to guide the feedback.
The first version of the Critique template asked designers to document the project context, problem, goals, constraints, maturity, open decisions, and expected feedback. Designers found it too heavy to complete for every session, which created friction before they could even present.
As the Ops Library later made project context a standard part of Figma files, the Critique template no longer needed to duplicate that information. I reduced it to an add-on containing only what was specific to the session: the critique format, what reviewers should focus on, and what they should ignore.
This kept the necessary context available while reducing the preparation required for each Critique.
3. Adapting feedback to the maturity of the work
The same type of feedback was not useful at every stage.
Presenters were asked to clarify what they needed help with, as well as what was not ready for discussion. Early explorations could stay focused on assumptions, flows, hierarchy, or product logic, while more mature work could be reviewed for accessibility, interaction details, Design System usage, consistency, or implementation risks.
I also introduced four feedback categories to make comments easier to interpret: strengths to preserve, improvements to address, opportunities to explore, and points to consider later. This helped prevent every comment from being treated as an immediate change request.
4. Capturing outcomes and follow-ups
The value of the discussion depended on what happened after the meeting.
The template included dedicated space to capture decisions, action items, and open questions so the outcome of each session remained easy to revisit. Presenters left with a clear record of what had been agreed, what still needed investigation, and what should happen next.
Impact
Feedback became more specific because participants had more context and knew what kind of input was expected. The team spent less time reconstructing the project from scratch and more time at the right level of discussion: product direction, user needs, business constraints, visual hierarchy, Design System usage, or implementation risks.
Critique also became a recurring space to practice product thinking and design communication. Presenters had to organize unfinished work, explain the problem, clarify the maturity of the proposal, and formulate a clear ask. Reviewers had to connect their comments to the project context and explain the reasoning behind them rather than reacting through personal preference.
Silent critique and round-the-room feedback created more space for different working styles. Contribution no longer depended only on who reacted fastest or felt most comfortable speaking, and more designers could contribute within the same session.
The ritual also helped expose more work across the team. Designers could spot duplicated patterns, inconsistencies, Design System gaps, and alignment opportunities earlier in the process.
What I learned
Before this project, I mostly thought about quality through the final output: the flow, the component usage, the visual details, the consistency with the Design System, or the implementation gap.
Design Critique changed that perspective. I realized that many quality issues appear much earlier, in the way designers frame problems, explain their decisions, ask for feedback, and build on each other's thinking. Improving those moments often had more impact than refining the final screens.
That shift continued to shape how I approached Design Ops. Beyond improving outputs directly, I became increasingly interested in improving the practices that influence product quality every day.