Design feedback guide: SBI model, tools & templates

The gap between those two sentences is the difference between a critique session that improves a product and one that just burns an hour. This guide breaks down the frameworks, tools, and phrasing that make design feedback actionable for givers, receivers, and those building the process around it.

What design feedback actually means (And why most of it fails)

Design feedback fails for a structural reason, not a taste problem: most of it is directive rather than actionable. Directive feedback prescribes a fix ("make the CTA blue"); actionable feedback names the observed problem and its impact ("users skip the CTA in testing because it competes with the hero image") and leaves the decision to the designer.

According to research, a single evaluator finds only ~35% of usability problems, vs ~75% found by five independent evaluators (Jakob Nielsen / Nielsen Norman Group research, 1994). Design critique studies show that many comments raised in a typical review never reach the shipped design, highlighting how feedback quality directly affects outcomes.

This inconsistency compounds over time, which is why periodically auditing your design system for gaps in components and documentation helps catch the drift that inconsistent feedback creates.

In our critique sessions with client design teams, we've noticed the same pattern repeat: feedback tied to observed behavior gets acted on, while feedback tied to preference gets argued about and dropped. This piece covers the SBI model, Figma annotation workflows, and phrasing that turns opinion into instruction.

The role of feedback in the design thinking process

Feedback sits at the hinge point of every design thinking cycle. It decides whether a team moves forward with the right problem framing or locks onto a convenient first idea. In the divergent phase, feedback should widen the field of options rather than prune it early.

A critique session run too early, before diverse concepts exist, collapses into premature convergence. This mirrors IDEO's guidance on design thinking feedback loops.

Research on iterative feedback loops, reported via Forrester data on user-centric companies, points to stronger brand awareness and faster revenue growth among teams that build iteration into their process. We treat this as directional, not a precise benchmark, since the figures come from a third-party summary rather than the original Forrester report.

In the convergent phase, feedback shifts from generative to evaluative. The goal becomes stress-testing a shortlisted direction against usability heuristics, business constraints, and pixel-level QA feedback before build.

This is exactly where premature convergence sneaks in: running a single-direction critique, evaluating one layout as if it's already decided, inside what was meant to be a divergent phase. Separating situation, behavior, and impact keeps a reviewer describing what's happening in front of them rather than locking onto one preferred layout too soon.

Structured critique formats are widely believed to outperform open discussion for both idea generation and decision quality, though the exact scale of that improvement is still being validated. That split, divergent versus convergent, is the part most feedback frameworks skip entirely.

Whether the critique concerns a design system or style guide, the same structured approach applies, since consistency debates often stem from unclear documentation of components versus visual standards.

How to give Good design feedback using the SBI model

The SBI feedback model turns a vague reaction into actionable feedback by forcing three distinct pieces: the Situation, the Behavior observed, and the Impact it had. Skip any one of the three and the comment reverts to opinion.

That's exactly what turns a design critique session into a debate about taste rather than a decision-making tool.

Write it as a formula, not a paragraph. "On the checkout screen (Situation), the primary CTA sits three scrolls below the fold on mobile (Behavior), which delayed task completion during testing (Impact)." That structure gives the designer something to act on instead of something to defend.

Research indicates that a significant portion of design critique time is spent on subjective opinion rather than specific behavioral observation.

Take a vague comment like "this button feels confusing." Restructured through SBI: the situation is the mobile viewport at first load, the behavior is a CTA buried below three scroll lengths and competing with a promotional banner, and the impact is visible hesitation during moderated testing.

Naming the mechanism, not the feeling, is what lets a team relocate the button in the same sprint rather than opening a design debate.

We've seen the same pattern repeat across other engagements, including our work with Volkswagen, where structured, behavior-first feedback during design reviews kept iteration cycles short and stakeholder discussions focused on evidence rather than preference.

SBI works as well in an asynchronous feedback workflow as it does live. Structured Figma comments anchored to a specific frame, written in Situation-Behavior-Impact order, survive being read three days later by someone with no memory of the discussion that prompted them.

Annotation tools that timestamp and thread comments make the Impact line easy to trace back to a test session or a stakeholder call. That's what separates actionable feedback from a drive-by note left on a layer nobody owns.

How to receive design feedback effectively

Design critique etiquette starts with a rule most designers break in the first thirty seconds: don't respond, record. Separate reaction from evaluation. When a stakeholder says "I don't like the checkout flow," the instinct is to defend it immediately. Write it down instead, and ask for the Situation-Behavior-Impact behind it before you say a word.

