How to Give Feedback to a Design Agency

Introduction

If you hire a design team and then treat feedback like optional admin work, you’re basically saying:

“Drive us to a destination I won’t describe.”

Then you act surprised when the result doesn’t match the movie in your head.

The truth: feedback is a production system. A good feedback system compresses time, reduces rework, and protects quality. A bad one creates scope creep, morale collapse, and “we should refund” drama.

NN/g’s critique guidance is blunt: feedback must be framed in relation to goals, tied to scenarios, and kept non-personal — otherwise critique derails into opinions and noise.

What “good feedback” actually is (and what it’s not)

Good feedback = goal-aligned signal

Good feedback does one of these:

• clarifies the goal (“we want founders to request a demo, not read docs first”)

• identifies a risk (“this headline could confuse our ICP”)

• reveals a constraint (“legal requires X, sales requires Y”)

• points to evidence (“users ask about security on calls; we need trust block higher”)

Bad feedback = vibes + pixel-pushing

Bad feedback sounds like:

• “make it more premium”

• “I don’t like this”

• “add more wow”

• “can you make it like Apple / Tesla / Stripe… but different”

Figma itself has published guides on giving feedback that’s specific and useful (because teams constantly drown in low-signal comments).

The Founder Feedback Playbook

1) Start every review with the goal (one sentence)

Before you comment on anything, write:

“This page’s job is: ______.”

Examples:

• “Convert trial users to demo requests.”

• “Build trust fast for enterprise buyers.”

• “Explain the product in under 15 seconds.”

This single line prevents 70% of “taste wars.”

NN/g’s critique cheat sheet literally says: tie feedback back to personas, scenarios, use cases, or goals.

2) Use the Feedback Ladder (don’t jump to pixels)

Review in this order:

1. Positioning & audience (who is this for? what promise?)

2. Story & structure (what’s the narrative? what proof appears where?)

3. UX clarity (can users find, understand, decide?)

4. UI execution (hierarchy, spacing, aesthetics)

If you nitpick UI while (1) and (2) are shaky, you generate rework.

3) Speak in “Problem → Why it matters → Suggested direction”

Use this template (copy-paste it into your Notion/Figma review doc):

Problem: …
Why it matters: (goal/ICP/objection) …
Suggested direction: (option A/B, or question) …

NN/g calls out the tactic: moderate reactive feedback by asking “why” and shaping feedback relative to goals.

4) “Describe the issue. Don’t prescribe the solution.”

Founders often try to “design the design”:

• “Move this 12px”

• “Make this button bigger”

• “Put the logo here”

Most of the time, you’re reacting to a deeper problem:

• unclear hierarchy

• wrong promise

• missing proof

• wrong CTA timing

Better:

• “The CTA feels too early because we haven’t proven X yet.”

• “I’m not convinced we’re credible to enterprise in the first viewport.”

Let designers solve the “how.”

5) Batch feedback. Don’t drip-feed it.

Drip feedback kills velocity because the team keeps re-opening files and context-switching.

Run feedback like this:

• One review window (e.g., 24–48h)

• One consolidated summary (top 5 issues max)

• Figma comments only for precise items, not essays

Atlassian/ Loom’s advice for improving feedback loops also pushes toward building a system that saves time and avoids chaos.

6) Figma comment hygiene (so you don’t become “800 comments guy”)

Rules that keep teams sane:

• One comment = one issue (not 7 demands in one thread)

• Reference the goal (“hurts clarity for ICP”)

• Avoid “more premium” without describing what premium means (trust? restraint? typography? proof?)

• If you’re above ~30 comments on one screen, you’re not reviewing, you’re rewriting the project

If it’s that deep — schedule a call and align on the system, not pixels.

7) Avoid contradictions (they’re the #1 iteration multiplier)

If your feedback says: “Make it minimal”, and 20 comments later: “Add more wow + more detail + more features”:

You’re forcing the team into impossible tradeoffs.

Instead, declare a priority: “We prioritize trust and clarity over flash.” or “We prioritize brand distinctiveness, but performance must stay safe.”

8) Decide who is the final approver (and stop “late boss surprise”)

The “boss appears at the end” situation destroys projects.

Fix it with a simple rule:

• One decision-maker signs off milestones.

• Anyone joining later can propose changes only via a change request, not “redo everything.”

This is exactly why founders search for revisions and proposal evaluation — revision handling is where scope creep lives.

9) Make scope changes explicit (or you’ll fight about money)

Two categories:

• Iteration: refining agreed direction

• Scope change: new pages, new flows, new requirements

If you add scope, you add time/cost. That’s not “agency being greedy.” That’s physics.

