Why Stakeholders Resist Your UX Work, And How To Fix It

You've probably been there before. You might have spent weeks iterating on an idea that tackles one of the most frequent frustrations in your product. Your colleagues designers have already celebrated your efforts, and you even considered onboarding and loading behavior and accessibility and even error messages.

Yet when you present that work in a big meeting, there is... crickets. Silence. Little to none excitement. Definitely no understanding. And frankly, very little appreciation of that incredible work you've been doing behind the scenes all that time. In fact, it's even worse: there is loud skepticism and resistance to your work. And eventually come strong and opinionated voices from the back of the room: "I don't like this."

Nobody wants to be in this position. But then, how do you respond to it? How do you move from there? Let's see how we can reduce resistance, deal with non-actionable feedback and prepare for successful outcome by the end of that big meeting.

If you'd like to support my work, take a look at a friendly UX bundle: practical techniques on UX and design patterns in Smart Interface Design Patterns 🍣 and How To Measure UX 🔮 — hands-on video courses on UX. Use a friendly code LINKEDIN to save 15%.

Where Does Resistance Come From?

We often assume that resistance comes from personal opinions and political powerplays. There is definitely some truth to that and we shouldn't discount that, but I think that it's merely how it appears on the surface level. Below the surface, there are deeper, and much more personal reasons — often unrelated to you personally, or even your work.

There are usually 2 main reasons for resistance:

• People are afraid of consequences of your changes, or
• People don’t see any valuable upside of your work for them.

Both need to be addressed to dissolve resistance. And in its essence, it’s all about change management. As Jared Spool argued, “we often think that users don’t like change. Yet users go through small and big changes all day long. What users don’t like are breaking changes. Sudden interruptions. Blockers. Bad surprises. Changes that they don’t understand and can’t see any value in.”

That’s what we need to avoid. And we can do that by preparing people for change early on.

Prepare People For Change Before It Happens

The best way to diffuse resistance is not by convincing people that you are right (and they are wrong), but by sharing ownership of your work with them. By no means do I suggest design-by-committee, but rather creating the time and the space for stakeholders to see your unfinished, early, rough drafts and have a chance to shape them early on.

Chances are high that even after thorough discovery you will not have the full picture of the problem space, and you will probably not be aware of all the fine little strategic and political decisions not mentioned in the meeting but happening between hallways or behind closed doors. But if your design doesn't consider it (even if you weren't aware of it), it has very little chance of being successful.

As it turns out, to be successful, design work must be prepared for success, and often that requires explaining what it will do before it’s done.

Initial Stakeholder Interview

In the past, I would assume that my discovery should be the main foundation of my design work. And I think I have been overestimating my abilities, and underestimating the hidden knowledge sprinkled all over organization — somewhere between Confluence docs and stakeholder interviews and poor constraints and limitations of legacy systems.

These days, I try to get at least some sense of commitment before I design a single pixel on the screen — and most certainly before I walk into that big meeting to present any of my design work. In fact, I keep repeating it like a broken record but: I always try to avoid big revelations or big surprising announcements in a big meeting.

It starts with the very first, initial interview with stakeholders. In fact, that's one of those meetings that I pay utmost attention to and usually ask for permission to record. Simply because from past experiences, I know that I will have missed specific areas that were briefly mentioned but never properly discussed. Usually I go through that video multiple times and listen very, very carefully to what stakeholders say and what is often meant between the lines but never said — hidden concerns.

This is a template I'm using for the initial stakeholder interview:

Copy-paste friendly version:

Dear Ms. Krajewski,

As a UX lead on the project, my team and I are currently in the process of discovery. As we start our work, we’d like to better understand your pain points, expectations and success criteria.

1. Describe the purpose of the project in your own words.
2. Describe where this project fits in your daily work.
3. What’s the most important thing for us to get right?
4. How would you characterize the target audience?
5. If you could ask users one thing, what would it be?
6. What does success look like for you and your team?
7. What challenges are top priorities for you/your team?
8. How would you describe success criteria for this project?
9. What constraints or frequent issues should we know about?
10. What is your ideal level of engagement in the project?
11. What is your preferred communication method?
12. Anything else that’s really important for me to know?

