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.