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
- [02:46] Is employee experience a good thing to start with service design in an organization?
- [07:11] Do you rather suggest a short term research or a long term research to learn more about employee experience?
- [11:04] How can I motivate employees to participate in the employee experience and get buy in for such activities?
- [13:16] Is it better to follow several initiatives for a better employee experience, or integrate them to a single one driven by service design?
- [15:32] How do you deal with the fact that team participants are users too of a possible solution?
- [17:52] How do you build trust among stakeholders when working on a service design project focused on employee experience?
- [24:34] When should I do a journey map when the blueprint and process map?
- [28:22] What are your tips for getting started with prototyping, especially for non-digital experiences?
- [30:47] What synergies do you identify between service design and agile?
How should we start with service design in my organization? Can I start with employee experience actually or do I need to start with customer experience?
Employee experience is a really discussed, hot topic in service design and it’s a topic that is close to my heart. We know we are pushing that for quite a while, but we really need to focus much more on employee experience.
I would actually turn the question around and say: yes, if you want to start, I believe employee experience is actually a much better start than customer experience.
There’s several reasons for that. The first one is that – if you think of research and if you think of an organization who starts doing service design, who tries to do first projects and do their first experiments and learn how to use this for your organization – often you have to struggle to be able to do research with real users, real customers.
But it’s so much easier to do this with employees, because they’re just in front of your office, in front of your door. You can go out and talk to them and do interviews, you can practice different research techniques, do observations, do work-alongs, do mobile ethnography with them, collect data easily, you can do workshops with them… so it isn’t really gentle start.
And if you manage to focus on one of those topics where all your colleagues always struggled with, always had problems with, something like: How do I book a meeting room? – I never saw that working well in any organization! It’s too complex and in the end someone else is in the room because the meeting earlier took too long or whatever – but if you manage to improve this process, people will see it, realize your work and you actually have a story to tell. You build your own case around that. It can be topics like booking a room, it can be also like a process like: how do you find your travel expenses? It can be something off work, like: how is your canteen? How do you get food and drinks and coffee around your workspace?
Is there an ability to link journey maps in Smaply with each other?
It is actually possible because each journey map has a unique URL and through this URL you can link the journey maps within each other. If I explained journey maps, I always like to explain it by comparing it to maps in geography, like Google maps for example. If you think of maps in geography, they have different zoom levels. You take a look and you have a look at the world. You can zoom in maybe to Europe to Austria to Innsbruck where we are based. The more you zoom in, the more details you see, until at the city level you see street names appear.
So maps in geography is the same as maps in service design. If we talk about journey maps, you have different zoom levels. You have the whole lifecycle of a customer: you don’t see a lot of details, but you get a good overview. Then you can zoom in to certain steps and you see more details the more you zoom in. If you want to build a repository of journey maps in Smaply for example, you can use the URL and link these journey maps to each other, so by the links it can then zoom in and out. I would constantly switch between different zoom levels to on the hand hand design the details and then understand what’s the impact on the wider experience.
Do you rather suggest a short term research or a long term research to learn more about employee experience?
What I understand the short term research could be a day or a one week project to dig in and understand something. A long term reset for me would be to spend months on that. To start with, I would definitely go for the short term. You first need to get an overview. So think rather in terms of multiple, shorter term research projects. Maybe then you can also think about something as a diary study where folks can add more data over a longer period of time. But design research in itself is iterative, which means you start with a a wide question in the beginning, like: how do our employees actually experience their work life here?
You start very broad and first get an overview of that. And once you’ve got an overview, you will realize there are certain topics, certain problems they have, pain points they have, or stuff they like, and maybe also certain problems in infrastructure. A client of ours had the problem – and they realize that through the research – that new employees doing the onboarding got the equipment way too late. So they just had to order at a different moment in time, they needed to set a different trigger point. And all this stuff you learn very easily through short term research. Then you need further research on to dig deeper into specific aspects.
How do you suggest to present the journeys developed in Smaply in an innovative way?
There’s a few news around that. One thing is we are working already on different visualizations, so different export options for your journey maps. This is still in prototyping – if you’re interested in seeing that, please just send us an email so we’re happy to set up a prototype session with you and get your feedback on that.
One way will be to visualize it with like a large emotional journey so a much more visual appealing way to do it. Currently I would recommend to use hide and show function of the lanes and – depending on the audience of your journey map – only show the data that is relevant to them. So one trick to make journey maps stick in your organization is – particularly if you think of using journey maps as a boundary object connecting the different departments of an organization – to include relevant information for each of these different departments.
Again you can compare the journey map to a map in geography. If you look at a map for a farmer, it includes very different information than a journey map for a mining company. You need different information to do both. So to have a relevant journey map, you need to include relevant information for them. I would suggest to add much information to it, everything that you can find that might be relevant, but then only show and export and show those departments what is relevant to them. By that you probably have a higher chance that it actually sticks with them and they see a value in it.
How can I motivate employees to participate in the employee experience and get buy-in for such activities?
I think it all depends on if you can show that you can provide value to them: what’s in it for me? And that goes way beyond employee experience in general. How can you motivate a certain department to participate in your project? How can you motivate someone to participate in it? Think about what’s in for them and take on that as a service design project itself. So why should they participate? Can you help them to maybe reach a certain milestone? Reach better KPIs or whatever they measure? And maybe by turning that around and saying: that’s in for you, I can help you to achieve something that you need to achieve anyway, you get them motivated.
For employees, to take part in research, it is important that they understand that you do that to improve their experience, and that actually something comes out of the project. So often we have surveys where you never hear back again from what happened. You never see something implemented.
Folks are sick of participating in something, if nothing comes out of it.
So you need to gain trust, you need to show that you actually mean to change something. It’s great because you can include them in the process. You can co-create a great solution with them. If you think about research, also think about a mix of methods. Use maybe something like observations or interviews, but also use something like mobile ethnography, where they can document stuff on the go without being observed or without an interviewer present. Also, use something like co-creative workshops to create a journey map together and share the different stories, share the different experiences.
Considering servitude and perspective, in the organization I worked at we are executing several initiatives for providing a better employee experience and also for driving digital transformation, internally at first be digital. Currently they are different initiatives. Do you think it would be a better approach to integrate them in a single initiative driven by service design?
Yes, absolutely! And actually digital transformation is a great gateway to bring service design into an organization. I often like to quote Thorsten Dirks, the former CEO of Telefonica in Germany, who once said: “When you digitize a shitty process, you have a shitty digital process”. That’s the whole idea about digital transformation. You don’t want to just digitize the paper form that you used to use into a digital format, but still use the same form in the end, still force people to fill in the same stuff, again and again.
Whereas technology gives you way more different options. Service design is great to understand what’s possible with technology, but then also to combine it with user needs: What do people actually like and how can we use this technology to enhance or improve a certain experience? So yes, maybe as a starting point: use any kind of project in digital transformation that is running. Don’t call it service design, but just use a few tools and methods. That might help you, and it might help the project to progress in an easier way.
And maybe by that, by showing results, you can then show afterwards how you did it.
Instead of pushing service design, let the results of service design talk for themselves.
And then, once people got interested in how you actually did it because the new process is so much easier, you can show them: that’s what we did! We actually talked with you, tested the prototype with users and that’s the result of it.
How do you deal with the fact that team participants are also users of a possible solution? (conflict of interest, …)
That’s true, it is a conflict of interest. On the other hand it also has an advantage that you are also users of that: It’s much easier to do research because you are involved in that. An example for that was maybe a company I was working with in public transport. All the employees were using public transport on a daily basis. Yes, of course you would like to improve it in a way that is suitable for you. And maybe by that, one of the dangers is to neglect other use cases, or that you push for solutions that are more usable for yourself.
And I think that’s a very common topic in service design. We often have a conflict of interest between different stakeholders, between different departments, like: which KPI shall we focus on? What should we measure here? What is how do we actually measure the success of a certain project? One way to tackle that is by using personas and following the guideline: design for the average, test with extremes.
So make this bias very clear. Create a persona for yourself and your own use case to make this conflict of interest very visible.
What we mean with ‘design for the average, test with extremes’ is: if you think of one target group, you have a certain core persona for the target group, but then also you have loads of other use cases around. You can also represent this with edge case personas or extreme personas.
If you develop a concept, you might have a tendency to in the beginning – your own bias, to push it in a certain direction. But if you test it against all the other edge cases, you might be able to create something that is a fit for all the different aspects within this group.
How do you build trust among stakeholders when working on a service design project focused on employee experience?
It’s difficult because ‘stakeholders’ is such a wide term. I’d say you refer to internal stakeholders: stakeholders within your organization, different departments, management and how do you actually create trust among them so they work with you, they join you. Trust is something which is hard to talk people into it. Actions speak louder than words. You need to show it, and what I always recommend is to start small, start with small cases.
Maybe in the beginning don’t call it a service design case, because very often just the word ‘design’ is suspicious for people outside of the design discipline. Just call it improvement, or the process, or whatever. Give it a very boring name and then use service design, or parts of it. Build your own case and measure that impact! So whatever you want to impact, measure before and measure it afterwards. This way you can build your own use case that you can then communicate to actually show what are you doing.
What doesn’t work in my experience is showing use cases from other companies. If you show the great cases of all the big companies out there practicing service design, folks always say: yeah, that works with them – but we’re different, this doesn’t work with us. And they’re right. Every organization is different. Because it works somewhere doesn't mean it works for you. Why should they trust you? Start building your own use cases by not talking about service design, but practicing service design. Once you have a few smaller cases – if you start with it in the beginning a few of these cases will fail, just be aware of that – you need some time to learn how to adapt design to your own organization. How to change the language. How to tweak the tools and methods to make it work for the specific team and organization.
Once you manage that and you’re able to maybe even solve some of the tiny things I was talking about earlier, then people will start trusting you because they see the impact of that. People don’t trust a journey map that you show them, but they will trust once they actually feel that you had an impact and that is what you should be working for. So: work towards outcome, don’t work towards an output. If you’d just talk about: we made this nice journey map, people won’t trust you. Don’t think about one project, the big project in the beginning, rather think about a sequence of projects. Start small, but then scale it up.
What are ways to flag key moments on journey maps?
I think that this refers again to Smaply, our journey mapping software. There are different ways to do that. On the one hand, you can do this visually by using different colors. For example, flag key moments. You can use a color code for that, like: red for really critical things, yellow for things on the roadmap thatyou might get into at some point. That’s a very simple way to do that.
A more sophisticated one is to add another lane, a text lane, underneath. There you can actually describe what’s happening. You can also add some numbers to it. Maybe you have already a number code for that, like 1 to 10 or something like that to show the importance. You can also use a visual way to that.
Often the dramatic arc – which normally is used to visualize the change of engagement over time – can be also used to visualize the importance of something. So tweak the tool, however it is useful for you!
If you have, for example, a graph underneath with a few peaks in it and the graph visualizes the importance. Right below or on top you have a graph visualizing the emotional journey, where it shows if an experience is positive or negative, you can put them together. You’ll see that you might have a few negative issues but only one of them is also an important moment. That’s the moment where you need to start. So use that as a second dimension for it.
So, three ways. The first one, color coding, very simple. The second one, use a graph like a dramatic arc, just call it differently, maybe importance or key moments. And the third one is visualize it through a text lane where you can actually describe why this is important and add more details to it or.
Referring to Smaply, there is no option right now to lift and shift sections so you need to delete or redo if a stage has to move. We are aware of that and we're going to work on that in the future. However it also can be changed depending on how you structure your journey maps.
So think about – instead of having that one long journey map – building a hierarchy of journey maps, where you link these journey maps on different levels into each other. And by that you drill down into a more detailed map so it’s like a pyramid where you can drill down into the details.
When should I do a journey map, and when the blueprint and process map?
Oh yeah, that’s good! So let’s start with the process map. The key feature of a process map is that you have different branches in it either, or you have a decision tree. So you can use a process map to visualize all the possible paths a customer has through your experience. What is really hard with a process map, however, is to have empathy – because you can’t add visuals to it. Our life as a human being, by definition is linear.
As soon as they have branches in it, you can’t really empathize with one of them, or with all of them. And that is the key feature of a journey map. A journey map has one linear story, of one person at a time. You might add more personas to a journey map and compare different journeys in one map, but it’s always one linear story of one person. That is actually a key feature of a journey map, because that allows you to add more data to it, more details to it. You can add visuals to it, drafts, text lanes, any kind of data which helps you to empathize.
If journey maps are on the one hand and process maps on the other hand, a service blueprint is right in the middle. A service blueprint connects a linear journey map where you have one story of a user describing one experience, but then additionally the backstage actions. What are the internal processes that you as an organization need to do to actually be able to create this certain experience?
There are different ways to visualize a service blueprint. If you go back to the very original ones from Lynn Shostack (G. Lynn Shostack (1984): Designing Services That Deliver) that beginning of the 90s, 80s or the paper by Ostrome in the 90s (Bitner, M. J., Ostrom, A. L., & Morgan, F. N. (2008). Service blueprinting: a practical technique for service innovation. California management review, 50(3), 66-94), it actually has a very rigid structure. However, how it is often used now, is more combination of a journey map with a flowchart, where it shows the actual experience of one person, but then drills down into all the internal processes in more detail.
Although that is corporate, or company internal perspective. When you do that, always consider one thing: the more you focus on the internal processes, the more you will also forget what is actually the customer experience. One aspect, one moment that’s very often missing in the customer experience, is waiting time. Very often, if you focus on the internal processes, you simply forget that people have to wait while you’re doing something. Once you went through that, think about how long do these processes internal processes take? And then think about what is a user actually doing in that time?
A second thing to think of is: when do these processes take place? In a flowchart, there is often no dimension of time, like: when do we send out a message to our customer? This results sometimes in the problem that companies send out text messages to their customers at 3 o’clock in the morning, because they just planned it with a flowchart and not thought about the experience.
Once I have done a journey map and we have some ideas for things we want to change, what are your top tips for getting started with prototyping, especially for non-digital experiences?
When you do a research-based journey map and you understand: what are the issues you have? And based on that you come up with ideas, or while you are doing the research you were already collecting ideas, then I recommend to use a very simple tool called an idea portfolio.
If you go to the website of our book thisisservicedesigndoing.com, you click on ‘methods’ you’ll find more than 53 method descriptions on how to do it step by step, and you will find the idea portfolio among them.
The idea portfolio is very simple. Based on all the ideas that you have, you map them on the one dimension: how big is the impact on customer experience? At the beginning that is really a gut feeling, but then the other dimension is: how feasible is it? How long does it take to develop this? How much do you need to invest? How much money does it cost? How much time? How many people are needed?
If you map those dimensions against each other you will see that a few of your ideas are quick wins: they are easy to do, but actually have a big impact. A few of them are long term goals, they are hard to achieve, but they have a big impact. A few of them are hard or easy, but those don’t have that much impact. Don’t neglect them, but rather look for infrastructure projects in there, or dependencies between the different ideas. Sometimes, if you tackle one of those ideas, it shifts many other ideas on the feasibility scale! I recommend to use an idea portfolio and then pick a few of the ideas – not just one, but a few – and move them to prototyping.
I’m originally a computer science guy. Recently I wrote a design directory program. What synergies do you identify between service design and agile?
That’s a good question! It actually has a philosophic component in there. My colleague Adam Lawrence likes to refer to two different kinds of people: there are lumpers and there are splitters. Lumpers are folks who look for similarities within different concepts, and splitters look for differences. Very often when I hear about service design and agile, people only talk about the differences, but for me they really fit perfectly together.
If you look at the similarities, service design is a great gateway into agile, because one problem about agile is the role of the product owner. Somehow the product owner magically knows everything the customers want – and that just does not happen like that. On the other hand service design is great to find out what people want through research, prototyping, co-creation. For me that is how service design and agile can fit together: we can practice service design in a similar time frame as you do in agile sprints. While you are developing the next feature, the next part of a feature, and you run simultaneous service design sprints with research to define requirements for the next sprints, you’re constantly feeding the backlog and make sure they have enough to develop.
Can a number of journey maps automatically be merged into a holistic master journey?
Not yet. However this is on our roadmap. This is something we’ll start working on this year. It won’t be launched this year, but we actually want to create something. I talked about that in an earlier interview – that you can visually just like you scroll throuh Google Maps, that you should be able to visually scroll through the different hierarchy levels of journey maps. We still don’t know how, and that is rather our task right now.
If you’re interested in the topic, send us an email, we’re happy to include you to our prototyping sessions and get your feedback on that.
Big view question: talk about the public sector applications of service design, specifically in the public sector focusing on complex issues facing governments and society
I think there are much better people to talk about that. I’ve been working with governments and public services, but if we look at what, for example, gov.uk did in the last years – they are way ahead! I would suggest to google for talks by gov.uk, the former leader Lou Downe did some really good talks at conferences. Some of them are online and I recommend to watch these. It's absolutely fantastic work these colleagues are doing there.
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.
