How to Run a Useful Design Critique

TL;DR: What You Will Learn

• Frame the session so everyone knows the goal, the audience, and what feedback you actually need
• Use objective, problem-focused language instead of vague opinions or personal taste. Run the same discipline asynchronously when your team is remote or spread across time zones. Capture decisions and rationale as you go, not from memory afterwards
• Capture decisions and rationale as you go, not from memory afterwards
• Follow up so agreed changes actually happen before the next round

Let us make your next critique the one people actually look forward to.

Why Design Critiques Matter More Than You Think

Early in my career, I treated feedback sessions as a formality. Someone presented, a few people nodded, and we called it a day. Then I watched a small oversight snowball into weeks of rework, and I changed how I think about this entirely.

A design critique is a structured conversation where a team evaluates a design against its stated goals, not a casual glance to see if everyone likes it.

What a Critique Is and Isn't

A critique is not an approval meeting. In an approval meeting, the question is “can we ship this?” In a critique, the question is “does this actually solve the problem we set out to solve?”

That distinction matters more than most teams realise. Approval seeks a yes; critique seeks the truth about whether the design works.

A good critique asks the designer to state the goal, the constraints, and the specific decisions they want feedback on. Everyone else then evaluates against those goals rather than personal taste.

The Nielsen Norman Group draws this same line in its research on design critiques, distinguishing standalone critiques (run purely to improve a piece of work) from design reviews (run to secure sign-off). Its write-up, led by NN/g’s Sarah Gibbons, frames the goal of critique as analysing whether a design meets its objectives rather than judging whether people like it, and notes that this only works once everyone in the room agrees on what those objectives are before the conversation starts.

The best critiques also settle one thing before anyone speaks: are we debating how something looks or how it works? Knowing the difference between UI and UX up front stops the room from arguing about button colours when the real problem is a confusing flow.

The Cost of Skipping Critique

Let me give you a scenario I have seen play out with local fintech teams. A Singapore payments startup was racing to ship a new transfer flow ahead of a partner launch.

The review was casual. The founder liked the clean layout, the team agreed the copy read well, and it went into development.

What nobody checked was accessibility. The confirmation screen relied on colour alone to signal success or failure, and the contrast on key labels was too low for users with low vision to read comfortably.

That gap only surfaced after a compliance check, close to launch. Fixing it meant reworking components, retesting, and delaying the release, all of which a ten-minute structured critique could have caught early.

For a fintech handling money and personal data, this is not a minor cosmetic issue. Accessibility and clarity affect trust, and trust is the whole product.

This isn’t just a hypothetical risk, either. In National Federation of the Blind v. Target Corp., a U.S. federal court ruled in 2006 that the Americans with Disabilities Act applied to Target’s website because it was tied to the retailer’s physical stores, after blind customers found Target.com nearly unusable with screen-reading software.

The case ended in a $6 million settlement, and Target also agreed to a three-year period in which the National Federation of the Blind would test the site for accessibility. None of that started as a design decision anyone flagged as high-risk; it started as the kind of thing a ten-minute critique is built to catch.

The pattern isn’t limited to one company, and it isn’t limited to accessibility, either. Software teams have long pointed to what’s sometimes called the “cost of change curve”: the idea that a mistake gets exponentially more expensive to fix the later it’s caught. The number most often repeated online design-stage fixes cost roughly 1x, testing-stage fixes 15x, and post-release fixes up to 100x- is usually credited to an “IBM Systems Sciences Institute.”

Still, independent researchers who went looking for the underlying study were never able to verify that it exists in a form that supports those numbers. The version that does trace to a real, checkable source is Barry Boehm’s 1981 book Software Engineering Economics, which tracked defect costs across dozens of aerospace and government software projects. Boehm found the same general shape: cheap to fix early, expensive to fix late, though even his own multipliers have since been challenged for varying a lot by project size, with smaller projects showing a far gentler curve.

