A design leader has vastly different responsibilities than the designers who are in the weeds. Design leaders ensure that their team works well, that the design team evolves, and that they are always aware of advanced techniques and other aspects necessary to move the team forward.
To do so, team leaders should work with their group, but in addition to that, they have to keep close contact with other stakeholders to get help. For example, If the team wants to move from working with software A to software B, the leader talks with the overhead managers to get permission to buy the license.
This isn’t easy, especially if you’re new to leadership. I’ll teach you how a design leader can communicate well with all the stakeholders in your organization.
The most important tip I can give about working with stakeholders is straightforward: We must build great relationships with them and always be in contact with them.
When I talk about building relationships, I mean that you should know them personally, not only in terms of work. For example, ask if they have a family, where they live, and their hobbies.
This is because good relationships start with real communication between people rather than about work. If we are focused on work, it can dry up relationships.
If you know the people you ask and are interested in their lives, they feel you care about them. Then, they will be willing to help you when needed.
For example, when you are on a call with a stakeholder for the first time, start with questions about themself. If you meet with them on Monday, ask about the weekend, what they did, and how it went.
Be a person before you are a colleague. It will add more connections between both and enable you to work with them more easily:
Some stakeholders may not like this approach, so you’ll have to dial it back if you find they don’t reciprocate your desire to get to know them as a person. Your colleague may prefer privacy, which is totally understandable.
There are many ways to talk with the company stakeholders. It can be in a one-on-one meeting, an email, a message, or a meeting with many stakeholders. The most important thing is communicating clearly and using the most accurate medium.
For example, one message will solve the issue if you want to update product managers about the design system process. It saves meeting time, and the other side feels you respect their time.
You can use a video if a text message is insufficient and you must explain complex information. As always, one image is worth a thousand words, and one video is worth a thousand images.
Another option, and the most classic one, is to have a meeting. This option is good for brainstorming. That way, you can ping-pong ideas much faster and arrive at a solution quickly. My rule is to select the best medium to communicate efficacy with minimal effort and avoid meetings whenever possible to respect people’s time:
People often interact like magicians. They have an idea and want to push it forward, so they work on it intensely for a long time, and then, when they think it is ready, they show it to the stakeholders in a meeting.
This is a major error. People do not like changes, and every change, even small changes, must be cooked on “low fire.” Otherwise, people will ignore them.
It’s best to work on your project in small steps and involve everyone. You should listen and understand them, build the solution with them, and then they will accept it.
For example, the designers work slowly on the project, and delivering the design to development takes a long time. You conducted a brainstorming workshop with the designers to understand why. You found that they work slowly because their UI kit is outdated. Your company made many improvements to the software, but the team did not update the library.
You decide to improve it. To make the change, you realize that you need all the team to work on it for five days. That means the product teams will not have designers for one week. Now, you need to convince the stakeholders, in this case, the product managers, to make the change.
Organize the process on paper and write why the design team needs it, how it will benefit the stakeholders, and what the process is. To convince the stakeholders, you must be accurate and explain how it benefits them, not only the design team.
You can use absolute value to make it easy to understand: “It takes us five days, and after making the change, the design process will be 25 percent faster.”
I like to do it one-on-one; that way, I can explain the need and the method and solve issues individually. If I have three product managers to talk to, I will do it individually and solve their problems.
If you see that some stakeholders do not like the idea because the designers will not work with the product team for five days, you can talk like a politician (Politics is part of the job) and see how you make a deal with them to get their approval.
If the stakeholders disagree, you must understand why they disagree and solve the issue with them. The “why” is the important part (why they disagree). Once everyone agrees, you meet with them and show them the plan. You enter the meeting, and you know that all the stakeholders agree. Once approved, you run the plan.
Knowing your position in the organization and other stakeholders’ roles and influence helps you understand who to talk to to move things forward.
For example, imagine that your team wants to use new software instead of the software you use in the company today. You know that the new software costs 15 percent more.
Who is the person that you need to talk to? Is the VP product, the CFO, or direct the CEO? Who is the person that approves it? Be aware of your and others’ roles to build the strategy well.
Consider the design team structure, how it is built, and how the designers work:
These questions guide you in understanding how and with whom to speak in the company.
For example, if you are a team leader with three designers under you, each designer works on another product squad.
If the product manager in one of the teams limits the designer’s freedom, it’s best to speak directly with the product manager to resolve the issue. On the other hand, if all the company’s product managers consider the design less important, you will need to talk to all the product managers and the company’s CEO and explain its importance:
When you are a leader in the team, you have three main stakeholders to focus on: one is the people above you in the organization, the people at the same level as you, and the third is those you manage.
Some people think that stakeholders are people who are above and on the same level as you in the organization, like product managers, CEOs, and CTOs, but not only them. According to Wikipedia, a corporation’s stakeholder is anyone essential to its survival.
So, the designers on your team are also stakeholders. We must consider them as stakeholders and see them as people we manage.
Here is a step-by-step guide on how to speak with two stakeholders, a project manager and a designer from your team, to solve a gap between them. I will guide you through the steps you should take. The explanation will focus on a specific topic, but you can use this framework for other issues.
You are a UX lead with four designers on your team. Each designer works in a different product squad with a different project manager. You are responsible for your team and for shaping the company’s design vision.
In a meeting with one of the designers, they tell you they do not feel comfortable working with the product manager because the tasks are unclear, making the work difficult.
The product manager changes the needs every two days, which leaves the work unfinished. There are always new things to do, and the task takes a lot of time to complete. You decide to solve this issue and help the designer on your team.
The first step is to define the problem well. This is the most critical part. When the problem is described well, it will be easier to find a solution.
Talk with the designer and ask many questions like:
Asking these types of questions will help you see the picture much better.
Ask the designer for specific examples, not talk in general; guide them to talk about particular cases.
You can ask: Could you give an example of a change the PM made in the scope of the last project?
Ask questions to understand the issue, then define the issue.
Here are some examples:
Let’s say that the problem is: Often, the task scope changes during the design process, leaving tasks unfinished, which causes the designer a lot of stress.
Ask the designer if they talked with the PM about it and how they tried to solve the issue. It is possible that the designer said they did not talk with the PM about the topic or talked with the PM, but the PM would not take care of it and did not listen to them.
This will give you a better perspective on the designer and their actions to solve the issue.
I prefer they talk with the stakeholders before I get involved. If they can solve the issue, they will become more confident and discuss more things.
An important point is that not everyone knows how to have this conversation, so you should guide them.
For our case, let’s say that they talked with the PM, but the PM did not do anything about it.
Ask the other designers in your team and the other product managers how they work and how the tasks are defined in their product squads.
You may find that the other product teams work well in those aspects or that more designers on your team suffer from this issue, too.
It changes the way you talk with the stakeholders and solve the issue. If it occurs only in a specific product squad, you can make one strategy; if it happens in all teams, you will take another.
For our example, let us consider that the issue only happens with the specific product team. In that case, take the time to understand how the other teams work to define the scope and study it well.
You can then build a strategy that aligns with the other product teams in the company, which will help you convince the product manager to adapt it.
Ask the other product managers how they define the scope for the designers in the squad. You may find that there is a specific process that all the PMs should work with, and one of the managers does not work in that way.
That will help you solve the issue because you will not need to invent something new; you will be able to use the same methods other project managers use.
Remember the point I mentioned at the top of this article: Always maintain contact with other stakeholders in the company; it will help you have an open door to talk with them easily.
Let’s say that there is a process in the other product teams, but it is not the same across the company.
There are different ways to solve the issue. I like to involve both sides deeply in the process. It makes the solution agreed upon by both. It is like a negotiation in which people buy a house; the agent bridges both sides until they agree.
In this process, you meet with both sides separately and listen to their point of view.
For example, the PM can say:
From the other part, the designer can say:
You understand the issues and can find a solution when you hear both.
For our example, the PM says, “I have no time to write the scope because he has a lot of work.” The designer says, “Often, the scope changes during the process.”
The problem is clear: there is no written scope, so no one has a guide on making decisions, and adding or removing things is easy because nothing is defined.
You know that product managers usually should write the scope, but the designer may do it if the PM has no time. It’s not an issue. The idea is to solve the problem, not do things like in the book.
Go now and talk with the designer, explain the product manager’s point of view, and ask if they care to write the scope. They may say: “Yes, I can write it, but I do not know how.” In that case, you can build a process to define the scope with the PM.
You ask the PM if they agree to create the scope with the designer, and the designer can write it. Once you agree with both sides on the solution, meet with the designer and the product manager to discuss it.
In the meeting, you shape the process with them; they must agree on defining the scope. For example, the PM comes with an idea, the designer shapes it, and they meet to write a scope for the task.
You can also agree on the scope format in this meeting, such as a user story with acceptance criteria. The process is about hearing and understanding both sides and deciding with them. You are only the bridge:
When you are a leader and you want to make changes or push new ideas, there is one thing that you need to remember very well.
You must take ownership of the topic you want to advance; no one will take it for you or do the work for you.
You are the person who”does not sleep at night” because of it. You are the person who needs to build the strategy, you are the person who asks for the meeting, and you are the person who must communicate it.
You are the person who needs to ask about the updates, how the process works, and what the other people did about the topic.
If you are the leader, you must do it. It will not happen if you do not.
In this article, I showed you how you can speak to stakeholders as a UX leader.
First, we looked at an important topic about working with stakeholders: building solid relationships with them, which is the basis for everything. We examined the different mediums you can use to communicate with them and why you should make changes step by step, not in one big action.
We saw the importance of the organization’s structure and how understanding it can help you move things forward. For example, to change to new software that costs more than the app the team uses today, you must know who makes the money decisions in the organization.
At the end of the article, I showed you a framework you can use to solve an issue between two stakeholders (a product manager and a designer) to overcome a problem when the scope is not defined well.
Last point: every person is unique, and the art of communication is something we need to adapt to each person differently; people are complex, and only some things will work as written in the book.
Header image source: IconScout
LogRocket lets you replay users' product experiences to visualize struggle, see issues affecting adoption, and combine qualitative and quantitative data so you can create amazing digital experiences.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
Nostalgia-driven aesthetics is a real thing. In this blog, I talk all about 90s website designs — from grunge-inspired typography to quirky GIFs and clashing colors — and what you can learn from them.
You’ll need to read this blog through and through to know what’s working and what’s not in your design. In this one, I break down key performance metrics like task error rates and system performance.
Users see a product; designers see layers. The 5 UX design layers — strategy, scope, structure, skeleton, and surface — help build UIs step by step.
This blog’s all about learning to set up, manage, and use design tokens in design system — all to enable scalable, consistent, and efficient collaboration between designers and developers.
Learn more →
