This series was initiated as a place for you to learn more about service design and journey mapping software. Our co-founder Marc Stickdorn and the Smaply team share their experience on how to embed and scale service design in organizations. The sessions usually kick off with a short introduction to the focus topic to bring everybody to the same page, followed by your questions and deep discussions of best practice examples.
On this page you find the recording as well as the transcript. Additionally this session is also available as a podcast on Spotify, iTunes and Google Podcasts.
Overview
[06:05] How can I make a smooth transition and help people understand that it's worth it?
[07:35] How do you handle the constant change that is present in public services?
[12:38] What do you recommend to do at the beginning of the process of giving service design a shot?
[14:50] What's the best argument to get people to try service design out?
[22:42] What's the best way to try out service design without setting expectations too high?
Transcript
Introduction
Marc:
My first tip is: Call it what you want!
We like to call it service design. But our clients use loads of different terms, be it design thinking, experience design, service innovation, human-centered design and UX design – if you don't limit yourself to the screen. It doesn't really matter what you call it, use a phrase that works within your organization and also avoid a phrase that got burned. Design thinking is one of the classic ones. If you tell people about design thinking, they think about it like a workshop format: one hour; you put some posts on the wall and then you're creative and you have loads of ideas. We all know that doesn't work and that's really not what design is. That's also not what design thinking is, but the term just got burned because of bad work. If you want to bring human centricity to your organization, also check for existing projects where people already practice it. Probably they call it differently, but look beyond the labels, rather look at what they do and how they work. Probably you find already people who are practicing it and then you can put those projects together.
My second tip is: Don't try to do it as one big project, where you say now we gotta make our organization human-centric.
But rather start with a sequence of small projects as you first need to learn how it works. Folks are more interested in the outcome than in the approach.
We'd like to talk about low risk projects, about stealth projects. Stealth projects are projects that don’t appear on the radar of the organization. You create a safe space to try out things and see how this can work in your own organization. Before you actually talk publicly about it.
My third tip about how to get more human-centric is: Don't always think about customers, but also think about employees!
Perhaps even start with your employees. If you want to become more human-centric, you always need to look at both sides. Probably even more sides, but employees are a great starting point. If you can change some pain points your team has, they will feel the impact. You create ambassadors and also it helps you to identify who is motivated to work this way. You find your allies that you can start working with, before you start scaling it.
Now the last tip I want to give you: Try to create pull factors instead of pushing it into the organization.
Pulling service design means communicating projects that were successful, that show the ability to work in a more human-centered way, that you really think about your customers and and your employees. Talk about the outcome and not about how you did it. Once people are interested, you can tell them that not only you’re nice to your customers, but actually you also have a business impact. Either by reducing cost or increasing revenue or loyalty. People start to understand it’s not only about being nice to people, but it's actually adding business value to an organization. Suddenly you can talk very differently about this topic.
You can also check out my LinkedIn profile, where we had a discussion around this topic last week. There were loads of really insightful comments.
How can I make a smooth transition and help people understand that it's worth it?
I'm afraid that people and teams will be very hesitant as they're afraid that this approach will change everything they did so far. People don't like change.
Marc: It's totally right and it's a common thing. Basically if you think about larger organizations, there's organizational restructuring every few years. Then there's new management in there and suddenly everything needs to be different than before. Often people are sick of this, they don't want to have yet another change where everything is different but actually nothing changes, nothing improves. What you need to make sure of is to understand what the pain points are. You need to create empathy and show that you have empathy with those issues, that's why the tip is: Don't start with customer experience, start with employee experience.
Instead of creating a change project around where you push it into the organization, change the pain points of your employees so they can feel the change towards the better. Once they see it and feel the positive impact themselves, they're more open to actually talk about how it works and try it.
This is a big topic in public services, isn’t it? Every few years there are elections, there's constant change and people who work in government are also impacted by that.
Nicole, how do you handle the constant change that is present in public services?
Nicole: I've recently transitioned from doing shorter project consulting to consulting in a role where I’m actually treated like I’m an in-house employee and it's very different. I think about embedding service design, the things we talk about all the time. Things like starting with a stealth project. Well, in an innovation group in government you don't often have that luxury. There might be something big happening, perhaps from a legislative point of view and someone has gotten the buy-in to do service design around it and build a team. Now you've got to bring everyone along with you and it's very high profile and definitely comes with challenges.
What I'm learning over the last few months as I'm learning to navigate being an internal person is you need to show things quickly. In my service design career I've often had the luxury of doing extensive research and really kind of getting into spending time with my users, and sometimes we don't have the time to do that. Learn something quickly, spin up a prototype. It doesn't have to be working software or whatever, but the quicker that you can show an output, the quicker the executives are going to be okay and see that trusting this process is going to go somewhere. We are going to be able to move at a faster pace than usual. Tell the stories of the users that you're meeting, bring your ideas to life in prototypes fast. I think the other big takeaway for me has been making sure that it's about us.
Not us the design team and the business or government, let policy folks and implementation folks and all these other people know that you're in it with them and you're there to be a part of it with them, and not to take it away and do it for them. In fact you can't because you need all of their institutional knowledge in order to move your thing forward.
Marc: Nice one: designing with people and not for people.
Nicole: I think being design-led, not designer-led. And helping people understand what that means.
Marc: About what I said in the beginning: start with small projects and think about a project portfolio, think about a portfolio where you have quick wins, where you have obvious pain points to fix, obvious needs from customers and or employees that are unfulfilled. Things you can do easily. Then you can make a quadrant out of it.
On one axis you put the effort – like how much time/budget do we need to tackle this issue? On the other axis is how much impact you can have on the people. What you will find is that your project probably has a tendency to have a big impact, but you will find a big variance in the effort you need to invest.
If you see it as a portfolio make sure that you don't only take the quick wins because then people will think it's always just quick wins.
Understand it as a portfolio where you always level out a few quick wins with some long-term goals and bigger initiatives. That also shows the different priorities, different complexities and a different scope.
Nicole: I'm working on a roadmap right now and exploring certainty versus uncertainty. Sometimes it's hard for someone to say how complex something is. But we can certainly run a workshop and get a good understanding of what the questions are and how many of them are answered versus unanswered. And knowing that there's a lot of uncertainty we probably have to spend more time exploring that option strategically. It's not going to be a tactical play and it's probably going to take more time.
In my company we do not have much time for service design. What do you recommend to do at the beginning of the process?
Marc: Don't see service design as being black or white; on or off; zero or a 100 percent. It doesn't need to be a service design project or a human-centered design project, but you can use bits and pieces of this approach of working in any project. Use one tool, one method. Especially when talking about becoming more human-centric, think about which tools and which methods can bring more empathy to your project. Which can you bring closer to the people you design with? And think about qualitative research and perhaps you can also invite customers to a specific part of your project. That already helps to bring you closer to the people you're actually designing for.
Nicole: I saw a presentation the other day, beautifully done. It was about sharing some external research, but telling some really human stories before they got into any of the sort of business aspects of what they had found.
We do these non-service design presentations all the time and just slipping in a couple humanistic stories about what's happening and how you might solve that problem using that method gets people thinking about it from that way.
I work in an agency with multiple core areas – not only design thinking. What's the best argument to get them to try it out?
Marc: Design in general is a team sport and you always need loads of different backgrounds. If you work in an agency that already has different backgrounds it’s great because you can build on that. You can use it. But that is a question rather about what do you actually want to achieve with human-centric design? Where do you want to go with that? Is it about what kind of projects you do and how you can make sure that the end user becomes part of this project?
Think about approaches like co-design, inviting people and design with them instead of you designing for them. Again, don't try to convince them to do everything differently, but take a project and take bits and pieces in there and I’m sure they will see the value of it and start adopting some of those tools and methods. Once they do that then you can add more to it and at some point you can then tell them about the whole approach behind it.
If you talk to people who do service design, most of them will tell you they've done it before they knew it was called service design, before they knew it was a thing. Don't get too attached to these words, rather think about how you can infuse it in bits and pieces in your work.
Nicole: I’ve worked in agencies before we had a group of three service designers. Then we had our UX team and a visual design team, and all of the developers. We were a web design house and we all worked very separately. We were starting to talk a lot about agile but we were still working in a very waterfall way. Whereas now I work in pods where we have a service designer, a front-end designer who does all of our UX and that front-end coding, and then a couple developers. We're able to move from that sort of service design facilitated idea into something that works really quite quickly and move forward so everyone is doing service design in a way and we're all doing it together.
Marc: The question is often, are we doing it consciously or not? Sometimes it's our job to make it more conscious and make people aware of the impact of their decisions.
How would you motivate groups that are not in regular contact with people to also keep an eye on human centricity?
Like accounting or development.
Marc: It's much easier if you first focus on employee experience. If you think of an organization: we're providing services to each other all the time. All of these interactions and little services can be designed. We can always put a more human approach to it. If we talk about how to bring the end user closer to developers or accounting, often tools that act as a boundary object help. A boundary object is what we call a thing that has a meaning in different social worlds. In different organizational silos, how we like to say. A great example for that is a journey map.
Use a journey map to create empathy with your customers. Map out the customer experience and add valuable information for both accounting and developers. To make it relevant for them it needs to have relevant information. For developers it might be adding epics, user stories, depending on the zoom level you're in and show the work they are doing and what they are planning to do in context of customer experience.
Maybe with accounting it’s interesting to find out at which time they actually come into play. If they see where the processes are triggered, they know what their work is. It helps them to understand what the context is.
Suddenly also those teams like accounting and development, legal and marketing can work together using this same visual artifact.
It often has to do with how you speak about your customers. To create empathy we need qualitative research. With quantitative research it's hard to have empathy with. It's hard to have empathy when you say 73 percent of our customers do the following. But showing qualitative research data, like an interview and observation, photos or video of a situation triggers much more emotions and creates way more empathy with users.
The biggest mistake I see happening is when you try to quantify qualitative data. When you did 10 or 20 interviews and you found a pattern in it, then don’t say that you asked 20 people and 12 out of 20 said the following. People would stop listening immediately because all they hear is 12 out of 20. 20 is not a representative sample size, they’re out.
But if you show videos of these 12 people struggling with a certain pain point. Or people calling the call center asking for help and the call center agent just can't help them because the system doesn't allow it, then you start creating empathy. You actually have a way different starting point for a conversation.
Nicole: For sure. Talking about starting with employees, those frontline staff, they get the double whammy. They have the pains of doing their own job, plus they see the pain of all the customers. They can be a massive resource in helping you understand where the customer pain lies, especially if you're having a hard time getting buy-in to actually talk to customers. It can be tricky, depending on your industry. Those front-line staff, they'll tell you all the stories and you'll see all their pain and they are generally really grateful to have someone sitting with them, who seems to care about this stuff. Because they've often been struggling for a long time and they're not often invited to the table for these conversations.
What's the best way to try out service design without setting expectations too high?
I'm scared I might fail and I don't want to have to justify my approach.
It will fail the first time. Be prepared for that. First you need to learn how it works, but it's a difference if you put spotlight on a project by saying “we're trying out service design now” or if you create a safe space for a project. For example, how I started today by talking about stealth projects. That’s a great way to create a safe space for your project. Even a step before that, don't start with the service design project, but rather use single tools and methods in any project. If they fail, it was just like maybe half an hour of a project.
And if you're afraid of trying it, and you're trying it for the first time, maybe gain experience outside of your job. Think about some events like the Global Service Jam for example. Two friends, Markus and Adam started that a couple of years ago. It's a global event happening locally, where people get together to create a prototype of a service within 48 hours. That's a great safe space to try out new tools and methods, to learn yourself what works and what doesn't work.
Nicole: Marc you've also talked about taking projects that are obvious problems that need fixing, but that no one else wants to deal with. And then give it a name that makes it sound really boring and then just go do the thing. Kind of take the spotlight off.
Marc: One of those tips of creating stealth projects is actually which name you give them. Usually names like process optimization or something similar works brilliantly, because people think that's boring. It is about optimizing something. Just the name of a project can already create a safe space, as it means people are not interested and that's actually what you need in the beginning to try out new stuff.
If you look forward you need to bring other people in, you need to scale it. Think about events where you show the work you've done and that can be like an internal workshop. An internal jam is perfect for that, where you can actually show it and be open to start actually a community of practice within your own organization. You need to find your allies because you need to build an internal community. If you want to scale it at some point one tip is, once you have this first group of people, make sure that you connect this community also with the wider community. It’s out there, think about conferences, online communities, workshops, master classes.
Also hosting events yourself where you invite the community to join you. Whatever helps you to have interactions, then your internal team will grow with the trends, the new stuff that the wider community comes up with. Otherwise your internal community will at some point actually remain at one level and stop growing. Then the best people will leave after a few years because they always need new challenges and then your community will shrink and stop growing their knowledge. So make sure you connect them as early as possible.
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.
