Ask Marc – about journey map operations

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

• [03:00] Workshop maps, project maps and management maps
• [07:00] How to get started with journey map operations
• [08:10] What’s the operations part about?
• [12:17] How to structure journey maps from macro to micro levels in Smaply?
• [14:30] Can you connect all the different journeys?
• [15:00 and 17:40] Is there an example for maps in a map?
• [15:40] How much time does it take to set up an initial journey map?
• [19:30] Who should update journey maps and how frequently?
• [23:05] Should everyone contribute or is it better to limit it to a few people?
• [24:00] How would you support teams as an external?
• [27:30] In your own journey map ops, what details are you focusing on?
• [31:00] Who is usually in charge of the management of the journey maps?

‍

‍Workshop maps, project maps and management maps

You can use journey maps in different ways. A lot of miscommunications in organizations actually stem from the fact that someone might think of a journey map as a workshop map, while someone else thinks of it as a management map.

The first category are workshop maps: these are maps you have to work on with pen and paper in a workshop setting, either as a research tool or as an alignment tool for the team to get on the same page and to learn from that.

But very often these maps are not used outside of the workshop. You often take a photo and only a few key insights out of the workshop.

The second kind of maps are maps you use within a project. These are proper boundary objects that are used to communicate between different teams that progress over time. You often start with the assumption-based maps and move towards research-based maps. You often start with current state maps to identify  problems and then develop them over time into future state maps – mapping out how the future could look like. Then maybe you even move into prototyping and test your ideas.

Today, we’re going to talk about the third kind of maps: management maps.

Management maps are maps that you use not for one project only, but to connect many different projects. You can use strategic management to manage the customer experience of your organization. When we talk about journey map ops we actually like to call it a customer-centric management tool for agile organizations.

The core problem is large organizations struggle with the problem that they run a lot of different projects that focus on customer experience, but also loads of other projects. The focus on something completely different may be a legal topic, a new IT system, a change of standard operating procedures, or rather focusing on internal processes. But all of them in the end impact customer experience.

Loads of these projects are now managed in an agile way, which means you don’t know in which direction the different projects actually develop. It’s really hard to manage that, hence the problem organizations have is that projects overlap. Different departments do similar projects and they are not aware of that until it’s very late: maybe they are ready to launch when they realize “Oh shoot there was someone else working on that as well!”. But they have a different opinion on that, maybe even a different solution.

It’s a waste of time and money!

You might also have contradicting projects: there’s maybe two connected steps in the journey, one project focusing on that one project on that and there different direction that’s why they’re contradicting

Focusing on management maps helps to understand how different projects impact customer experience – and these are not only projects of customer experience, design, innovation but all the projects in your organization.

I always like to compare journey maps with maps in geography where you have different zoom levels.

How to get started with journey map operations?

You might start with a high level map – the highest level you can have, kind of a customer lifecycle. Then you can zoom into any step, create a dedicated journey map there with a different time frame – it might be just a few hours. Then you can zoom into details again and do micro journeys or further level it down into more detail. The difference here is always the time frame. The more you zoom in, the more details you see, but the less time you actually cover in it.

It’s the same as with maps in geography: when you zoom in you see more details but you see less of the scope.

If you map out all the customer experience and organizations offers, you will end up with loads and loads of different maps. I don’t recommend to start with that – rather start with a few dedicated ones. Map out the highest level and then at least one level below. Start with for example where you have pain points or where you currently focus different projects on.

What is the operations part about?

We really want to put the customer at the center, and management tools should help us with that.

That means you need a different role in the organization: the journey map coordinator.

These folks hold a council. Depending on the organization, they might hold it every week, every month, every quarter. Depending on how quick you move within your organization. They are responsible for different parts of the journey. If we think of the highest-level journey, the person responsible for that should also be the person in the organization who’s in charge of customer experience.

When you zoom in, you probably have different teams responsible for different parts, or even different departments responsible for different parts of the journey. For the more detailed journeys, also assigned journey map coordinators so there’s one coordinator responsible for one journey. You can go down to very specific details of your experience, and have a specific team responsible for that.