What has held up across that debate is the direction, not the precise number: catching a design problem before it reaches development is consistently cheaper than catching it after. And the accessibility exposure keeps growing regardless of which multiplier you trust: more than 4,600 web accessibility lawsuits were filed in the U.S. in 2023 alone, according to UsableNet’s tracking. Against numbers like that, a short, structured critique is cheap insurance.

How Critique Builds Design Maturity

There is a quieter benefit that compounds over time. Regular critique makes your designers better and your team more aligned.

When designers defend decisions against goals, they learn to articulate why, not just what. Junior designers in particular grow fastest when they hear how senior peers reason through trade-offs.

Critique also builds shared language. Once a team agrees on how to evaluate a payment flow or an onboarding screen, disagreements become productive rather than personal. Julie Zhuo, the former VP of Product Design at Facebook (Meta) and author of the widely shared essay “How to Do a Product Critique,” ties this same growth to a specific, learnable skill: observation. As she puts it, “there is no shortcut to developing better product instincts besides keen and close observation.”

That is the muscle a well-run critique trains teams to practise noticing before judging, week after week, to start spotting problems faster than teams that never build the habit. That maturity is what separates teams that ship confidently from teams that ship and then scramble to patch what they missed.

Setting the Frame Before Anyone Speaks

The worst design critique I ever sat through fell apart in the first two minutes. The designer opened Figma, said, “Let me know what you think,” and the room immediately started arguing about button colours while the actual problem, a checkout that lost people at the payment step, never came up.

A useful critique is decided before anyone opens their mouth, by how well you frame it. The framing is your job as the person calling the session.

Write a Tight Agenda and Time-Box It

Send an agenda ahead of time, not a calendar invite that just says “design review.” Name what you are reviewing, how long each item gets, and the outcome you want by the end.

For a local Shopee e-commerce team prepping a checkout redesign, that might look like: ten minutes on the guest checkout flow, ten on the payment method selector, five to agree on what ships this sprint. When time is boxed, people prioritise the decisions that matter instead of drifting into a full teardown.

Share the artefacts with the agenda too: the current designs, the problem statement, and any user research you have. If reviewers walk in cold, half your session gets spent explaining context that a shared link could have covered.

State the Goal and the Constraints

Every design exists within limits, and your reviewers cannot judge fairly if they do not know them. Say out loud what the design is trying to achieve and what it cannot change.

Back to that Shopee checkout team: their goal is to reduce drop-off at payment, and their constraints include Shopee’s payment integrations, the mobile-first traffic they see, and a two-week build window. Sharing the success metrics upfront (say, fewer abandoned carts on mobile) means people critique against the goal, not their personal taste in layouts.

If a reviewer suggests a redesign that ignores the payment integration constraint, you can gently point back to the frame rather than debating it emotionally. This is also why designers should be fluent enough in their tool to show work cleanly, and if that is you, these Figma design basics every beginner should master are worth locking down before you present.

Decide What Feedback you Actually Want

Not all feedback is welcome at every stage, and pretending otherwise wastes everyone’s time. Tell the room where the design sits in its lifecycle and what kind of input helps right now.

Broadly, you are asking for one of two things:

Exploration feedback: early divergent thinking on flows, structure, and whether you are solving the right problem at all.

Polish feedback: convergent, detail-level input on spacing, copy, states, and edge cases once the direction is locked.

If the Shopee checkout is still a rough wireframe, asking for opinions on icon styling is a distraction. Say “this is early, I want to pressure-test the flow, not the visuals,” and you will get feedback you can actually use.

State this before anyone speaks, and the whole session stays pointed at the problem you came to solve.

Assigning Roles That Keep the Session Honest

Here is a mistake I made early in my career: I ran a design critique where the same senior person presented the work, chaired the discussion, and decided what to note down. Predictably, the loudest opinion won, and the quieter reviewers said nothing useful.

A critique only works when the jobs are split. When one person owns everything, they cannot stay neutral, and the session tilts towards whoever has the most authority in the room.

