3 tools to help you win over stakeholders

Because a prototype alone isn't enough. You have to be tactical to get buy-in.

🕰️ Est. reading time: 4 minutes

---

A prototype can speak a thousand words, but it won’t guarantee stakeholder buy-in.

Here’s the hard truth: Finishing your prototype, in reality, only does half the job.

The other half is effectively communicating your design to help others understand the value it brings to the table. And effective communication goes beyond just walking through your design—you need to know your stakeholders, frame your message appropriately, and, at times, approach them individually.

Bottom line, it's all about building relationships with them.

Here are three tools you can use to be more tactical in navigating your relationships with stakeholders and gaining their support.

Design Buddy is a free, reader-supported publication.

Subscribe to receive my next post in your inbox. If you enjoy the content, a small pledge for a ☕️ cup of coffee would help me continue creating quality content. Thank you!

Job titles can be a practical starting point for understanding your stakeholders.

However, don't rely on stereotypes—everyone has their own unique experiences, values, and interests. I've worked with executives who, surprisingly, care about pixel-level details alongside the business impact

So before presenting your work, take a moment to reflect on how well you know the people you're working with.

🧰 Tool: Map out your stakeholders and align with what they value and what interests them.

Tip: It's okay to start by making assumptions when mapping stakeholders. Over time, through observation, you'll gain a deeper understanding.

Example →
Who: Jim (Product Manager)
Interests: Roadmap alignment, feasibility, low-effort and high-impact ideas, metrics, build MVP for continuous improvement
Values: Efficiency
Concerns: Effort required for implementation

Jim values efficiency and is always concerned about the effort involved—worried that the investment might be too hefty and not worth it in the end—he often asks,

'How can we validate this before moving forward with implementation?'

'How can we approach this as an MVP?'

'What can we do if we fail?'

Okay, we’ll get back to Jim later—but for now, you have a better understanding of him.

Once you have a clear understanding of your stakeholders, frame your content (idea, solution, or design) within contexts that align with them.

The goal here is to make the rectangles, texts, buttons, and flows you’ve designed make sense to them.

Frame your design to explain why it matters to your stakeholders and why it aligns with their goals.

Connect the dots: your idea, user outcomes, and business impact.

User outcomes are about why this would help users and why they’d like it.

Business impact is the numbers the company cares about—things like user base, LTV:CAC, or revenue, depending on what you’re working on.

🧰 Tool: connect your idea to what matters to your stakeholders.

Note: depending on your contexts, you may want to include ethical perspectives, technical feasibility, market positioning, or anything that matters to your stakeholders.

Example →

Your idea is to simplify a long, complex form by breaking it into smaller, cleaner steps that are less overwhelming for users.

You can stop there and present it to your stakeholders. But they might not understand why breaking the process into steps could be the right direction. Once, I received this feedback: “Isn’t this making more steps, which creates more friction?”

You need to frame your design by explaining why it benefits the users.

The user outcome: Breaking the process into smaller steps makes it feel less overwhelming and helps users stay engaged. Lowering cognitive load reduces friction, making it easier for users to complete the task.

What’s in it for the business impact? If it’s easier for users to complete the form, what will happen? Form completion rates will improve → driving certain growth (e.g., revenue, user base).

☝️ Bonus point for Jim, who’s always concerned about efficiency, metrics, and continuous improvement: If we break the form down into steps, we can use data to identify which step has the most drop-offs. Smart, isn’t it, Jim? This approach will help us improve and make things better over time. The step-by-step process isn’t the final goal—it’s just the beginning. It’s our MVP for moving forward with better insights about our users. And as we progress, we can keep refining it to make things even more efficient.

This way, you're framing your idea specifically for Jim, making it more likely to resonate with him.

Approach your stakeholders individually to gain their support, rather than all at once. No matter how big or small your team is.

I currently work on a small team—sometimes a project involves just me and a developer, while other times it includes a content writer and a product marketing manager.

I always message the engineer, saying, ‘Hey, I want to hear your thoughts before I talk to our boss.’

At other times, I send the link to my design and provide some context to make sure it’s clear what I’m looking for from them. This way, others have more time to marinate their thoughts before providing feedback—then I follow up with a quick chat.

I have observed that approaching the team individually before the big meeting works much better than addressing everyone all at once.

When I haven't spoken to my team beforehand, it can sometimes be difficult and uncomfortable for them to provide feedback on the spot, especially with different people in the room. By talking to them individually beforehand, they already have an idea of what I'm discussing and can add their input if needed.

If there's an opportunity to include ideas from others, acknowledging them in the meeting can make a big difference. When everyone feels included in the idea, it gives them a sense of ownership, making it easier to gain their support. And with their support, you’ll have a greater chance of winning over your final decision-maker.

🧰 Tool: Plan who you want to approach, the timing, and what you need from them.

Example →
Person: Lead Engineer
Timing: After having wireframes with a clear flow and understanding of the required metadata
What you need from them: Feedback on feasibility and technical insights

What about Jim? Jim is always concerned about the effort required for implementation. He wants to justify every bit of effort against the expected impact. That’s why it’s always useful to talk to the engineer first—preferably separately—before discussing it with Jim. Why? Because Jim will inevitably ask, 'How much effort will this take?'

---

I've worked at companies of all sizes, from small to large, and one thing remains the same—design is only half the job.

Hear me out: Building relationships is just as important 😃.

Take your time to think tactically about what will work in your context.

I hope these tools are helpful!

Until next time,

Your design buddy,
Thomas

---

If you have any thoughts or tips, I’d love to hear from you!

You can also show your support by clicking the heart button ❤️ or sharing this with a friend, colleague, or fellow designer! It helps me spread this newsletter and reach more people. Thank you!