How to give feedback to designers — as a designer

One of the strangest things about design teams is this:

We spend years learning how to receive critique… but almost no one teaches us how to give it properly. And bad feedback from another designer hurts differently.

Because when feedback comes from PMs or stakeholders, you expect some disconnect. But when it comes from another designer, especially a senior one, it can either sharpen your thinking — or quietly destroy your confidence for a week.

I’ve experienced both.

“This feels off.”

Years ago, I presented a mobile dashboard redesign during a critique session. I walked through the flows, explained some decisions, showed interaction patterns. Then another designer leaned back and said:

“This feels off.”

That was the feedback. Not what felt off. Not why. Just… off. The room went silent for a second. I nodded pretending I understood. Inside, I was annoyed.

I went back to my desk and changed random things for two hours because I genuinely didn’t know what problem I was solving anymore. That experience taught me something important:

Vague feedback creates design insecurity, not better design.

Good critique is not about sounding smart

There’s this weird culture sometimes in design critiques where people try to sound hyper-intellectual (in Delhi we call them Gyaan k C…. :P) .

“This lacks visual harmony.”

“The hierarchy doesn’t emotionally resonate.”

“The affordance architecture feels fragmented.”

Brother… what does that even mean. Some designers confuse critique with performance. The goal becomes sounding insightful instead of being useful. The best feedback I’ve received was usually simple and painfully clear.

Things like:

• “I’m not sure users will notice this action.”
• “This step increases cognitive load.”
• “I think you solved the business problem but created a usability issue.”
• “Can you explain why this needs to be hidden?”

That’s actionable. That helps.

Designers are not critiquing pixels. They’re critiquing thinking.

A younger designer once asked me:

“How do you always know what to comment on in reviews?”

Truth is, I don’t always. But over time, I realized strong feedback usually comes from evaluating the reasoning, not the UI itself. The screen is just evidence of thinking. When giving feedback, I now try to understand:

• What problem are they solving?
• What constraints exist?
• What trade-offs did they make?
• What user behavior are they optimizing for?

Without that context, critique becomes decoration advice and to be honest, that happens a lot in reality.

One mistake senior designers make a lot

Jumping straight to solutions. This happens constantly. A designer presents work and within 12 seconds someone says:

“You should move this button here.” Or “What if this was a bottom sheet instead?”

Maybe. But maybe not. The problem is, solution-first feedback skips understanding.

I learned this the hard way when mentoring a junior designer years ago. I kept prescribing UI fixes instead of asking questions. Eventually he stopped exploring ideas and just waited for my direction. That’s not mentorship. That’s design puppeteering.

Now I try to ask before suggesting:

• “What led you to this approach?”
• “What alternatives did you explore?”
• “What concern are you optimizing against here?”

Questions create thinking. Instructions create dependency.

The best critiques feel collaborative, not hierarchical

Some of the worst critique cultures happen when seniority enters the room. You can almost feel it. The presenter becomes defensive. The reviewer becomes authoritative. Everyone pretends this is productive.

But the healthiest design teams I’ve worked with treated critique like collaborative problem-solving, not design court.

I remember an old design director I worked with who had this habit during reviews. Instead of saying:

“This is wrong.”

He’d say: “Help me understand this decision.”

Tiny difference. Massive impact. That phrasing lowers ego instantly.

Timing matters more than people admit

Not every feedback needs to happen immediately. Designers sometimes interrupt explorations too early. A rough concept gets over-criticized before it even has room to evolve.

And honestly? Early-stage ideas often sound dumb before they become good. I’ve killed my own concepts too quickly because critique arrived at the wrong stage.

There’s a difference between:

• exploratory critique
• refinement critique
• pre-launch critique

Mixing them creates chaos. You don’t critique wireframes like polished production UI. At least you shouldn’t.

Feedback should reduce confusion, not increase it

A good test I use now:

After my critique, does the designer have more clarity or just more doubt?

Because those are different things. Great feedback sharpens direction. Bad feedback creates spiraling. And designers already spiral enough on their own at 1:17 AM while zooming to 1600% wondering if 8px or 10px padding will save civilization :P.

Sometimes the right feedback is restraint

Not every design review requires a brilliant observation. This took me years to learn. Some critiques are driven by the reviewer’s need to contribute, not by actual problems in the work.

Silence is underrated.

If something is working, saying: “This solves the problem well.” is valuable too. Designers rarely hear that enough.

Final thought

Giving feedback as a designer is less about having the sharpest eye in the room and more about helping someone think more clearly. That requires empathy. Precision. Timing. Humility. And occasionally resisting the overwhelming urge to redesign someone else’s screen during their presentation.

Which, to be fair, is still difficult for me sometimes too.