The Four Roles That Make It Work

There are four roles I look for in every session, and each one exists to protect the honesty of the feedback.

Facilitator: keeps time, calls on quieter voices, and stops any single person from dominating. They stay neutral on the design itself.

Presenter: frames the problem, the constraints, and the specific decisions they want feedback on. They listen more than they defend.

Note-taker: captures feedback and open questions so the presenter can focus on the discussion instead of scribbling.

Reviewers: give considered, specific feedback tied to the goals the presenter set out.

This split borrows from Discussing Design by Adam Connor and Aaron Irizarry (O’Reilly, 2015), the book most UX teams reach for when they want critique to be a repeatable practice rather than a one-off event, and the same source the Nielsen Norman Group leans on when it describes facilitation as consciously steering a conversation toward a clear outcome, rather than just keeping time.

Why a Neutral Facilitator Matters

The facilitator is the role people skip most often, and it is the one that protects psychological safety, a term coined by Harvard Business School researcher Amy Edmondson for a team’s shared belief that it’s safe to take interpersonal risks, like flagging a flaw in someone else’s work. Edmondson’s original 1999 study of hospital teams (published in Administrative Science Quarterly) found something counterintuitive: the best-performing teams reported more errors, not fewer, because they felt safe enough to surface problems instead of hiding them. A design critique runs on the same logic: junior designers only point out the awkward decision, or admit they’re unsure about their own, if they trust it won’t be held against them.

Picture a Singapore agency running a critique for an SME client, say a local F&B chain redesigning its online ordering flow. The junior designer is presenting, and the room includes a strategist, a developer, and the account lead.

If nobody facilitates, the account lead’s strong opinions can quietly steamroll the junior designer, who then just nods along. So I would have the account lead facilitate instead of critique.

That way, their focus shifts to drawing out balanced feedback and making sure the developer’s concern about load times gets the same airtime as the strategist’s view on messaging. The junior designer presents on a level playing field.

Rotate Roles and Invite the Right People

I rotate these roles across sessions rather than fixing them permanently. When today’s presenter facilitates next week, the whole team learns to give and receive feedback well, and no one gets stuck being the eternal note-taker.

Be deliberate about who reviews, too. Bring in a developer to catch feasibility issues and a content person to flag copy and tone, because they see problems designers miss.

Keep the room small: three to five reviewers with a clear reason to be there beats a crowded meeting where half the people are silent. Every extra person who has no stake in the work dilutes the discussion and makes the presenter feel like they are performing rather than learning.

Giving Feedback That People Can Actually Use

The hardest part of any design critique is not spotting problems. It is saying them in a way that helps the designer move forward instead of getting defensive.

Good feedback follows a simple pattern: observe before you judge, tie every comment to a user goal, and be specific enough that the designer knows exactly what you mean.

Separate the Problem From the Solution

When you jump straight to “make the button blue,” you steal the designer’s chance to explore better options. You have also skipped explaining what is actually wrong.

State the problem first, then let solutions come as a shared conversation. Say what you observed, why it matters, and only then offer a suggestion if you have one.

Picture a UX team in Singapore reviewing a government e-service form for renewing a licence. Instead of “move this field up,” a stronger comment is: “The NRIC field sits above the consent notice, which may push people to enter data before they have read how it is used. That could weaken our PDPA-friendly collection.” The problem is clear; the solution is left open.

Use 'I Noticed... Because...' Framing

This small structure does a lot of work, and it echoes a discipline IDEO has taught in its design-thinking workshops for years: separate the observation from the fix before you start solving. IDEO co-founder Tom Kelley describes the firm’s well-known “I like, I wish” exercise as asking reviewers to open with what’s working before naming what could change, specifically so critique doesn’t collapse into a single unfiltered opinion. “I noticed” keeps you in the world of observation rather than personal opinion, and “because” forces you to connect the point to a real consequence for users.

