Picking the wrong battle, in the wrong setting, with the wrong tone, is a quick way to get labeled as “difficult” instead of “an expert in this.” But staying quiet has a cost, too.

Design is brought into the room because designers understand users, systems, and how they connect. Every time a designer or design leader backs down, that decision lands with someone who understands this connection less. The negative result usually raises its head later, in the form of usability problems at launch, costly redesigns, and the UX department being generally seen as more of an execution function rather than a strategic voice.

But, there’s a third option: understanding your stakeholders well enough to set recommendations that actually land—not just pushbacks.

Formal design training covers how to research, design, prototype, test, and implement. It doesn’t teach you how to manage a VP’s expectations, negotiate a timeline, or read a room full of stakeholders who don’t all want the same thing, and then align them.

But whether or not you’re prepared, if you want to advocate for the full design process to be done properly, you have to learn this art. There’s no opt-out: a lack of stakeholder management can have just as much of a negative impact as bad stakeholder management.

Early in my career, before founding Outwitly, I was running a journey-mapping project. The client sent a survey link to recruit interview participants using criteria we’d built together—but when I started analyzing the results, I found the survey had been sent to the wrong people. I flagged it to our main point of contact, a director of CX new to the role, and suggested fixes before we continued.

But, the director didn’t want to delay the project, and after a back-and-forth over email, told us to proceed with the interviews as planned. I didn’t push back.

At the final presentation, I added a caveat about the target list up front. The VP, sitting in for the first time since kickoff, was furious that the research hadn’t actually been conducted with the right people. When I mentioned we’d flagged this by email, more than once, the director claimed it was news to them and threw me, as the “consultant,” under the bus. The client wasn’t happy—and the only thing that saved the firm from eating the cost was that every warning I flagged had a paper trail via email.

The likelihood of those stakeholders seeing design research projects as “worth it” in the future was diminished. When getting any user research or testing greenlit is a battle, this loss of faith perpetuates a bad or shaky rap for the discipline as a whole.

This experience taught me three things:

When running a user interview, you’re meant to do two things: stay curious about what’s driving the user, and remain patient enough to uncover the motivations behind their behavior.

If you give your stakeholders the same understanding as you do users, it’s easier to see how their pushback isn’t about your ideas at all. Instead, it’s likely about the goals they have—the goals that you either haven’t asked about, haven’t fully understood yet, or haven’t held empathy for.

A short one-on-one conversation, interview, a stakeholder workshop, or even reading the company’s last annual report or town hall recap will tell you more about what’s driving a VP’s decisions than any meeting agenda will. That context is what lets you frame a recommendation around a business goal they already have, instead of focusing it around user needs and hoping they’ll immediately care.

It also helps to know who’s who in the room and who can help you understand the stakeholders and org better and back you up.

Champions come in more than one type: some are visionaries who talk openly about where things should go, others are quieter doers who don’t generate big ideas themselves but are excellent at getting other people’s ideas done.

You want both—look for the ones who move between groups, sit in meetings outside their own team, and already have the ear of whoever holds the budget. Ask what they’re focused on, offer to help with something small first, and let that turn into them mentioning your work in rooms you’re not in.

Objection-handling isn’t just for the sales team.

The stakeholder objections and responses I’ve kept as reference material for my teams over the years all break down into the same three steps: acknowledge the concern behind the request, reframe it using what you actually know, then offer a concrete next step that addresses what they were worried about in the first place.

It always comes back to the fact that people can’t take in a different perspective until they feel like the first one was actually heard.

Take one objection almost every practitioner hears: “We don’t have time to do all that research.”

Here’s a version of what you could say in response:

Acknowledge: “What I’m hearing is that deadlines are very tight and research feels like it’s standing between us and shipping.”

Reframe: “However, doing research up front will actually save us time and money in the long run—it will take more time to fix issues after launch than it will to design the right product from the start.”

Offer: “What if we scope a lean version instead: a handful of interviews with customers who actually deal with this problem directly, so we protect the timeline without flying blind?”

Deliver well on a scoped offer like this, and stakeholders won’t treat you as someone who just executes on decisions.

Jargon gets trained into practitioners early on—how fluently you talk about journey maps, service blueprints, or research methods is often exactly how peers and instructors judge your competence. But executives who hear design buzzwords tend to tune out, unless you can connect your practice to the business impact it will bring.

Speak in terms of the KPIs they already track (or that your research has found they should track), and do a mental translation before assembling a slide deck and getting on a soapbox:

Once you’re speaking stakeholders’ language, they might agree to more of your recommendations, but that doesn’t mean they automatically trust you. The actual goal can’t just be telling everyone what to do. You’re not taking back design decision-making.

Instead, you’re turning decision-making into a collaborative process, with the aim that stakeholders will then recognize your expertise, understand the full value of collaborating with you, and start involving you in more decisions.

All of these alignment strategies contribute to trust in the design process, buy-in for the final deliverables, and wiggle room for shaping next steps:

The more you work in the open like this, the less you will need to, because stakeholders will gradually become more confident in your decision-making.

No one got into this discipline with the intent of being a stakeholder whisperer. When it all feels like it’s taking time away from actual design, try to remember that in reality, it’s part of the process… or at least a doorway to influencing that process.

I’ve seen entire business roadmaps shift because of insights and recommendations that design put on the table. It can still happen, and it can bring strong ROI with it.

It starts with knowing the people across the table well enough that you can align your recommendations with their goals. Do that consistently and the next big product design decision won’t require your pushback, because it will be yours.