The Skill Every Designer Needs But Nobody Teaches: How to Handle Feedback

As a designer, we constantly receive feedback from different stakeholders, on the problems we should solve, the design direction, and every choice in between: flow, color, font, animation.

Early in my career, design reviews left me overwhelmed. There were so many opinions, often conflicting. I didn’t know what to do with all of it.

What I’ve learned over the years is this: filtering feedback is a skill. Not all feedback deserves equal weight. The real work is knowing how to ask feedback, what to take, what to set aside, and how to respond to both. But the framework of how to filter feedback alone isn’t enough, your mindset when feedback arrives shapes whether you act on it thoughtfully or simply react.

In this article, I’ll cover:

• How to set up feedback sessions so you get useful input
• How to filter feedback and turn it into decisions
• A healthy mindset about receiving feedback

Before you ask for feedback

Most messy feedback happens because people don’t have enough context to give you useful input.

If you don’t give context, people fill in the gaps themselves and give you feedback on things that are out of scope, irrelevant, or already decided.

Before asking, be clear about two things:

1. Where you are in the process.

Are you exploring direction, or refining details? This tells people what kind of input is actually useful right now.

2. What you’re trying to achieve.

Share the goal of the project, any defined constraints, and what specific feedback you’re looking for. Is it the copy, the visual direction, or the user flow?

As a designer, you don’t want people commenting on color when you’re still showing lo-fi mockups. The good news? That’s within your control.

✨ The quality of feedback you get starts with how well you set it up.

When you receive feedback

Not all feedback is created equal. When something comes in, I run it through a 3-step filter

1. Is it relevant to the current goal?

Some feedback maps directly to what you’re trying to achieve. Some is a nice-to-have for later. Some falls outside your constraints entirely. Knowing the difference saves you from chasing every thread.

2. Have I already considered this?

If yes, explain your reasoning. Walk them through your rationale. This isn’t being defensive, it’s being transparent and it helps your stakeholders understand your decisions.

3. Does this person have context I don’t have?

This is the most important question. Stakeholders often carry knowledge you don’t, business direction, another team’s roadmap, customer complaints or industry shifts. Before you dismiss a suggestion, ask yourself: are they seeing something I’m not?

The mistake I made as a junior

Learning to filter feedback is one thing. But there’s a reason it’s hard: as someone junior, we often assume that senior people are always right and that their word is the final answer.

Here’s something I didn’t do enough of early in my career: using my critical thinking to challenge other people’s rationale. My design decisions were often simply driven by feedback from others and I just changed my designs without truly understanding why.

That’s not good enough, and it’s not fair to yourself or your work.

When someone senior gives you feedback, don’t just take it. Pause and understand it. Why are they suggesting this? Does it fit the direction, the vision, the constraints, the resources? Is it actually the best approach given everything you know?

This isn’t about assuming they’re wrong. It’s about making sure you understand the reasoning of feedback so you can make an informed decision, not just do what you’re told.

The mindset shift about receiving feedback

The framework above helps with the what. But none of it works if the feeling of feedback is working against you.

For a long time, feedback felt like a verdict on me.

When someone pointed out something I hadn’t considered, my first thought was: I should have seen that. I’m not good enough.

What I’ve come to realise is that’s the wrong frame entirely.

Working in a cross-functional team means you’re surrounded by people with expertise you don’t have, in business, engineering, research, operations. Product teams are built this way because no single person can see the full picture alone.

Feedback isn’t a sign you missed something. It’s different perspectives doing exactly what they’re supposed to do.

When a stakeholder flags a constraint, a researcher challenges your assumption, or an engineer raises a technical limit, that’s not a failure on your part. That’s the system working as it should.

Once I reframed it that way, feedback stopped feeling like an attack and started feeling like an advantage:

✨ I get to learn from people who know things I don’t. That’s actually a privilege.

Before we wrap up

Next time feedback arrives, pause before you act on it. Ask yourself:

1. Is this relevant?
2. Have I already considered this and can I explain why I chose differently?
3. Do they have context I don’t?

Then decide. Don’t just react.

Feedback isn’t criticism. It’s information. And learning to use it well can help you make informed design decisions and grow from the expertise of everyone around you.

✨Every time you receive a new piece of feedback, you have the opportunity to learn something new.