Compare these:

Vague: “The button looks off.”

Useful: “I noticed the primary call to action competes with the secondary one because both use orange, so users may not know which action we want them to take first.”

The second version is something a designer can act on before lunch. The first just leaves them guessing.

On that government form example, a useful comment might be: “I noticed the instructions use small grey text because it fits the layout, but many of our elderly users struggle with low-contrast copy, so they may abandon the renewal partway through.” Now the observation is tied to a specific group and a specific outcome.

Prioritise High-Impact Issues Over Nitpicks

Not every problem deserves airtime. If you flood a designer with twenty comments about padding and pixel alignment, the one issue that stops elderly users from completing the form gets buried.

I always ask myself: does this affect whether the user can complete their task, or is it a preference? Task-blocking issues and anything touching trust, accessibility, or compliance come first. Cosmetic nitpicks go into a separate note, if at all.

Above everything, critique the work, not the person. “Your design confuses me” points a finger; “This screen made me pause here” describes what happened on the page.

Framing feedback well is a skill hiring managers actively look for, and it shows up in the UX designer interview questions hiring managers ask, so practising it in critiques pays off well beyond the meeting room.

Receiving Feedback Without Getting Defensive

Presenting your work in a design critique can feel like standing in front of a room while people poke holes in something you spent days building. That sting is real, and pretending it does not exist helps no one.

I have watched a junior designer at a SkillsFuture-supported reskilling bootcamp in Singapore visibly tense up the moment a reviewer questioned her navigation choice. By the end of the programme, she had learned to treat critique as data, not a personal verdict, and her work improved faster than anyone else’s in the cohort.

The shift starts with separating your ego from the artefact. The design on the screen is not you, and someone disliking a button colour is not a judgement of your worth as a designer.

Listen and Capture Before Responding

Your first job as the presenter is to shut up and write things down.

When someone raises a concern, resist the urge to immediately explain why you did what you did. Instead, capture the comment verbatim in your notes, even the feedback you disagree with.

I ask presenters to keep a simple running list during the session, so nothing gets lost and nobody feels ignored. This also buys you time, because the more you talk, the less the room talks, and you came here to hear from them.

Ask "What Problem Are You Solving For?"

Not every comment is clear, and vague feedback like “this feels off” is useless until you dig into it.

The single most useful question you can ask is: what problem are you solving for? This reframes a personal preference (“I would make it blue”) into a real design concern (“users might not notice the primary action”).

If a reviewer says the onboarding flow feels long, ask whether they are worried about drop-off, cognitive load, or something else entirely. You will often find that two people flagging the same screen are actually pointing at different problems.

Decide Later, Not in the Heat of the Room

Here is the part that frees you: you do not have to decide anything during the critique.

The presenter owns the design decision after weighing the input, and that means you can thank people for a comment, note it, and choose not to action it once the room clears. Not all feedback must be actioned, and trying to please everyone in the moment leads to muddled, committee-driven design.

This calm, curious posture is exactly what hiring managers look for too, and it is one reason why most UX designer job applications get rejected comes down to how candidates handle feedback rather than raw skill.

Treat critique as input to weigh, not a verdict to accept or fight.

Facilitating the Session So It Stays On Track

The person running the room makes or breaks a design critique. I have seen strong feedback dissolve into a shouting match, and I have seen quiet, well-managed sessions produce three clear decisions in thirty minutes. The difference is almost always the facilitator.

Open With the Goal and Hold the Clock

Start every session by stating what you actually want feedback on. One line is enough: “We are validating the checkout flow, not the visual style, and we need a go or no go by the end.”

That single sentence saves you from half the problems that follow. When someone starts redesigning your button colours, you can point back to the stated goal without it feeling personal.

Then time-box everything out loud. I usually give the designer a few minutes to present context, a fixed block for review, and a hard stop for decisions.

Keep a timer visible. In remote and hybrid sessions, I run it inside FigJam or pin it in the meeting so nobody has to ask how much time is left.

