This series was initiated as a place for you to learn more about service design and journey mapping software. Our co-founder Marc Stickdorn and the Smaply team share their experience on how to embed and scale service design in organizations. The sessions usually kick off with a short introduction to the focus topic to bring everybody to the same page, followed by your questions and deep discussions of best practice examples.
On this page you find the recording as well as the transcript. Additionally, this session is available as a podcast on Spotify, iTunes and Google Podcasts.
Overview
[07:25] Who should complete a stakeholder map?
[09:30] How do stakeholder maps interact with other features of Smaply?
[18:50] How do you explore and identify conflicts between stakeholders?
[21:20] How frequently do systems change and therefore also the system maps?
[22:45] How do you find and choose relevant stakeholders?
[25:10] Who are we putting at the center and how complex do we want to make our maps?
Introduction
Marc:
We’ll talk about what the different tools are, how they look like and what kind of information each of these maps contain. I'm going to start with stakeholder maps.
Stakeholders are usually people, organizations or groups of people. You put someone in the center of such a map, for example your customer. Then you arrange different stakeholders that are important for this person around. You can do it for a customer from a customer perspective but you can also do it for projects where you then put the most important people of this project in the center, perhaps a project lead. And then you arrange the various internal players that are important in this context. In this example you see three simple circles. You can arrange your stakeholders around the person in the center, ranked by importance. The more important a stakeholder is, the closer you put them in the center. The less important they are, the more you put them out.
There are different backgrounds for it, but the three-circle map is one of the most used ones. There is an optional thing you can do for a stakeholder map – the transition to the next category of maps. You can draw relationships and describe relationships between these different players, so you can focus on specific aspects. One particularly interesting one is trust: who trusts whom in the network? Whenever there is a lack of trust, you will see that processes take longer, that you need contracts, that everything costs more money to actually get into relation and so on. If you then build out these relationships a little bit more and you visualize an exchange of values between these different players, we talk about a so-called value network map. Value network maps can show you where you have the financial streams in the system, where you have a flow of information in the system.
An exchange of value is not only monetary value or products and services, but it's also information. If you use social media like Facebook, you might not pay for it with money, but you pay with your data. Often a relationship is bi-directional, there's an exchange of values. Now, if we go one step beyond that, we talk about so-called ecosystem maps. And ecosystem maps not only include people and organizations but also other systems like IT systems, mobile apps, machines maybe places where people meet.
If you think about for example a mobile app: there is someone responsible for the app and the data comes from somewhere – so you can visualize all the relationships the app has. The thinking behind that, the logic when you create such a map is: everything what is now a machine, an app or a website used to be people. Often it helps if you visualize the systems there, because they again connect different people. And it helps you to understand the whole system.
Who would complete this map? Senior leaders only, or would you involve all employees?
Marc:
It depends on what kind of map you're doing. It sounds to me like you're talking about an internal map, focusing on internal stakeholders. Perhaps for a project to understand who's involved in it, I would recommend to not only work with senior leaders. Whenever you talk with people from one perspective, you only get this perspective. You will then see who is important from their perspective, but I would do different maps. I would understand it more as a research thing in the beginning. Moderate a co-creative workshop, it can be face to face where you put a system map template on the wall, or where you use tools like Miro or Mural, where you can all work on the same map at the at the same time. You have all the flexibility, quite like a whiteboard.
You can put different stakeholders on it, from different perspectives. And then you compare those and once you add that step, it makes sense to actually put it into a tool like Smaply. Here you can then summarize all that into one map, where you can start analyzing it, filtering it for different relationships like show only the trust relationships and so on. So starting with different perspectives first, and then summarizing would be my approach here.
Nicole:
I would second that it's always really interesting to see how different stakeholders create a stakeholder map. How different people in the business see things, who they put in the middle and how they think about that ecosystem around it can be a really good learning exercise. Especially when you have multiple people do it.
Can you elaborate on how stakeholder maps interact with other features of Smaply?
Marc:
It interacts with personas. A stakeholder map visualizes different people or organizations, so a persona represents a person or a group of people through a fictional profile. And obviously you can put personas on a stakeholder map besides stakeholders where you don't add a lot of information. So that's the connection to personas.
If you look at it from the perspective of a stakeholder map, you can zoom into one profile on the map and understand more about the background. Then, on the other hand you can connect it with journey maps. You slip into the shoes of a persona and you follow that experience step by step. When you create a stakeholder map in your mind, very often you're actually going through a journey map already because you're going through an experience. You will think about who is in touch with that person and who is important to them.
It is a very different visualization though, and that's why I recommend adding a lane called “stakeholders” on a journey map. There you can simply list out who is in touch with that persona at any step of the journey.
This is the repository you then use for your stakeholders on the stakeholder map. The stakeholder map then gives you the answer on how important these different stakeholders are. There might be people who are in touch with the customer regularly, but the customer doesn't realize that they are important. From their perspective they put them rather outside on the stakeholder map. There's another link between a journey map and a stakeholder map. And that is when you go into backstage processes. You can add a lane called backstage processes where you can visualize what the different department teams within our organizations are and what processes they are doing. Again you have a list of internal teams and systems that you can visualize on the stakeholder map.
All of these three tools are actually interlinked. You can dive deeper into each tool here: Personas, Journey Maps, Stakeholder Maps.
I would like to know best practices for identifying stakeholders especially for digital transformation in the public sector.
Marc:
Especially interesting right now because if you think who is driving digital transformation, there has been this meme out there for a couple of months:
It is the pandemic that actually forces organizations to move online. How do you identify the key stakeholders there? I would always start from two different perspectives: on the one hand from the perspective of the actual user, in this case it is your employees. Those people who then suddenly work in a different way. If you are in an office situation, I recommend visiting your colleagues at the workplace and do a quick interview at their workplace. This is a tip also for the regular working experience, contextual interviews.
Look out for all these little post-its, that we have around our office, around the monitor. Very often these post-its are shortcuts or ways to hack the system. This means that the system as it is right now, doesn't allow an employee to achieve something. It's a shortcut in the process and a workaround, because they can't use the software. They can't use a tool.
All of these help you to list out the pain points your employees have, but then also who are the ones that they reach out to for help at the moment. Stakeholder maps help you because you can visualize the people who are blockers in your organization, the people who encourage others to work, the people who help others to work and zoom into different perspectives. Do two or three perspectives. One from the perspective of a user and one rather from a project perspective. There you can visualize the decision makers and the different agendas of the different people. Often you identify that digital transformation doesn't get forward because of internal conflicts and internal politics Visualizing usually helps to solve these issues.
Nicole:
I've done a lot of service design work in the public sector. For me as a service designer who's often working on a single service, for example moving an application for a citizen program online, we're usually trying to start using human centered design practices to do that. Doing this exercise and doing stakeholder mapping can be really important for identifying stakeholders outside of that government team, or outside of core government. Who else is involved with the citizen, especially because there's so many siloed services across government? Citizens often get really important parts of the service from completely different departments. When you pull together your frontline staff, your program managers, your directors and maybe even some people who are in tangentially related departments, you can learn who a lot of those other organizations are that are supporting the people at the center to get what they need. They can really help you understand who you need to talk to outside of the organization to get a good understanding of how the service is running and what really needs to be looked at.
"Digital transformation at scale: why the strategy is delivery" is a book written by a whole bunch of people, who basically started the digital transformation at the UK government. Most governments are kind of modeling or at least learning a lot from how they did things in the UK. This book tells the story of how they've started up a consultancy just sort of walks through what digital transformation is and the definition that I really rely on. It's really about completely changing how the organization works to put service design practices, human-centered design practices and the citizens themselves at the heart.
If we can't identify the user's needs, we're not doing it.
That's the very core tenant of everything. They also talk about all the other stuff that needs to change. It's a great read.
Someone used a stakeholder map or value network map that explored what was important to each stakeholder, especially those closer to the center and then identify conflicts. The solution has to consider the other stakeholders to be successful. Have you done this and does Smaply support it?
Marc:
Identifying conflicts because the solution has to serve both. I would do that not only when it comes to prototyping new solutions, so refining your concept, but also when doing research.
Because starting a stakeholder map will help you to understand who plays a role and who should you actually talk to in such a project. and that is one of the key areas how we use it. It helps a team to understand a system and that guides you towards where we need to focus on, who do we need to talk to, who do we need to invite to prototyping sessions or to test our solution to make sure it works.
Smaply supports the visualizations, it doesn’t support the testing. For prototyping itself you need to use different prototyping techniques depending on the project you work on. However on the website of our book thisisservicedesigndoing.com you find 54 different method descriptions and loads of them refer to prototyping and a few of them also to stakeholder mapping.
In your experience how frequently do systems change and therefore also the system maps?
Marc:
A system map is just a snapshot and it can't visualize the changes over time, so what you need to do is a different system map for different moments in time.
I once did a project where we looked at the tourism industry of a whole country during a crisis. One of the key ideas there was to map out the whole industry using
stakeholder maps to identify what the problems and the conflicts are at the moment.
We already mapped it out two years earlier (before the crisis). When comparing those two we got a clear understanding of what changed and how we needed to adapt to it.
So – yes, systems change but there is no guideline for how often you should do it. There are some systems that change rather slowly and others that change rather quickly, so it depends on the context of how often you should do that.
How do you find stakeholders and how do you decide if they're relevant or not?
Marc:
Let's compare a stakeholder map to a map in geography. If you create a stakeholder map, you can zoom out where you don't see the different teams and departments but a summary of the company. The different players are rather abstract but you understand the system on a big scale and then you can zoom into certain aspects of that. Here you suddenly see more details, where you see different players and more. Create maps on different scales to visualize the different levels of complexity
Set yourself a limit. Maybe do a ranking that can be done depending on the persona that was put in the center. If you do it from a customer's perspective, it should be customers.
If you do it from an internal perspective, focus on different teams and you will probably realize that there is not only one ranking of stakeholders, but depending on who you talk to the ranking will be different. That in itself is a really interesting fact that you can use then. If you do that with different teams in your organization you will probably find a few where everyone says “Yes these are important” and others where it depends on the context, the department you speak to etc.
Who are we putting at the center and how complex do we want to make our maps ? Sometimes we have more than one exchange in each direction between two stakeholders. Can we model this in Smaply or is it on the roadmap?
Marc:
First the asset is on our roadmap. Currently it's not possible, you have to decide for one. But it is on our roadmap that you can add multiple ones. I would like to share a quick story. A couple of years ago I was working with a large b2b software company and it started with a senior management workshop with 20 participants. It started with how good they are, how customer-centric or user-centric they are and so on. A colleague of mine was there as well and we were asking ourselves if they were really user-centric.
Our goal was to find out how user-centered they were, because we had a very different perspective than they had from themselves.
We asked them to split the group up into three smaller groups, six people per group. We asked them to map their b2b sales process, which is a huge process for big software companies, taking like 12 to 18 months. Involving loads of different people from the client and from themselves and a few external sometimes. They started mapping and we only told them the more important a stakeholder was for this process the more it had to be put in the center and that was the only guidance we gave them. We didn't tell them who to put in the center.
Now the next thing we did was to hang those three maps next to each other on the wall and we just asked them one question: How user-centered are you?
Where do you think were the users on these maps? Well on one map, there was no user at all and on two maps, it was somewhere out there. So the nice thing is, it's a very visual representation of what you put in the center. If you claim to be user-centered, where should the user be? In the center, because you design the software around their requirements. You involve them throughout the process, you make sure that it works for them, which they clearly didn't. It's also a tool that you can use to better understand your own organization or your client’s organization.
And now, what's next?
Check out our article about the basics of stakeholder mapping, or have a look at other Ask Marc sessions about different topics of human-centric work, like multi-persona maps, creating CX insight repositories, and many more.