These coordinators get in touch with the different departments to find out what kind of projects are going on and where those impact customer experience at a particular part of the journey.

On your journey maps, as an additional lane type you add Projects. There you write down all the projects that are currently going on, or that are planned. Because you feed up the information from the very detailed journey, to the mid-level, to the highest level – on the highest level you aggregate loads and loads of projects. As soon as you aggregate these projects, you’ll find overlaps or contradictions between the projects from different departments.

It is absolutely essential that the coordinators get in touch with other departments, start building relationships across the silos of your organization and collect information.

It works brilliantly if you add other lane types as well, like user pain points, team pain points, KPIs. Suddenly a journey map becomes a dashboard of your organization, focusing on the customer experience. You see all the projects, all the KPIs, all the pain points from your team and your users, organized by the experience.

When you meet regularly in this council, you bring all the information together and there’s a governing structure behind that: in the meeting you check how you are performing, how the various KPIs are developing. Don’t just focus on one KPI, but on a whole set of KPIs.

If you move further down into details, you don't only see quantitative, but also qualitative data. You’re going to see projects and you check for contradictions and overlaps. You decide which projects should move on or who should you bring in touch with each other. You also realize that there are pain points where there are currently no projects active focusing to solve them. You can agree on starting research projects for that or, if you already identified the pain points backed up with research, you can set up prototyping projects and in the end also development projects, implementation projects.

It’s a whole governing system for an organization around customer experience. Using a journey map as a as a visual management tool only works if you use a digital solution for journey mapping – by the way, that’s how our customers use Smaply as a governing system.

What is the best way to structure journey mapping from macro to micro levels in Smaply and where is the best place to start?

Actually I covered a lot of that already. I recommend to start with where you are. So if you already have a map on a specific project – that is your starting point. The next thing you should do is take a look at the next higher level. Where is this experience actually embedded in? I think I said it in our first Q&A session. There is a saying in design: “When you want to design a table, you need to understand the room in which this table is placed. If you want to design a room, you need to understand the house. Otherwise you end up with two bathrooms but no kitchen.”

You always need to understand the next higher entity. For journey maps that means, start with where you are. Understand the bigger picture if you start with a blank canvas. If you don’t have anything, start from the top. Start mapping out the high level experience, that is often very straight-forward. And then identify – where do we have the biggest friction? Either from a user perspective – pain points – or from internal perspective where they say “This is where we lose our conversion”. Focus on that one. In Smaply it’s very simple. Each map has a unique URL that you can simply copy. You create a text lane. You can call it detailed journey maps and either copy paste in the link, or you actually write detailed journey map here. Then you click on the little link button and you can add it as a link. By that you can actually build the whole hierarchy of maps.

Can you connect all the different journeys?

You cannot only connect just one map into each other, you can add multiple. Think about different use cases, different target groups, different personas involved.

So you might have that one big high level map, but then you can actually focus on one aspect and show different use cases there. The more you get into details, the more useful it is to detail it out for different user segments, for different contacts, for different channels and so on.

Is there an example for maps in a map?

When you look at it, it’s still just one single map. You can click on that link and then open up the next layer down map, or multiple maps as you choose.

How much time does it take to set up an initial journey map?

Well, that depends on the quality. I mean, you get what you pay for. So, depends of course on how much data you already have. If you have all the data, then it’s fairly straightforward. Just put your data into a map, cluster your data. The most time consuming is actually the data collection because a journey map is just as good as the data is.

There are two different kinds of journey maps. There are research-based journey maps and there are assumption-based journey maps. Assumption-based journey map means you just – maybe alone or in a small team – put up a journey map and say: “We think, this is what the customer experience is”. They look great and they might be a useful start, but they are only a start. Because then you need to challenge your own assumptions. They are biased by your own personality, by your behavior, by the knowledge you have. You need to challenge that and back it up with research, so over time you move from assumption-based maps into research-based maps.