Draw Out Quiet Voices and Manage the Loud Ones

The most useful trick I know is the timed round-robin, and I picked it up watching a lean product team at an IMDA-supported SME here in Singapore. It’s not just a personal habit; the Nielsen Norman Group lists round-robin facilitation as one of the two standard techniques for running a critique, precisely because it guarantees everyone contributes and removes the advantage of speaking first or loudest.

Their team was small, five people, and one senior engineer tended to dominate. So the facilitator gave each reviewer a strict ninety seconds to share their top observation before any open discussion began.

Because everyone had to contribute first, the quieter designer and the newest hire actually spoke, and the loud voice waited his turn. Only after the round did they open the floor.

You can run this in Figma comments too, asking each reviewer to drop their notes on the frame before the call, then reading them out in order. If you want a refresher on what Figma is used for in design teams, that comment workflow is one of the most underused parts of it.

Kill Rabbit Holes and Park Scope Creep

The three failure modes I watch for are rabbit holes, dominating voices, and scope creep. Each has a simple counter.

• Rabbit holes: When two people debate one edge case for five minutes, name it and move on.
• Dominating voices: Redirect with a direct question to someone who has not spoken.
• Solutioning by committee: Stop the group from designing live, and hand the decision back to the owning designer.
• Scope creep: Anything outside today’s goal goes in the parking lot.

That parking lot matters. I keep a visible list, a FigJam sticky column, or a shared doc, and every off-topic idea goes there, where the person can see it captured.

People stop repeating themselves once they trust the idea is safely parked, and you close the session on time with your decisions intact.

Turning Notes Into Action After the Room Clears

The critique itself is only half the job. If nobody writes down what was decided, all that sharp feedback evaporates the moment people close their laptops or their Loom tab.

I have watched brilliant sessions turn into wasted time simply because no one owned the notes. An undocumented design critique is a meeting you may as well not have held.

Capturing Decisions and Open Questions Clearly

The first thing I do while the room is still warm is separate two categories: decisions we reached, and questions we could not resolve.

Decisions are things like “We are moving the primary call to action above the fold” or “the onboarding flow drops to three steps”. Open questions are the ones needing more data, a stakeholder sign-off, or a quick user test.

Keep these distinct. Mixing a firm decision with a maybe means someone will read the notes next week and guess wrong.

Picture a small product design agency in Singapore working on a fintech dashboard. Straight after the critique, the facilitator logs every outcome into a shared ClickUp or Trello board, one card per action.

Each card gets tagged to the design goal it serves, say, “reduce sign-up friction”, so scattered comments become a prioritised list rather than a pile of opinions. This is the same discipline you would use to build a content marketing strategy that boosts SEO: raw ideas mean nothing until they are structured and tied to an outcome.

Assigning Owners and Deadlines

A task with no name attached is a task nobody does. Before people leave, or before the async window closes, I put a real person against every action item.

For that fintech board, each card should carry:

An owner responsible for the change, not a whole team

A due date that fits the sprint, even a rough one

The next reviewer who will check the revised work

The design goal tag so priority is obvious at a glance

Assigning the next reviewer matters more than people think. It tells the owner exactly who to loop in when the fix is ready, so the design does not stall waiting for a vague “someone should look at this”.

Closing the Loop Back to Reviewers

Here is the part most teams skip. When a reviewer gives feedback and never hears what happened to it, they slowly stop bothering.

So after the owner makes the change, I make sure the original reviewer sees the result, whether it was adopted, adapted, or set aside with a reason. A one-line comment on the ClickUp card is enough.

That small habit builds enormous trust. When your designers know their input actually moves the interface, they show up to the next critique sharper and more honest.

Following up is not admin overhead. It is what turns a design critique from a talking shop into the engine that genuinely improves your product.

Common Critique Mistakes and How to Avoid Them

Most broken critiques share the same handful of habits. Once you can name them, you can catch yourself mid-session and steer back.