This is by no means a comprehensive or absolutely necessary list of questions to ask, but it does highlight some critical areas that then guide the conversation in the right direction. When you listen carefully to things said and things not said, and then run stakeholder interviews in the same format a few times, trends start emerging. That's something we need to watch out for.

Of course we should also ask for objectives, KPIs, goals, org charts, any existing artifacts before that meeting, too — but my goal is to find clear answers to 4 key questions:

• What will it be like to work with them?
• What will it take to keep them engaged?
• What’s needed to bring them on our side?
• What’s required to build up their trust?

As you can read from the questions above, I do see it as a part of my work to prepare people for change before it happens. And it starts by diffusing concerns early.

Diffusing Concerns Early

When I go into a meeting with important stakeholders or important clients, my goal is not necessarily to get a commitment, or a green light or get more visibility — I want to build and maintain a strong, trustworthy relationship. And to me, that means that I need to make a few critical points pixel-perfectly-clear — way before asking for a commitment to a change.

First, I need to know what I want to change. And I need to know it very, very well. It shouldn’t be a fuzzy and broad idea like “rethinking navigation” or “removing friction”. Instead, I try to address it directly: “Restructure the Account section”, “Rewrite error messages”, “Make user’s key tasks more prioritized”, “Re-organize filtering”. You won't get any commitment to your work before it's clear what that work actually impacts, and how severely.

Second, I need to understand what this change means for the person I'm speaking to. The product might have a few broken buttons here and there, but people are very good at bending the rules and tweaking the flows to make it work for them. These buttons might look broken to me, but they might be perfectly fine four our customers — especially after 2 years of using the same (albeit broken) shortcuts and flows, over and over again.

Third, people have to see high value and low risk in the new way before they’ll consider abandoning the old. So I need to address both. That requires me to understand what will change for them, for their teams, for their units, for their business. But also what will change in their daily operations, as far as current workflows and integrations are concerned. We must really understand the needs, goals, objectives that will be affected as we will introduce these changes — and articulate the high value and a low risk that apply to them.

Fourth, I want to show unfinished work and ask for feedback before the meeting. I want to avoid situations when an important stakeholder will see my work for the first time in that big meeting. I should have approached and asked them for feedback way before that happens, so that I already have their general commitment to the direction when that meeting happens. To show unfinished work, I love using simple sketches on paper — invite stakeholders to contribute ideas and share feedback very early.