If you create a research based map, use various methods of qualitative research: use interviews observations, maybe auto-ethnography – just become a customer yourself, maybe use mobile ethnography… That is probably what takes most time. But most time it can be anything from a few hours to a few days.

Actually creating the map itself is not the big deal, once you have the data. It can take anything from like five minutes to a few hours.

This is a high-level journey map, an example journey map. It’s a travel journey of our customer Anna doing air travel. It’s a very high-level map, you’ve got the pre-boarding experience, the flight experience and so on. What we did here – just to show how this looks like – is, that we added one lane type. It links to detailed journey maps. That is a very simple text lane. At every step you can add text. And as an example we put in two different maps here, so this is just text. If I mark it and click on the link button you see that this is the text we saw “detailed journey map” and then there’s the URL of the map. So what happens now is I can actually click on this map and open it. I just open it now in the different tabs so I can move between them. What you see here is another journey map. By that you can actually build a whole hierarchy of maps and as I said, you can actually have multiple ones here. You can have different ones, like only Anna’s experience, or Anna’s and Tom’s experience. By that you actually build up a hierarchy of maps. Here again, you can add the same lane type and go more into detail. Also, this is how you build it in Smaply.

Who should update journey maps? Should everyone contribute, or is it better to limit it to a few people? How frequently should you update them?

This depends on what kind of map you are at. Remembering the slide I showed you; there are workshop maps, project maps, management maps. Workshop maps you typically do not update. You create them to collect information, probably in a co-creative setting where you invite your customers and learn from them. You might digitize them, it might be a starting point for a project map but you typically don’t update workshop maps. Project maps you update throughout a project. That depends on the kind of projects you have. What is the velocity of your project? If you have a fast-paced project where you have regular changes, where you do research, there you might add research data every day to the map. Where you do prototyping, you might add prototypes to it. Or your hypothesis and the results of that. You could also upload reports or videos of the prototypes to it.

In a project it really depends on the velocity of it: the faster the project goes, the more you update it. I have been in projects that went on for years and every few weeks people were working on it. Of course you don’t update it on a daily basis, but ongoing. Like every few weeks. The last type,  the management maps rather depend on the speed of your organization. We work with startups who try to be as much on the pulse of customers as possible. They update their management maps on a weekly basis. They do it by having a dedicated team for that, so they have set up small journey map ops team. It’s a handful of people – five six people – who constantly update. Although there might not be major changes every week.

It’s more like, they add a user pain point, they discovered from the support work. There might be another team pain point they discovered by talking to their colleagues. It might be a new project they add to it. There are only tiny changes every week. But the nice thing is they meet each week, they take a look at the map. If there are any changes that folks put up there, they will highlight them. Immediately you see all the changes in the map. What was added to it? That also helps to speed up meetings because horrible meetings are when everyone talks about exactly the same thing every week.

One rule I would always put out there is: only talk about updates, about new things, what changed and not just the same every week again and again.

Most of our clients do it on a monthly basis. There are few companies –rather in the production and the manufacturing area – where they have lots of products. They were much smaller, much slower going. They produce cars for example, or b2b manufacturer. They do it on a quarterly basis.

Should everyone contribute or is it better to limit it to a few people?

I don’t think it makes sense if everyone contributes to it, because that will be a mess. That’s why having a governing structure where you have a clear responsibility. Who is in charge for which part of the experience? And that means if there’s a person in charge, they get all the information from their own circle. Whoever they build into this circle. Then others can tell them “Hey we have a change here”, “Hey that’s a new paint point” and “Hey there’s a project”. Still, not everyone needs to be in the system to update the journey map themselves.

Many contributors, limited owners.

If you work project based with various companies, you might not have an employee in each organization to lead the journey process. How would you support teams as an external?

So, you are an agency and you have multiple clients and multiple projects? The thing is, they are often not connected obviously. They are clients in different industries with different products. The system I just showed you is an in-house system. If you, as an organization run journey map operations internally for your own products, for your own customers as an agency it’s hard to connect all these different ones into one map. That probably doesn’t work because there are different markets and so on.

