Early in my career, I watched a senior designer tear apart a junior’s work in a critique. Technically, everything she said was correct. The hierarchy was off. The spacing was inconsistent. The interaction pattern didn’t hold up under edge cases.
But she said it in front of the team, with no context nor curiosity about the designer’s intent. It was just a list of everything wrong.
The junior designer never fully recovered. He got quieter in meetings, stopped taking risks, and started over-explaining every decision before anyone could respond. It was like he was already bracing for impact.
The feedback was right. The delivery was a disaster. And the team lost someone who had real potential.
That moment shaped how I think about feedback more than any book or framework ever has. Here’s what I’ve built from it.
1. Start with curiosity, not critique
Before I jump into feedback, I ask: “What were you trying to solve here?” or “Walk me through your thinking on this.”
A couple of things can happen from this. First, I sometimes find out I was wrong about what I was looking at. Maybe the designer had constraints I didn’t know about. Second, the designer stays engaged instead of shutting down. You can’t absorb feedback when you’re in fight-or-flight mode.
2. Separate the work from the person. Then urge them to do the same.
This sounds obvious, but in practice, it isn’t.
“This interaction pattern is going to confuse first-time users” is a design problem we can fix together. “You made this confusing” is a character flaw. One opens a conversation. The other ends it. Watch your language in reviews. It matters more than you think.
3. Be specific about what’s working, and why
This isn’t a softening tactic. I do this because it’s genuinely useful information.
If I tell someone “the information hierarchy on this screen is really clear,” they know to protect that when they iterate. Vague praise like “good job overall” does nothing. It doesn’t build skill. It just fills silence.
4. Name the stakes, not just the fix
There’s a big difference between “move this button up” and “this button placement is causing users to miss a critical error state, which is going to create support tickets and erode trust.”
The second version gives the designer the reasoning behind the change. Now they can apply that thinking to the next screen, and the one after that. You’re not just fixing a design, you’re building judgment.
5. Calibrate to the person in front of you
A senior designer who’s been on the team for 3 years needs different feedback than someone 6 months into their first role. One needs to be pushed harder. The other needs more scaffolding.
And if someone’s clearly having a rough week? Sometimes you pull back on the depth of a critique and check in on them first. The work will still be there.
The goal isn’t to protect someone’s feelings. It’s to keep them in a growth mindset so they can actually use what you’re telling them.
Feedback that lands is a skill. It takes practice, but it’s learnable. Most people just never get taught how to do it.
The best designers I’ve worked with weren’t the ones who never got hard feedback. They were the ones lucky enough to have leaders who knew how to deliver it.