And sometimes, it's just a matter of trust, or confidence of your decision. Perhaps because you are operating on legacy systems — the very heart of the business, or perhaps because top-line business clients will be affected by your work. There, you won't get far without measuring UX before and after (and that's why I have a whole video library on Measuring UX) to make a strong case for the tremendous impact of your design work.

“Sorry, I Just Don't Like It”

Personal opinions are personal, and as such they are very hard to argue against. Not only because we, as people, are inherently bad at articulating and explaining our thoughts and our intent — but also because it at times feels like a confrontation of personalities and identities. And if anything, people protect their identity also instinctively, even if they are wrong.

As Filippos Protogeridis noted, "I don't like it" is one of the most commonly used yet unhelpful phrases in design feedback. What's more significant to me though is not even the feedback on its own, but the consequences of that feedback being expressed. Because as Filippos continues, "accepting feedback such as “I don’t like it” means we open ourselves to personal opinions, which can often be a slippery slope."

When feedback of that type emerges, I try to fight hard the notion of defensiveness. It's not about me winning in the meeting, and the other person losing. It's about gathering enough reliable insights to make progress towards our shared goal.

So when I realize that I trying to get in defensive mode, I always jump to re-iterating our shared goals. I want us to first agree of what exactly we are aiming to achieve here, and then decide on how exactly the current design helps or doesn't help us get there.

"I don't like it" is a symptom, not a diagnosis, and my task is to find the root cause. And typically targeted, open-ended questions help move from the vague to specific:

• Ask for more detail: "What is making this approach ineffective or unreasonable?"
• Focus on goals: “When you say you don't like it, which of our shared goals do you feel it's not meeting?”
• Isolate the problem: “Can you point to a specific area that isn't working for you? Is it the layout, the colors, the wording, or the overall flow?”
• Show data from testing: “That's a good point. Our user testing showed that 8 out of 10 users were able to complete the task with this design. Perhaps the issue isn't usability, but something else?”
• Level of confidence: “What's your level of confidence that it's not going to work, and why?”
• Lack of data: “Do we have any data or evidence that highlights or contradicts that behavior? Perhaps we should run some experiments or research on it?”

And then I invite stakeholders with a strong opinion to work together on a solution that would feel right to them. join me in a separate meeting Paper is fantastic and fast for low-fidelity sketches, so are whiteboards — and so I always try to invite stakeholders to contribute ideas and share feedback very early.

Find Hidden Concerns By Reflecting Back

Behind every resistance there are hidden concerns. These concerns are typically obfuscated behind vague and generic feedback. And very often these concerns are perfectly sensible, sometimes deeply personal and rarely aimed at you personally. 

The approach I try take is to “decode” and then address these concerns by reiterating the problem that we are trying to address here. In other words, I “reflect back” how I see the project for me and how I believe the project is seen by stakeholders, from their perspective.

So once I think I have a decent broad understand of the problem space, I ask each key stakeholder individually for a 20-25-mins meeting to confirm what I have learned. That's a meeting I can't be over-prepared for. That's the meeting where you build trust and confidence that you will need so much in the later stages of design work. In fact, I would argue that it might be the most important prep meeting I will have.

And in that meeting, I start off by explaining how I understood the main goals, concerns and challenges of the project at hand. Most importantly, I reiterate specific doubts and goals that came up during that initial interview with stakeholders. And often it opens door to all kinds of issues that haven't been mentioned before. Surely I take notes of them, too.

And then, I explain how I already have or how I will be considering all these concerns in my design work. I don't show any of the work done at all — in fact, I might show decisions I rejected already, and why, and the paths taken instead, and why. I want to be as transparent about what I do, how I work, and how I make decisions very early on.

And at this very meeting, I explain the value proposition that my work brings to the table for them, and how exactly it will address those concerns that they had brought up initially. And then I explain how I will choose what to do, how I will prioritize work, how I will design and when I will need their (timely) feedback, and also how I will measure the success of that work.

That meeting isn't the time to be too optimistic or paint an unrealistic picture — in fact, despite my boundless optimism, I try to be highly pessimistic, cautious and explain my level of confidence of what we can deliver and what we can't guarantee. It might not help every single time, but it sets a clear frame around that fuzzy "design work" that we do.

Wrapping Up

Too often we overestimate what people think of us and of our work. Most of the time, they have their own priorities and interests in mind that are way more significant than a UX project you are initiating. They might want to support you, but they need to have a clear picture about what value that project drives and what it means for them.

And: often people don’t resist your design — they protect their interests. If you can show how your design adds value while protecting their interests, that’s a safe strategy to bring them on your side. And nothing diffuses resistance better than that.

Useful Resources

• User Centered Design Canvas, by Alina Prelicz
• Articulating Design Decisions, by Tom Greever
• “I don’t like it”, by Filippos Protogeridis
• A Practical Guide To Difficult Conversations (+ Decision Trees)
• How To Deal With Difficult or Opinionated Coworkers
• A Guide For Difficult Conversations, by Adrian Raudaschl
• How o Navigate Tough Conversations With Your Team, by Emma C Siegel
• How To Manage Challenging Stakeholders (free eBook), by Productboard

Friendly UX Bundle: Interface Design Patterns + Measure UX

Meet a friendly UX bundle with Smart Interface Design Patterns 🍣 (15h video library) and Measure UX 🔮 (8h video library) and live UX training — with live sessions, real-life UX challenges, 1:1 feedback and UX certification. Ah, use the coupon code 🎟 LINKEDIN to save 15 off. Jump to details.

Thank you so much for your support, everyone — and (as always!) happy designing! 🎉🥳