(Again: most mainstream “evaluate an agency” guidance stresses scope clarity, process, and post-launch support—because that’s where projects blow up.)

10) If you don’t have feedback… say that properly

Some founders hide behind: “You’re the professionals.”

That’s fine if you also provide guardrails:

• 3 adjectives for the brand tone (e.g., “calm, surgical, confident”)

• 3 competitors you want to beat (and why)

• 3 things you hate (and why)

• primary KPI (demo, trial, inbound)

No guardrails = random outcomes.

Design Feedback Examples (good vs useless)

Useless: “This doesn’t feel premium.”

Good: “For enterprise buyers, we need more credibility above the fold — can we bring proof (logos/security/metrics) higher so trust is established before the CTA?”

Useless: “Make it more modern.”

Good: “The typography and spacing feel dense on mobile; readability suffers. Can we increase line-height and simplify the first screen to reduce cognitive load?”

Useless: “I hate this hero.”

Good: “The hero promise feels too broad; it doesn’t clearly target finance teams. Can we tighten the ICP and make the value outcome explicit?”

NN/g also explicitly recommends framing feedback toward the work (not the designer) and tying it to goals/scenarios.

Metrics & Instrumentation (yes, for process)

If you want feedback to be an asset, track process health:

• Cycle time per iteration (days from delivery → approval)

• # of revision rounds per milestone

• Rework ratio (how often “approved” work is reopened)

• Comment volume per screen (signal-to-noise proxy)

• Stakeholder alignment (how often feedback conflicts)

This is how you know whether your feedback system is accelerating work or choking it.

Our angle

We’re not interested in “pixel politics” or founders weaponizing feedback as leverage. We run feedback like a production system:

• goals first

• batched reviews

• one approver

• clear change requests when scope shifts

• critiques tied to the audience and outcomes

That’s how you ship premium work without turning the project into a courtroom.

Case from our practice

A while back, we had a founder who said all the right things inthe kickoff. “Do what you think is best. We hired you for expertise. I want market-driven decisions.” First week went smooth: we aligned the goals, mapped the audience, and built a clean direction. Then the first visual checkpoint hit — and suddenly the feedback turned into pure instinct. Not “this might confuse our ICP” or “sales keeps hearing this objection,” but the classic: “I don’t like it.” And the worst part wasn’t even that. It was that every “I don’t like it” came with zero constraint, but also zero freedom. We weren’t allowed to keep the direction, but we also weren’t allowed to change the rules of the game. Just endless hovering in the gray zone.

The spiral always looks the same: they start using “premium” as a weapon instead of a criterion. “Doesn’t feel premium” can mean typography, spacing, trust signals, or content clarity — but they don’t specify which. So the team tries to guess. You adjust the hierarchy, then the color, then the density, then add proof, then remove proof because “too busy,” then simplify again because “too empty.” After a couple of rounds, the file starts looking like a patchwork quilt made of compromises. And this is where founders accidentally destroy their own outcome: they demand responsibility from the agency while refusing to accept the agency’s decision-making authority.

We’ve also seen the opposite — and it’s night and day. The best founders don’t “design” in Figma. They translate reality. They show patterns: what users ask on calls, what objections kill deals, and what parts of the flow people consistently misunderstand. Sometimes it’s literally a short doc like “Top 7 questions we get before purchase” or a handful of annotated screenshots from support tickets. That kind of feedback is gold because it’s not taste — it’s evidence. You can disagree with it, test it, design around it, but at least it’s real. And when they do comment on visuals, it’s framed as a goal: “We need to feel calmer and more trustworthy to the enterprise,” not “make it cooler.”

The takeaway is brutal but simple: if your feedback system is “vibes + control,” the project will bleed time and quality no matter how strong the agency is. Either you give evidence-based feedback that ties to users and goals, or you give the team a clear mandate and minimal guardrails — but the half-half approach (“you’re free, but I’ll veto everything emotionally”) is how good work gets slowly suffocated. (Client and project details anonymized.)

Sources

1. UX Design Critiques: Cheat Sheet (PDF) — Nielsen Norman Group

2. Design Critiques: Encourage a Positive Culture to Improve Collaboration — Nielsen Norman Group

3. Derailed Design Critiques: Tactics for Getting Back on Track — Nielsen Norman Group

4. From Figma’s design team: How to run a design critique — Figma Blog

5. Guide to comments in Figma — Figma Help Center

6. Feedback loops and how to optimize them — Atlassian (Work Life)

7. The Cost of Context Switching (and How To Avoid It) — Atlassian (Loom)

8. Context switching: How to reduce productivity killers (task batching) — Atlassian