Note-taking discipline matters more than defensiveness here. When a reviewer receives scattered comments calling out a dashboard as "cluttered," logging each one against SBI structure often reveals the real pattern behind them, frequently a handful of inconsistent spacing tokens rather than a genuine layout problem. The fix in that case is one token update, not a redesign.

That's the same reason group review beats a single opinion: a lone evaluator catches only a fraction of what a small panel would, per the same Nielsen Norman Group research cited above.

Run feedback through a three-step filter: capture verbatim, tag by SBI category, then triage against actionable feedback versus preference. Anything without a clear behavior and impact goes back to the giver with a follow-up question, not a rebuttal.

In asynchronous feedback workflows, this filtering has to happen before you reply in the thread, since a defensive comment on Slack or in Figma sets the tone for every reviewer after you.

Handling vague or negative feedback without losing psychological safety

Vague feedback ("this doesn't feel right") and negative feedback ("the hierarchy is wrong") need different responses, but both threaten psychological safety if the facilitator role goes unfilled. Design critique etiquette exists precisely for this gap: it gives the group a shared protocol so criticism targets the artifact, not the person who made it.

For vague input, the facilitator's job is reframing, not translating. Instead of guessing what "doesn't feel right" means, the facilitator asks the commenter to point at a specific element and describe the behavior it produces, pulling reluctant feedback into the SBI feedback model on the spot. This single move turns unusable noise into actionable feedback without putting the giver on the defensive.

For negative feedback, the fix is sequencing. Divergent critique phases should surface every reaction before anyone evaluates it; convergent phases decide what to act on. Skipping straight to convergent judgment is what makes critique feel like an attack, since reviewers don't yet have anywhere to put a raw reaction except at the idea itself.

Reframed through SBI, vague critique like "the logo feels cheap" becomes something like "the mark loses legibility below 24px," a note a designer can actually act on in the next revision.

How to structure a design critique session

A design critique session works best as three time-boxed phases run by a single facilitator role: five minutes of context, twenty minutes of divergent reaction, fifteen minutes of convergent decision-making. Skip the phase structure and the session drifts into either silent nodding or a free-for-all where the loudest voice wins.

This structure matters even more when non-designers join the critique, since clear phase boundaries keep unfamiliar reviewers from either staying silent or dominating the discussion.

Time-boxing is not a nicety, it is what keeps divergent critique (surface every reaction, no debate) from bleeding into convergent critique (rank issues, assign owners). A facilitator who lets the two phases blur ends up with a transcript full of opinions and no actionable feedback.

Three roles cover most sessions: the facilitator (protects the clock, enforces SBI feedback model phrasing), a scribe who logs decisions directly against the Figma comments thread, and the presenter, who stays quiet until the divergent phase closes.

Structured facilitation in group critique sessions is linked to higher-quality group decisions (ACM Digital Library, "The Facilitator's Perspective"); sessions run with an explicit facilitator role produce measurably more resolved action items than unstructured walkthroughs.

For distributed teams, fold in an asynchronous feedback workflow before the live session: reviewers leave annotation tool markups against specific frames, so the live meeting starts from a pre-filtered list rather than raw pixel-level QA feedback. Whatever surfaces in either format should land in a tracked action list, not a comment thread that quietly closes when the meeting ends.

Running async and remote feedback workflows

An asynchronous feedback workflow replaces the live critique room with threaded comments, screen recordings, and a shared record of decisions, so a distributed team in Kraków, Wrocław, and Austin can review the same screen without booking a shared hour. The trade-off is real: you lose tone and body language, so the annotation itself has to carry more precision than it would in a room.

The tool choice depends on what stage you're reviewing. Figma comments work well for pixel-level QA feedback, flagging a 2px misalignment on a token, an incorrect line-height, a button state that breaks at 320px. Loom video feedback fits wireframe-stage feedback better, where a reviewer needs 90 seconds to narrate a flow problem that a static comment thread would take ten back-and-forth replies to explain.

Mixing the two by stage, rather than using one tool for everything, is what separates teams that ship clean async reviews from teams that drown in comment threads nobody resolves.

Annotation tools alone don't close the loop. Every comment needs an owner and a status, whether that's a Jira ticket, a Linear issue, or a tracked column in the same Figma file. Without that, an async thread with forty unresolved comments looks identical to a thread with zero decisions made, and reviewers stop trusting it.

