Marc Stickdorn – Service Design: Creating Delightful Cross-Channel Experiences
Podcast: Play in new window | Download (Duration: 25:38 — 13.9MB)
Subscribe: iTunes | Android | RSS
Service design seems to go by an increasing array of names: Customer Experience, Cross-Channel UX, or even just “design thinking.” In most cases, these terms describe a holistic approach to your users’ and customers’ needs, no matter where or when they’re interacting with your product or service. In traditionally siloed organizations, it can be no small task to ensure that you are providing the best possible service.
Communication is at the heart of service design and Marc Stickdorn knows the core of it is getting everyone on the same page. He says that the importance of this lies in the fact that customer experiences sometimes aren’t tangible—a user or customer could be experiencing an internal event. It’s important to understand how different customers come in contact with the design.
One way of determining that is with a customer journey map. Being able to visualize the path a customer takes while interacting with your product is a powerful thing. It allows you to see the moments where they are engaged or perhaps need your service, but it also allows you to have a conversation about what happens between those moments. Being able to design for the exact moment your customer needs the design to function in a specific way creates a very delightful experience.
Marc will be presenting one of 8 daylong workshops at the UI20 conference, November 2–4, in Boston. For more information, visit uiconf.com.
Recorded: July, 2015
[ Subscribe to our podcast via 
←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Full Transcript.
Jared Spool: Hello there, everyone. Welcome to yet another episode of the SpoolCast. I am Jared Spool, I am the person who guides you through these lovely discussions.
Today, this lovely discussion is going to be with Marc Stickdorn, who presented at last year’s UI19 conference. He did such an amazing job that we’ve invited him back to present on service design at this year’s UI20 conference, which is going to be November 2-4 in Boston, Massachusetts.
Marc is really the person who, for me, made service design be more than just a buzzword. He really understands what it is that we’re trying to do and how, as people who are in the user experience business, we can use what we already know and also learn the new tricks that the service world has. His sessions are always fascinating and I thought we’d have a chance to talk with him today.
Hopefully, he’s here. Marc, are you there?
Marc Stickdorn: I’m here. Hi, Jared.
Jared: Hi. I love it when the technology works.
One of the things that has become a theme as I was putting together the UI20 conference. It’s funny, because the way I put together these conferences is basically I pick the sessions I want to hear most about and then I invite people. Then people like you are silly enough to say yes and then the conference comes together.
When I first saw you in Brazil a couple of years ago, what you were saying about service design and how you were teaching it then was really a jump ahead of everything I’d heard in the past, which is just the same old rhetoric about, make sure you take care of your customers.
You were actually talking about how this happens and the tools that we could use for it. That’s intrigued me to a great extent.
But this year, as I was putting the conference together, I realized that all the sessions…it came out when we were writing up the initial marketing pieces. Every session had a sentence in it that said something like, get your people on the same page. It’s like, every session is about getting people on the same page.
In service design, getting people on the same page is the big deal. That’s really my understanding, is, as I’ve heard you’ve talk about it, that’s at the heart of what good service design is, is getting the entire team, all the people who have any influence on what the customer or the employee experiences, onto the same page about what a great experience is and how to go about fixing it.
Did I get that right or am I making stuff up?
Marc: No, absolutely. That’s absolutely right.
There’s always a bit confusion about what the heck is service design. For me, it’s not so much about the name. There are many names about the same stuff. It depends on the country you’re in, on the company you’re working with. They might call it, some just call it design thinking. Some call it multi-channel UX design or customer experience, whatever.
I don’t care that much about the label we give it. I rather care about how we do it. The core part of it is, exactly as I say, it is getting people on the same page.
Which means, of course, it includes a process, some tools and methods, but the core of the work what we do is actually facilitation. That means we facilitate a group of people, mostly from very diverse backgrounds, from different departments, different companies. But also, customers through a process using specific methods and tools to talk about the same thing.
The problem we have, when we talk about services, is that services, customer experiences, are not tangible. They’re sometimes just conversations between people, and sometimes it’s really simply something happening in the head of the customer. It’s really hard to get all the people on the same page.
Academically speaking, what we need to create to achieve a consensus between everybody is to create a so-called “Boundary object.” Some kind of object which clearly phrases what we’re talking about and what we’re not talking about. Most of the methods we use in service design is actually to get those people on the same page, using different boundary objects.
Jared: Give me an example of a boundary object.
Marc: Probably the most quoted one would be a customer journey map. What is a customer journey map? Everybody uses them and I really like your talk when you go in stage and say, “Well, I have to put in customer journey maps because then I get more money paid.” That is something we see quite often.
But what is a customer journey map? It’s simply visualization of customer experiences. It’s a visualization of data and it really depends on the quality of the data if the journey maps are really useful and make sense or not. But they can make sense when you work with a group of people to visualize the experience you’re talking about, so that at least between the group of people, you’re talking about the very same thing.
Jared: The journey maps that I’ve seen, basically talk to the experience of a customer or a group of customers. When you’re using them, they’re across, basically, for lack of a better word, all those touchpoints that a customer has, all those moments of interface that the customer has between the interactions.
But one of the things that I’ve always loved about journey maps is that they allow us the opportunity to talk about what happens between those moments of interface.
Marc: That’s why I’ve really struggled with the word “Touchpoint.” I think everybody struggles with that. Because, if you take a look at where touchpoint comes from, it comes from marketing, from branding. Typically, what is a touchpoint was like the billboard at a highway or something, “Oh, it was a touchpoint.”
I often like to leave that word out now when I talk about journey maps, because it confuses people. If we just say a journey map is a sequence of steps, and the step could be an interface. A step could be conversation between people. A step in a journey map could be just somebody thinking about something.
You can compare journey map to a movie. A movie is a sequence of scenes telling this story of a main actor. A journey map is a sequence of steps telling the story of the main actor of a service, which could be, for example, a customer.
Jared: But that space between…first, why is it that the touchpoints bother you?
Marc: The first thing is the name. A touchpoint, I think we talked about that last year already. A touchpoint is sometimes nothing you can touch, because it might be conversation between people. It’s not a point, because it’s often, or it should always involve a specific time. Touchpoint, the word itself, is quite misleading in terms of a journey map. That’s why I prefer steps.
But then, also, it depends on what kind of journey map you’re talking about, because there are many different journey maps. The first thing is, “Well, what is the scope of the journey map? What is the timeframe? Are we talking about an experience, like a high level perspective of, let’s say, a mobile phone contract where the overall high level journey might be like three years, including the time we search for a new phone, when you look for a new contract?”
When you do it, then you have a contract for 24 months. Then maybe you quit or you renew. That’s a pretty long journey. But you could also zoom into specific steps, like the moment when you choose your phone in the shop, and have a journey map with a scope of, let’s say, an hour, the time you spent in the shop.
Or, you could even zoom into more and have a more detailed journey on one very specific aspect within that one. It really depends on which level you want to work on what makes sense. At the services end, we often switch between these levels. We always consider the context of the overall journey.
But then when we zoom in and we try to improve the experience at a very specific moment within the journey, then we are down to the details. Then we need to look up again, take a look at the overall experience, and how does this fit into that?
Jared: As we’re looking at that experience, part of the goal here is to get people who are working on this, all the stakeholders, all the different people who can influence these activities, to actually have a shared understanding of what those experiences are. Often times, this comes as a real surprise to those people, right? They don’t realize how hard we’ve made it.
Marc: Yeah, absolutely. That brings me back to what I said in the beginning. The journey map is as good as the data is we use to create this journey map. If you think now of, let’s say, a classic example of a middle or upper management workshop, maybe in the marketing department, and they’re sitting a bunch of people around saying, “Let’s trade their journey map and see how their experience is.”
They do a so-called assumption based journey maps. They make the steps of how they think their experience is. They don’t use real data, research based data, but they make it. How useful is such a journey map? But, yes, they are on the same page. They might talk about the same thing, but they’re all talking about the own assumptions and not on the real customer user experience.
When we talk about journey mapping and getting everybody on the same page, we also need to make sure that the customer has a word in there. That means that we either have data about the customer, solid data, not so much talking about content of data, but rather qualitative research methods, ethnographic research, to really understand, “What is their experience?” from a customer perspective, step-by-step throughout the whole journey. Then based on these data, we can start to redesign or improve it.
Jared: It seems to me that this is an extension of what a lot of people are already doing when they are thinking about how the website should work, or how an app should work. We’re now pushing into all the places that are outside that app.
Now, we have to involve all these different people, and they come at the problem from very different perspectives. Once we have the journey map, is that just the magic formula? Is that the magic touchstone as it were, or is there more work that has to happen to get everybody on the same page.
Marc: No, not at all. In fact, in many services and projects I do, we actually don’t do a journey map. A good friend of mine, Adam Lawrence from WorkPlayExperience, he always says, “If you do services, and if you do, only two things in service design. You should do research, and prototyping.” Sometimes, you don’t need a journey map for that.
When you do research, you see very obvious things where you state like, “How can that be?” Then you prototype a solution. You test it in reality, and you change it. If you do only one thing in service design, I would really say you should do research. That is the most important thing. To get a good understanding of the customer experience.
A journey map is useful as a boundary object. It’s useful to get a team talk about the same thing, to visualize that, and then to be able to redesign that to work with that. It’s far from the silver bullet, and you do just a journey map, and then you’re done. It’s just a tool.
Jared: The prototyping aspect of it, when we were at the workshop, you were building, in some cases, full scale experience elements. Like what it would be like to create a ticket station for a bus system.
That helps you physically go through the motions of understanding, “If I have suitcases, and shopping bags, and how easy is it to get the card out of the wallet, and then put my credit card in?” and all that stuff.
That, in itself, is a type of research. Just getting everyone to see that this system can be incredibly complex. So many times in the real world. I was just in Paris, and the Metro ticketing stations, if you are not a French speaking person are actually a bit challenging.
Marc: [laughs] I can imagine, yeah.
Jared: The screens are actually pretty good on the main display, but it tells you to insert your credit card. The messaging on the credit card unit which, I assume, is a third party unit, those are all in French.
Sometimes, you put your card in, and you remove it immediately. Sometimes you put it in, and then you take it out, and then the transaction happens. Sometimes, you keep the card in for the entire transaction. If you don’t read French, you don’t know which one of these that is.
Marc: Even if you speak French, these machines are just horrible. Even if you speak the language. Sometimes you don’t know that there are all these slots for cards. There’s another slot for the ticket. Sometimes, they look exactly the same. You’d try to enter your credit card in the slot where the ticket comes out, because you don’t know which one is the right one.
These prototypes really help us to explore different solutions. More so, it’s about simplification. How can we make it more visual, more simple, and help customers throughout this process, and actually get rid of unnecessary steps within the customer journey map?
What is a prototype? Basically, it’s the same as we use in the UX from your buyer framing, but it depends on the channel we’re on, what kind of prototype we’re doing. If we are, for example, talking about the channel of telephone, say a call center, it doesn’t help us a lot if we build a prototype with card board.
Then we rather use theatrical methods like improv theater, raw playing to prototype these situations. When we talk about physical objects like ticket machines, like the check and desk at a hotel and swan, we can really simply build it with card board.
When we go up there on a larger scale, and you think about, for example, a hotel layout, or a tourism destination, then we can use desktop walkthroughs. Where we build a simplified version of a building, of a city, of a destination on the table, and visualize processes, prototype processes with Lego figures, or papered card board.
Really simple methods, but it depends on the channel, and the cross channeling experience which method makes sense in which situation.
Jared: You mentioned that prototyping, and research are the two pieces of this. The research part of this, in its simplest form, it’s just observation, but the way you do the observation, particularly since many of these parts of the service experience happen away from the touch points as it were. They’re out of sight of the organization. Collecting that data can be tricky, right?
Marc: Absolutely. We use different methods to collect data. Of course, we use plastic methods like Big Data, Google analytics, and also quantitative analytics like surveys, questionnaires, desk research.
We try, always, to use recent…what’s already out there, and not reinvent the wheel. Then the most valuable methods for us in service design are qualitative research methods. Ethnography like different kind of observations. Observation, there’s a whole bunch of different techniques behind that.
We use interviews. Mostly contextual interviews, so we do interviews in the context of a situation. If we’re going back to the ticket machine, we could do an in depth interview retrospectively. Which means we invite a customer, and then talk about the ticket machine, and the experience with their last experience of buying a ticket.
It makes much sense to do an interview in the very situation when they are operating the machines. That means we need to go out in the field, and talk to the people in these situations. We also use stuff like diary studies, cultural [inaudible 17:25] , or we ask people to document their own experiences.
Actually, what I will be talking about at UI 20 will be the result of my PhD, and my latest startup, which is ExperienceFellow. Where we developed a new way to do research where we include real customers as active researchers in our projects.
It’s called “Mobile ethnography,” where you can set up a project. You can invite your customers. They have a simple app on their smartphone, like a little diary, and they can document, step by step, all their experiences. We see the data coming in real time, visualized as journey maps with different options then to analyze that.
The interesting part about this research approach that many companies think, “Well, it’s just qualitative research. Its’ not solid data,” but that’s not true. If you just follow a few rules of thumb, and you use not one method, but, at least, three.
You triangulate your results, you use different sources of data, you work with different researches, you get very solid data with limited bloodshed. It’s just a question of how do you do that? That will be one of the things I’ll be talking about at your conference.
Jared: Being able to do this with a limited budget, that’s absolutely how this has to work, because nobody has an infinite budget to pull this stuff off.
Marc: No, and that’s always the biggest restriction. That’s why in any project people are hesitant to use qualitative research methods, because they think, “Well, we only have a limited budget, so we could talk or get feedback from 1,000 customers if we do it quantitatively. But if it’s really about going out and talking to the people, observing them, including them as research in our projects, we can only get…I don’t know, 20 or 30, maybe 50 people with the same budget.”
But then, if you ask yourself, “What kind of data actually makes sense?” If you compare, let’s say, a questionnaire or stuff like Net Promoter Score, where you get data. Like, let’s say, 80.7 percent of our customers are satisfied. 20 percent are not happy with our service on this channel. That that is kind of the level of detail you get from that. That doesn’t really help us to innovate.
What helps us to innovate is to observe them and to see patterns in their behavior. It goes back to usability testing more in UX. I mean, if we go back to literature, the early work from Nielsen, what he said, how many people you should ask to find the main bucks, that’s basically what we’re doing, just on different channels.
We’re not interested in finding out if 80.7 percent or 80.5 percent are not happy with that. We try to find out what are the main bucks in our customer experience across all our channels. Then we should take the top three bucks, so the most urgent problems in our customer experience, we should prototype that, fix it, and then start all over again.
It’s the same thing as Agile development or Lean startup or Lean UX. But across channels, it’s the same process. That’s basically what design is. That is an iterative design process.
Jared: Of course, all that iteration just builds up the accumulated knowledge of what customers are doing and what they’re trying to do.
It seems to me that we still have some opportunities to do better at this in a lot of organizations. What would you say are sort of the big places that you think people should be focusing on to sort of expand their thinking into the service domain?
Marc: It’s really to understand how important customer experience is. To get that idea, how important customer experience is across the whole organization.
There was research from Gartner, Gartner Research, who said that — I hope I get the numbers right — that customer experience will become the new beta field. That 89 percent of companies think that they compete on customer experience in the future, where only four years ago, there were only 34 percent of companies who said that customer experience is important.
We’re on that page now, that they understand how important that is. But we don’t have the processes within the organizations yet to constantly observe and understand customer experience, because that doesn’t work only with quantitative statistics. That’s only for monitoring. What we need is qualitative research methods who get the same status as quantitative research methods in organizations. I think that will be the next step.
Jared: The quantitative stuff, though, that’s tricky, right? A lot of organizations start their quantitative stuff by just diving into these massive piles of data and asking, what patterns can we see here and then trying to put inferences behind those patterns and then make all sorts of decisions on that.
Lately, I’ve been seeing organizations that have been going the other way around. They start with the qualitative, they go out and they watch a bunch of people, see some patterns in what they’re watching and then ask the question, “How often does this occur in the real world? Can we figure that out?” That tends to produce, really, sort of more actionable results that have fascinating outcomes.
Marc: I absolutely agree. Often we just need to know which question should we ask. If we don’t know that, we will drown in data when we try to find patterns and for sure, we will find patterns. Some of that is a starting point, but often that’s just leading to not so important or very subjective analysis.
Even though we’re talking about quantitative data, because we try to interpret something into these numbers which we didn’t really observe in reality. That’s why I think we need both. It’s not an either/or, it’s not that I’m saying we only need qualitative, we need both.
Jared: Marc, thank you so much for taking the time to talk to us today about service design and prototyping and research. It’s really fascinating stuff.
I’m really excited about your workshop that’s coming up at the UI 20 conference. It’ll be November 2-4. The day long workshop that you’ll be doing on service design was a lot of fun last year. Everybody spent most of the time doing research and building stuff, it was really a very interactive session. It was so much fun, we learned so much. I’m looking forward to that this year.
Those of you who are interested in the workshop, you can get more information about it at uiconf.com, that’s U-I-C-O-N-F dot com. Marc, thank you so much, this has been great.
Marc: Thank you. I’m excited already to come back to Boston. It was a great experience last year, and a great bunch of people. I’m really looking forward to it.
Jared: I want to thank our audience for listening. You guys are awesome. You can learn more about the conference, uiconf.com. If you’re listening to these podcasts, if you like them, please go leave us a review on iTunes, that helps us quite a bit.
Thank you again for spending the time with us, and of course, thank you for encouraging our behavior. We’ll talk to you soon.