I would then actually suggest in Smaply you can have different projects, different folders. You can actually run the different projects in each folder. What might be helpful is to duplicate existing projects of one client, when they work in a similar market. Then you wouldn’t need to start from scratch. This obviously always depends on the NDAs, whether you are allowed to do so. If you are allowed to do it, you can copy it and and focus on changes. So did it change over time? Did the market change? Do they focus on different customers? ..and so on.

If you as an agency try to support a company in setting that up, I recommend to work with them on a rather coaching basis. That means, don’t set it up for them, but set it up with them. Or, even better, help them to set it up themselves. That often is much more successful than if you work on the old agency model where you do something and then present it. They need to have ownership. The whole journey map of system only works if you have an organization own it themselves and run it themselves.

The topic journey map operations is rather new to many, but for a lot of companies even the idea of doing journey maps is quite new. They’re not even at that point. They may have wrapped their head around the fact that it’s valuable to have some journey mapping done and they’d like to see that. So now it’s that sort of coaching and educating that there’s a way that they can start moving towards managing their business if they can set up a couple people to own some journeys, and be in charge of those. I’ve been using my time with my clients to just start introducing the topic and get them to start getting the wheels going, so they can start thinking about it.

In your own journey map ops, what details are you focusing on?

In our company we obviously have a high-level journey map where we focus on the customer lifecycle. So anything from identifying a need, how they become aware of that there is something like a journey map software, trying it out, then we actually split our journey map at some point into on the one hand our subscription customers – some folks who sign up themselves on the website, who use our software independently – and then enterprise users. These accounts are often connected to some training. From there it goes to how do we onboard hundred new users in the company and so on, all the way through to off-boarding.

I recommend never to end with off boarding but end with re-engagement or similar. “How do people come back?” On this high-level map we actually then structured it in different sub-levels. These sub-levels are in the beginning the same, but then they split up into different sub levels. The enterprise and the subscription one. For each level we focus on a different set of PIs and KPIs. First you can actually measure something for every step, also in the detailed journey map but not everything you measure is a KPI. Each journey map should have a set of KPIs, something around three. Never just one, never ten, but something like two, three, maximum four.

Focusing on one KPI only might lead to a trap: you try to change the KPI but actually not change what you measure with the KPI behind it. Beside the KPIs we obviously have a lane for projects as I just explained. Then we have a lane for team pain points and a lane for user pain points. We on purpose split it up. Sometimes we do projects which solely focus internally but then, they obviously solve a pain point that the employees have.

This then helps to free them, up to have more time to actually focus on customer experience.

It’s important to have both perspectives – customer and employee or team pain points. We then try to connect all the projects with pain points and all the pain points with projects. Sometimes you identify that there are pain points but there’s no project tackling it. And obviously that is stuff that goes into our backlog. This is what we need to fix in the future.

In the more detailed maps we also have a lane that is underlined with research data. That can come from support, from usability testing, from research we run do, workshops we run and so on. And then we actually meet once per month and and go through that.

Who is usually in charge of the management of the journey maps?

This is difficult to answer in general. That topic is based on the different departments in different organizations. So it can be part of design, it can be part of innovation, in some organizations it’s even part of the C-level where you have a CXO. I would look out for the person in the organization who’s the highest in the hierarchy and actually focusing on customer experience. That might be in innovation, might be in design, but that might also be in marketing. It might also be in any other department, when you look in a role, I think everyone can learn it.

There is not only one single person responsible for them, that is really important. That’s why we like to call it the council. Because it should always be a group of people taking a look at that, a group of people taking decisions. There should be someone high ranking in the organization, because they have an impact. You can also influence other departments. But then you should build accounts that consist of different people with different roles. And that might be UX lead, that might be a PO, there might even be a project manager. This obviously depends on the project manager’s rights. I would not limit it, I would not exclude anyone by definition.

It’s the same as when you’re struggling to build service design capabilities in an organization. You need to look for the people with the interest and the heart and the  desire to really grab onto the work. I think that’s a good way to figure out where you’re starting. Who can own?

‍

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 or another Ask Marc session journey map repositories – here you go!