Shifting a distributed team's onboarding-flow critique from a single weekly Figma comment dump to SBI-structured async annotations tied to short Loom clips per contested screen is what turns an unmanageable comment pile into a workable review queue.

Situation-behavior-impact framing on each comment cuts the clarification back-and-forth a team would otherwise do in follow-up calls, because the reviewer's reasoning is already attached to the frame, not left for someone to guess at three days later. That kind of structured feedback matters most on projects built around large component libraries, where a single unclear comment can ripple across hundreds of reused instances.

Feedback phrasing templates and scripts you can reuse

A feedback template works only if it forces the reviewer past "I don't love this" into something a designer can act on. Below are four SBI-based scripts we reuse in critique sessions and Figma comment threads. Swap the bracketed detail and the actionable feedback survives even when the reviewer is rushed.

Visual hierarchy: "In the checkout screen [Situation], the CTA and the discount code field carry the same visual weight [Behavior], so users hesitate before tapping either one [Impact]. Try increasing CTA contrast by one token level."

Copy and microcopy: "On the error state [Situation], the message reads 'Something went wrong' [Behavior], which gives the user no next step [Impact]. Name the failure and the recovery action."

Interaction and motion: "When the modal opens [Situation], it snaps in with no transition [Behavior], which reads as a bug rather than a deliberate state change [Impact]. A 150ms ease-out would signal intent."

Pixel-level QA feedback: "On the card component at 1440px [Situation], the padding is 12px against the 16px token used elsewhere [Behavior], breaking the grid rhythm [Impact]."

Save these as a shared feedback template in your critique doc so every reviewer, async or in the room, structures comments the same way.

How to ask for design feedback (Giving reviewers enough context)

Specify three things before you post a screen: the stage (divergent exploration or convergent polish), the exact question, and any constraint the reviewer can't see. "Feedback on the checkout flow" invites a heuristic evaluation. "Does this discount CTA meet accessibility contrast at the current stage" invites actionable feedback instead.

Name the framing question inside the Figma comment thread itself, not in a separate Slack message. Reviewers who see "Stage: convergent, question: hierarchy only" skip the low-value comments about copy tone. Adding that one-line framing to each frame is what cuts off-topic annotation-tool comments dramatically, because reviewers stop guessing what stage the work is in.

Attach constraints reviewers can't infer: brand tokens locked, a legacy component they must reuse, a stakeholder who already rejected an option. According to Nielsen Norman Group's heuristic evaluation guidance, evaluators without stated context routinely apply irrelevant standards, which is the single biggest cause of critique bias in asynchronous feedback workflows.

Beyond your team: Community critique and AI-assisted feedback

A design subreddit or a Discord design community turns a design critique session into a volume exercise: dozens of reactions in hours instead of three colleagues in a meeting, at the cost of anyone knowing your business constraints. These reviewers also can't see whether your work follows shared components and tokens, since that context lives in your design system, not the screenshot.

Crowdsourced threads default to heuristic evaluation, contrast, spacing, convention, because that's all a stranger can judge from a screenshot. Ask for the same framing question you'd post in Figma comments, or you'll get opinion, not actionable feedback.

AI critique tools fill a narrower gap: pixel-level QA feedback, alt-text gaps, tap-target sizing, run against every screen before a human ever opens the file. We use them as a first pass in the asynchronous feedback workflow, not a replacement for it.

Crowdsourced design critique provides value across skill levels; participants rated quality, quantity, cost, and speed positively (CrowdCrit study, CHI conference proceedings). Treat both channels as volume filters that feed the SBI feedback model, not substitutes for a reviewer who understands the product.

FAQ: Design feedback questions

Build a feedback process that sticks

A design critique session only compounds value if it feeds a running workflow, not a one-off Figma comment thread. Our team runs asynchronous feedback workflows alongside live SBI-model sessions, pairing annotation tools with pixel-level QA feedback so nothing gets lost between design thinking and shipped code.

That discipline is what turns actionable feedback into shipped changes instead of another comment thread nobody resolves. The frameworks in this guide, SBI phrasing, time-boxed critique phases, a named facilitator role, only compound if they're applied consistently across every review, not revived for one difficult session and dropped afterward.

If you're testing whether Figma comments alone are holding your critique process back, improve your product's UX with Netguru's Experience & Design team and the Silk design system. If your critique process needs an outside perspective, Netguru's professional UX review service can pinpoint usability gaps a standard comment thread might miss.