Let me walk you through the five that quietly wreck a design critique, and the quick fix for each.

The Five Traps

No clear goal. When nobody states what the work is meant to achieve, feedback drifts into random opinions. The fix is one sentence at the top of every session: what problem is this solving, and for whom.

Feedback as personal taste. “I don’t like this blue” tells the designer nothing actionable. Ask people to tie every comment to a user goal or a usability principle, so taste becomes reasoning.

HiPPO override. It’s the fastest way to kill a team’s trust in critique. Give the most senior person a rule: they speak last, and they frame preferences as questions, not verdicts.

Solutioning by committee. When ten people redesign the button live, you get a Frankenstein screen nobody owns. Keep the room focused on identifying problems, and let the designer decide how to solve them.

No follow-up. If nothing is captured and nobody checks whether changes were made, the session was theatre. Assign a note-taker and a clear owner for each agreed action before anyone leaves.

A Singapore Startup That Broke the HiPPO Habit

I once worked with a small SaaS startup in Singapore where every review quietly defaulted to the founder’s preferences. The team would present, the founder would say which layout felt right, and that was the decision.

Designers stopped bothering to argue. The work got tidier but not better, because it was optimised for one person’s eye rather than for users.

The turnaround was simple. They started every critique by stating the goal and the metric it mapped to, such as reducing drop-off on the sign-up flow.

Suddenly “I prefer this version” was not enough. Someone would ask which version was more likely to move that metric, and the conversation shifted from taste to evidence.

The founder still had a voice, but now it was one input among several, weighed against actual user behaviour and analytics.

Consistency Beats the Perfect Session

Here is the part people underestimate: no single critique needs to be flawless. What matters is that your team runs them the same way, every time, until goal-anchored feedback becomes muscle memory.

A shared critique culture is what makes new designers feel safe to speak up, and it compounds far more than one brilliant session ever could.

If your team is still finding its feet in the tool itself, a step-by-step Figma tutorial for beginners removes the friction so people focus on the feedback, not the file.

Conclusion

Remember the meeting we opened with: the one where the loudest voice wins, feedback drifts into “I just don’t like it,” and the designer walks away deflated and unsure what to change. A good design critique replaces that mess with a repeatable ritual. Whether you run it live, async, or as a mix of both, the same five moves hold it together.

Start by framing it: state the goal, the constraints, and what stage the work is at, before anyone opens their mouth. Then assign roles, so someone facilitates, someone presents, and someone captures notes; no one person should hold all three jobs. Once the session is underway, talk in observations, not taste; “I noticed… because…” beats “I don’t like it” every time, whether you’re live or in a comment thread. Just as important is picking the right format on purpose: use live sessions for early, exploratory decisions and anything that needs real trust and back-and-forth, and save async for polish-stage feedback and time-zone-spread teams, with a facilitator, a response window, and a written wrap-up either way. Finally, close the loop: every decision needs an owner, a date, and a reviewer, and every reviewer should eventually hear what happened to their comment.

Do those five things consistently and something shifts. The HiPPO override loses its grip because opinions now have to connect to user goals and stated objectives. Vague reviews become specific, actionable notes. And your team starts trusting the process enough to share early, rough work without bracing for a pile-on.

The trick is frequency, not perfection. A short, structured critique run every week, in whatever format your team’s calendar actually allows, beats a grand quarterly review that everyone dreads.

So here is my nudge: pick one piece of work this week, book thirty minutes (or open one Loom recording), name a facilitator, and run it with this framework. It will feel slightly awkward the first time. It always does. By the third or fourth round, it becomes the way your team just works.

If you are a designer or product person in Singapore who wants to facilitate these sessions with real confidence, formal upskilling helps you internalise the craft behind the ritual. Explore Equinet’s UX/UI Design Career Programme to build the design thinking and feedback skills that make critiques genuinely useful and to practise this exact framework on real projects with mentor feedback.