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, the session is available on Spotify, iTunes and Google Podcasts.
Overview
- [05:30] Introduction
- [14:20] How can you establish links and enable traceability between customer and operations / organization metrics using repositories?
- [18:10] What is a good way to connect all the different journeys within one company?
- [20:00] How could journey map repositories work for journey maps that cover journeys across all kinds of different government agencies that work independently?
- [21:45] How do you operationalize this if you are for example a bank?
- [27:20] What are the biggest barriers for implementing such a method in large organizations and how do I overcome these barriers?
- [31:00] How can you realign journey mapping activities between departments?
- [34:25] How do you cope with data security when linking real-time data that we talked about to a repository like this?
- [37:10] What is a boundary object?
- [38:00] Is a repository of templates and taxonomy that can standardize journey mapping a good place to start?
- [39:00] Which government did a journey map from life events that you spoke about earlier? Is it possible to share that information?
Introduction
I always like to compare a journey map to a map in geography. If you think about Google Maps, there you can zoom in and out, you can take a look at the whole world, or a continent like Europe. You don’t see a lot of details, but you get a good overview. You can zoom into a country, zoom into a city – the more you zoom in, the more details you see.
There are three different cases of journey maps. Starting with the first from the left-hand side, the workshop maps. These are maps we often co-create together with customers, with users, with frontline staff, with stakeholders, managers, whatever. And even a co-creative setting can be done online – probably you use some kind of whiteboarding software. Or you do it face to face with a journey map on the wall, with post-its. These maps are often not made to survive. We do this to learn, to get some research data, but often the conversations people are having in front of the tool are more important than the tool itself. Often, we just document it with a photo or screenshot. We typically don’t come back to them. We just keep it but what lives on are some pieces of data, some insights we got out of that. But they remain as a researcher prototyping tool.
The second part is different. These are the project maps. Project maps serve as a boundary object. You often start assumption based and current stage. You can use it to actually fill it up with your data, you enrich it through the research you’re doing into research based maps. And you then define certain areas of interest or pain points, opportunities. Out of that you spin different future state journey maps. All of these means the maps survived during a project. That might be several days, weeks, months.
In big occasions and large projects maybe even several years. But often they end up in a drawer after the project and you often don’t use them again. Even worse, if you think of a large organization maybe multinational with loads of different teams doing service design, they often work with different agencies as well, so you might have some of these maps in PDF, some of them in Excel, PowerPoint, Smaply or whatever tool you use. It’s really hard to find old project maps if you don’t by chance know someone from this project and work on top of that. It’s hard to find them again, that’s actually one of the key ideas behind the repository. That you build a repository, so you’re able to find these again.
The third kind of map, the management maps. That’s actually what the repository is made out of, so you use these maps to connect existing maps. These management maps survive over many projects, they actually connect many projects. To the hierarchy – the basis of a repository. A very simple example of an airline. The high-level experience might be someone traveling. Everything from a travel need, to booking, preparing, going to the airport, flying, arriving and so on. The customer lifecycle if you like to say so. And every step you can zoom in, just like in geography.
This is a continent view, we zoom into the country view, if we zoom into the airport we have a different timeline. We’re not looking at several weeks, we’re looking at maybe four hours. Within that we can then do that for every step. And we can zoom in even further, so if we’re at the airport we look at the boarding experience. That itself could be a journey map. Maybe time duration would be like 20 minutes or so. You can build that up all the way to micro journeys, microinteractions. Now these different levels are really important. When you build a repository, it’s important to think about that. Create kind of a consistency in these levels. These levels of details just like maps also have different zoom levels and they’re kind of standardized. That’s why they work seamlessly and integrate seamlessly into each other. A tip when you build your repository: be clear about how you name these different levels. Maybe time duration is a good indicator for what kind of level you’re looking at.
Now we’re switching to Smaply to show you what a repository can look like.
It is the same example of a travel journey and I just zoom out once and show you how it looks in the project base. I always recommend if you structure it: have one folder for your management maps, the ones you regularly update. They used to link each other in. And then you see other folders for your different projects that you can then also link into these. Within the folder you have the high level map and different sub-journeys.
In this simple example we just have two levels, a high level and a sub level. The high level is the level we just looked at. Everything from need to travel to at the airport, the flight and so on. In our example we just linked a few sub journeys in here. I’m going to show you how it looks like if I zoom into the airport experience now. It’s similar to what we saw on the slides. We see a separate journey now which has a different duration. Now it’s the airport journey. Like that you can really link them into each other.
Later on we are going to come back because we have some questions on that. You can link it to live data to KPIs. You can connect the KPIs also to the different levels of the journeys. You can have KPIs for micro interactions but also for the big ones and that’s really nice if you see an issue, for example here: let’s say on the check-ins. You can actually go to the sub journey and have a closer look there. Look at these KPIs maybe, it shows you already, indicates towards a direction where you should look at. You can also link all the different projects you’ve done. The problem I started with you can actually find the old projects and so on. The last thing I want to show you is that this also is really nice as a dashboard for management. You can also create an HTML version of your map. Obviously if you have a shared version of your map it should also link them to the shared version so you have the link journey map lane. If you click on that another website opens again. This is the shared version of the map. Due to this also management or external people can access it, because you don’t need to be a Smaply user for that.
We see traceability across domains as the biggest challenge when mapping and measuring. For example, an insurance business discovers a pain point in waiting time after filing a claim, but the metric is internal processing time measured using a BPM software, not a journey map. There are many less obvious examples. How to establish such links and enable traceability between customer and operations / organization metrics using repositories?
It shows one of the biggest issues corporates often have which is – how do we connect the outside perspective with the inside perspective? We measure the duration of a process like we see here. But actually the pain point that results out of that is the customer focus, and how can we connect that? And that was a reason why I showed you that you can also add live data to a journey map. I recommend that if you build a repository of your maps, that you define a standard set of lanes that you put in there. One lane could be for projects, another lane could be for linked sub journeys or alternative journeys, alternative cases and one lane could be for customer pain points and one could be for employee pain points. And that is really important to connect those two. To have both separated but to have both there. If you see in a step that there is an employee pain point, there is an issue in support. Customers complained that resolving that ticket just takes way too long. You see an employee pain point with a connection to accounting.
I just made this up but it’s a real issue because they don’t prioritize what we see. You see an immediate connection there, where you can drill deeper and ask whether these are actually connected.
To solve the customer pain point we might actually need to solve an employee pain point. The same thing you can do for the KPIs, you can define per journey different KPIs I recommend not to do too many but I also recommend to do more than one. NPS per journey is nice, but that should be just one. Have two or three or four KPIs per journey, and maybe, if you drill deeper per step so you could then have a KPI for the internal duration but also KPIs for what are the three most reported pain points in this area.
The nice thing is if you have these maps up to date you can actually connect them also to your CRM software, to your support software. If your support team is good at tagging tickets you might have an up-to-date view of what are the current issues on that day and you can even connect that to certain steps in your journey.
How do you find the best high level journey? He works within a railway company and they have lots of different journeys from their customers from buying ticket, subscriptions, physically going places, for a b2b deal from mobility for corporates, disrupted journeys for example the station. The main question here is what is a good way to connect them all?
Partly, but one thing I didn’t show is that you sometimes have two distinct audiences or distant products, like at the railway. I think there is a huge difference in selling b2c or b2b, it might be a completely different experience, completely different journeys. In that case I would suggest to have b2c and b2b as two distinct high-level journeys where you then can drill deeper into each specific one. It actually splits the funnel. A journey map is by definition linear because our experience is linear. But that somehow also means that you define a sequence, where in reality the sequence might be different, might be another way. As long as you’re fine with that, as long as you’re aware of that, that’s totally fine. The question is, what you need to map. I don’t recommend to map everything just because you can, but focus on the areas where it makes sense to map, where you have pain points and over time your repository will grow. That’s my answer.
I work for a government agency and how could journey map repositories work for journey maps that cover journeys across all kinds of different government agencies that work independently?
At some point it gets tricky, the bigger the organization is the more fragmented your services are, the more complex it is. What one government did was they defined the lifetime journey. You start your journey with being born, to going to school, making the driving license… Whatever the big events are. That is actually a nice way to also structure the different service offerings that you have from a customer perspective so you can then build sub journeys for the different areas. Try to link it in at some point, it will not be perfect and at some point it doesn’t work anymore.
Once I was working with a fast-moving consumer good company they have thousands of different products with different journeys. How do you combine all of that, there is not the one journey to rule them all. It doesn’t work, but in a specific area it works quite well.
This all sounds fun and games on paper but then again so does communism and we know how that could work out in practice, so how do you operationalize this if you are for example a bank?
It actually works quite fine. I haven’t done it with a bank to be open. We started with that like three or four years ago and besides the repository there’s a whole governance approach around that, which I call journey map ops, but that will be a different session. I’m not going into details there now.
But the repository is the basis for this, maybe what comes close to banks are insurances we’ve done it there and actually we are working with one bank now who’s starting to include that.
How you kick this off depends highly on where you are right now. Some of our clients have been using Smaply for years. They have hundreds or thousands of journey maps in the software so they have a huge mess there. At some point they say we actually are aware of this huge mess, how do we get structure into this? And that is a completely different starting point compared to someone to who this is new. Who wants to start with this, who has a handful of maps that they’ve done in workshops or projects but actually wants to start with a blank canvas.
So two completely different starting points and obviously it’s not like a wire. There’s a lot in between. I’m just going to mention or explain it roughly for those big cases. Let’s start with a blank canvas thing.
If it’s new to you, I recommend to start with a high level map. Do you find a high level map? Also that takes often a few iterations to really define it, if you have different customer segments that you might want to map. Once you have that, look for pain points so maybe connect it with your support or at least invite them to look where you got loads of tickets, look where you got complaints in social media, try to get as much data together as you can and define which part of this high-level journey you have the most problems with. And that is probably the first sub journey you should map to dig deeper into these problems and understand them. Blank canvas: start high-level, define your problem, create sub journeys.
Different starting point: you have loads of journeys, you have a mess. Look at what you have. Create an inventory of your maps, try to use the three different use cases that are outlined in the beginning to understand what kinds of maps you have. In another Ask Marc session I also went through the six aspects to evaluate journey maps. Maybe loads of your maps are assumption based, leave them out, you really don’t need them in your inventory.
Focus on the ones that are valuable. That you can base decisions on, that are actually based on research.
For your inventory it makes sense to distinguish between assumption based and research based, between high level maps and detailed level maps.
What kind of map is it? Is it a customer journey, is it a user journey, is it an employee journey? Go through the six aspects and out of these try to identify the maps which are probably up to date. Maybe done in the last one or two years, and which are focusing on your target group, for example on customers and they also should be current state. Then you can look at how many maps of this big mess are left.
Out of these ones then try to find a structure in them. Try to understand which level they are, are they already connected? Can you connect them maybe?
It really helps out to do like a little card sorting exercise there, where you put them on a table or maybe currently you do it on any whiteboarding software. Just put it up there and try to put them into relation with each other.
If you then find that maybe you can connect four or five journeys through one higher-level map, that is probably your starting point then. And then you rather go upstream and really start to connect them. You’re going to have some blank spots and that’s fine, but once you have your inventory and your repository, then you can start adding live data connected to pain points to it.
What are the biggest barriers for implementing such a method in large organizations and how do I overcome these barriers, for example to get employees to continuously update these maps in a regular fashion?
It depends on where you are. If you already have a team who’s working with journey maps, probably at some point they are intrinsically motivated to clean up the mess because it will help a lot in their work. The big advantage is, you can build on top of existing work. That really helps you. If you don’t have a team yet. Well, it’s a classic problem.
Budget is how organizations express their love for something. If there’s no budget for something there’s no love for it. In this context budget is mainly time.
Time of employees to actually do it. I can guarantee you that it will fail if you put this on top of the daily workload of employees. Then it will be a burden and they will hate it. It will not work. What some of our clients did is they defined a new role we call the journey map coordinator. And the coordinator is responsible for one particular journey, and only this one journey. You have these coordinators all the way through the repository on different hierarchy levels, often the highest-ranking person in your organization responsible for customer experience is also the person for the high level journey map. One of our clients even have a CXO and that person obviously is responsible for the high level journey, because that’s where all the data feeds in.
But it always goes all the way down to very specialized teams like the online check-in process with a mobile-phone. There might be a small team responsible for that and they need to pick one who’s responsible for updating the journey map. They need budget for that. Budget means time. They need to have time to do this. Workload to really do this continuously with updating is something between one and three days per month. With updating this structure I mean checking in on projects that are going on in your organization. You won’t have big changes there every month.
If you then use all the governance around it, like journey map ops, it helps you to identify overlaps between projects, contradictions between projects. Most projects that impact customer experience do not come from design or innovation, they come from anywhere in the organization. If you have someone responsible for this part of a journey it is suddenly possible to find projects that impact it even if they come from legal thinking about impact of GDPR, IT or any other change of standard operating procedures. Workload to update that with the KPIs, pain points and projects is something between one and three days per month. This is kind of the budget, time budget you need to calculate in. And you need to have it. Otherwise there’s no love for it and it will not work.
In today’s situation most companies have hundreds of journeys because every department has its own journey. How do you usually realign such journey mapping activities?
It’s a political thing and I’m very honest, it doesn’t flow like a breeze. There are some battles to fight. In a classic organization you have one particular journey and that exists in different silos.
Marketing has the same journey, sales has the same journey, design has the same journey – they all have different data to it because they need different data to make it relevant to them.
And it’s really hard to define ownership of this journey. The problem is always the same – it has to do with the language. As soon as you call it ownership of a journey, management of a journey… I’m not a fan of the phrase journey map manager because it’s hard to manage it. That’s why we call it coordinator. The term is less invasive, the journey map coordinator is the one who helps others to coordinate. The feeling for teams is: “Oh, they’re taking workload off from me”. That is what you need to achieve. If you are able to achieve that, suddenly marketing, sales, design, what-have-you might be more open to collaborate. It only works if you guarantee them that there is information in the journey that it is useful for them. Very often teams say “That’s a nice journey, but it’s not relevant to us.”.
What they actually mean is that the journey map doesn’t include relevant information to them.
You need to add this information to the journey and suddenly this journey becomes a boundary object translating between marketing, sales and design. If you have these coordinators, at some point you’re going to see a switch. In the beginning people feel like that something is being taken away from them, that they lose power. It might also be additional workload for them because they need to feed information to these coordinators.
At some point you’re going to feel a switch where the coordinators suddenly are seen as a hub in the organization, where people actively reach out to them and say “Hey, we’re starting a new project. I know you’re coordinating this area, did we have any projects? Is there anything else going on in this area?” It helps them then to not start from scratch, but to build on top of existing knowledge. That’s really useful. So yes, even if they are some battles to fight, it’s the matter of how you name it, how you approach it and at some point you’re really going to see that the role changes and is regarded very positively.
How do you cope with data security when linking real-time data that we talked about to a repository like this? Did you ever experience any issues with this?
That obviously depends on how your organization is structured. If you have a fragmented structure, if for example your organization consists out of different sub organizations. That is always when you enter legal issues. Then the lawyers come in and it takes time. It is possible but again, it’s more politics, it’s more complex. It’s much easier to set it up within your own organization. If you add for example research data and you might have consent by the research participants only to use it within a specific timeframe or context or whatever, and you need to be aware of that.
In general I think of data as a pyramid. On top you have the key insights, like a summary of your research, then you have your visualization.
That could be like your project maps, journey maps, personas, system maps and so on. And underneath you have a whole bunch of raw data, and the legal question defines how much can you actually include in such a repository. In Smaply it’s quite simple: all the different projects have different user rights, so only a person who is allowed to see it can see it. Others can only see the name of the sub-journey, but not see what is within it or see the name of the project, but not see what is within the project. And that’s one way how to handle that. But you can then obviously state who is in charge of that. And they can reach out and maybe you can then agree on a per project basis to access this kind of information. The more complex an organization is, the more difficult the legal side is.
On the linking of live data: it depends if it’s your internal data. That’s quite easy and straightforward to link and as soon as you link external data obviously at some point you hit legal boundaries.
What is a boundary object?
A boundary object is an object that translates between different disciplines If someone from marketing takes a look at the journey map, someone from sales, someone from legal, they all take a look at this same object, and they understand what they’re talking about. Legal can add information to it that then marketing, sales, design and IT also understand. It is kind of a translating object.
A boundary object brings people on the same page, even though they have different backgrounds.
Is a repository of templates and taxonomy that can standardize journey mapping a good place to start?
That’s the main reason why companies use Smaply. If I look at our client base, the majority are large organizations using Smaply to standardize how they do journey mapping across their organizational silos. With the idea to standardize it and then actually use a repository to link them into each other.
We also have templates. If you’re interested in journey map ops we also offer coaching there, and give you the idea for how you can set up a taxonomy, and a standard layout of your maps and so on.
Which government did a journey map from life events that you spoke about earlier? Is it possible to share that information?
Yes and no. I recommend to look at a previous presentation from the services design network conference from the government of Dubai. They have a ministry called the ministry of happiness. It’s a little bit lost in translation but it’s actually a ministry part of the prime minister’s office that is doing service design work. They for example defined such lifetime events and they also use cross silo KPIs for four different ministries and departments to bridge the silos. They did a brilliant talk at one of the service design conferences on that and they also published a bit on the blog. That’s the one we can disclose. But actually inspired by that I know of at least three different governments who initiated that, and we’re working with a few, at least with two of them but since they’re clients I can’t talk about them.
And now, what's next?
Check out the other Ask Marc sessions about different topics of human-centric work, like multi-persona maps, creating CX insight repositories, and many more.
Or if you'd like to get more specific information on the what and why of a journey map repository – here you go!
