How to deal with your design getting harshly rejected
Seeking clarification after your design is rejected can offer valuable insights

Part of UX design that doesnโt get mentioned often is dealing with rejections.
As Designers, we are often generating a lot of design recommendations for problems that we find during iterative testing. As a result, we often deal with โsoft rejections.โ These include repurposing design elements for other solutions or not being part of the Minimal Viable Product (MVP).
But on occasion, we might get a firm rejection, often accompanied by harsh feedback. It might be possible that the stakeholder is mean, but more often than not, theyโre just trying to articulate themselves around a complex topic.
In these cases, one of the worst things that you can do is immediately react: Iโve screwed up presentations before because I responded at the moment.
So before you take any drastic action, such as tossing out your work or cursing out your stakeholders, pause. Take a deep breath and realize one thing:
Your stakeholders might not have experience thinking about empathy.
Empathy vs. problem-solving
Empathy is a foundational aspect of UX, as it is how we learn to advocate for users. Understanding, mirroring, and then sharing another personโs expressions, needs, and motivations help us design the best user experience for our users.
But it might be training your stakeholders donโt have. They might be trained in something that sometimes runs counter to empathy: finding solutions.
It doesnโt sound like they would conflict at first. But when you attend meetings where weโre advocating for understanding the user better with more research, and someone else wants to jump on the first solution anybody speaks of, you can start to see where they run into issues.
Finding solutions is an admirable trait at times. Problems come up during work, and finding solutions promptly helps move the project along. But when your stakeholderโs day is filled with mostly finding solutions instead of empathy, that may be what they try to do with their feedback.
This often results in one of two types of harsh feedback:
Stakeholders will lump both criticism and solution into one piece of feedback.
Stakeholders will give something that isnโt actionable from a designerโs perspective.
You may have heard the first type before. For example, โI hate the way this pop-up window is designed. We should go with another screen instead.โ
This is often tied to that problem-solving mindset. Stakeholders might not feel comfortable critiquing a problem without offering a solution, so they try to develop a design solution (while not being a designer).
โComplaining about a problem without posing a solution is called whining.โ
โ Theodore Roosevelt
If the only other design they saw was a โnew pageโ that you tried out before had run into a ton of issues, they might say something like, โI remember we had tried out another page, is it worth it to revisit it?โ With both types of harsh feedback, we should take the same essential step to get started: set your ego aside and seek clarification. Doing that allows you to do something that the stakeholders not only will understand but will encourage: turn whatever criticism youโve received into actionable feedback.
Deciphering unproductive feedback
UX Design often has to deal with vagueness, as we often have to decipher whatโs problematic, needed, or wanted by both users and the business. For example, a user rarely says, โI want this screen designed with X, Y, and Z.โ More often, they say, โI donโt like this. Can you make this better somehow?โ
Our job is to seek a further understanding of what the user needs to build a better user experience.
We should think of stakeholder feedback the same way. Sometimes, there might be a good reason for rejection, or sometimes because of something completely unrelated to design. So itโs our job to dig deeper past poorly constructed criticism into actionable feedback. Hereโs how we can do that.
Pause, and breathe for a moment:
I emphasize this a lot because Iโve made this mistake in a high-tension setting before. Take a moment to pause, and make sure that youโre not going to react immediately. When youโve done that, thereโs one other thing you should do.
Assume positive intent:
Your stakeholders arenโt out to get you, and they arenโt giving you feedback to insult you (usually). Instead, they want to build a good product as much as you do: they have a concern, which is why theyโre speaking up.
But sometimes, they might be voicing concerns with context that you donโt have, which is why you have to ask about it.
Seek context about the larger system:
One of the things that Iโve learned, working for large organizations, is that youโre often designing a product thatโs part of a more extensive complex system.
As a result, design recommendations might often be shot down because your product interacts with the more extensive system.
For example, imagine working on an application initially accessible through a user portal. If you advocate for putting a notice at the top of the portal page signaling the user to pay attention, you might get shot down immediately. Itโs not because itโs a bad idea or doesnโt follow usability principles. Itโs because youโre part of a larger ecosystem, with many projects that might be fighting for attention and position on the page.
As a result, we might want to consider Dr. Russell Ackoffโs approach to seek out context with how our project fits into the larger system:
What system is this experience a part of?
How does that containing system work?
What key role does the experience youโre working on play in the systems containing it?
However, thatโs not the only clarification we can seek out.
Ask open-ended questions for clarification.
One of the most valuable things you can say in response to poor feedback is, โCan you expand on your thoughts?โ When you ask for more details, you often might find that the stakeholderโs problem isnโt what the feedback indicates: itโs something else entirely.
Other open-ended questions to ask:
Why is that important to you?
Tell me more about that, please.
Can you tell me why that is problematic?
Another helpful thing to do when seeking clarification is to turn their feedback into a problem statement. Doing this helps narrow down what youโre hearing into something more actionable.
In either case, these steps should help you turn their feedback into something you can take action on.
Poorly constructed criticisms can become valuable feedback
Whether youโre starting in design or have been around for a while, itโs never a fun time to get a harsh rejection. But often, itโs not because the person is out to get you or otherwise doesnโt like you: many times, itโs just poorly constructed criticism.
Sometimes, they might have valuable insights, but they cannot articulate them well. Other times, it might just turn out that something unrelated, like the โdraft contentโ of the website, distracts the person from seeing the design you put forth.
But whatever the case, you shouldnโt take it personally. Instead, spend a little more time digging into the response, and you might unearth some valuable insights.
Kai Wong is a UX Specialist, Author, and Data Visualization advocate. His latest book, Data Persuasion, talks about learning Data Visualization from a Designerโs perspective and how UX can benefit Data Visualization.