Service Design

So, I'd like to introduce you to the next mapping tool here. It's the *ecosystem mapping*. It's a template that you can use. It's also a group activity. To start with, let's look at this quote here from the newly appointed CEO of Nokia in 2011. And he said this: What he pointed to there is this problem

that every business faces when they're delivering a service, which is the relationship and dependencies of the entire ecosystem. Now, at this stage, Microsoft acquired Nokia, and so they inherited this particular problem. But I think it illustrates the point that we're looking for here – which is:

What's going on in your *entire* ecosystem? And how are you going to deal with that in terms of creating a service that really resonates with customers? So, I like to define the ecosystem as those who are *bringing* the experience to the customer. Some people define ecosystem with "the customers" or "the users" and I don't think that's helpful; so,

I would like to define ecosystem as *those who are manufacturing the experience*. So, think of it as the employers, employees, supply chain, suppliers, contractors – everyone that goes into making that, building *that stage* – you know – making that thing perform. It's the *things they're doing* and the *value they're bringing*. It's the *information* that they need or

use or require or share; the *people* or systems that *they* interact with, the *services* that are available to them, the *devices* that they might use and the channels they might communicate with. So, in Amazon's case, they have their own delivery kind of ecosystem. That's my truck.

The Amazon ecosystem delivery is actually UPS and FedEx as well as USPS, the US postal service. But they've also added *private drivers*. So, they have private drivers It looks like somebody's dad, somebody's father driving the truck. So, you have *that* going on. And then you have the *kiosk* that takes / that inputs the packages. Behind there, there's the *database*. So, there's a system there.

From that database, there's an email notification. The email notification goes up, pings the customer and sends that email to the customer. The customer gets it on their device and so forth. We also have the infrastructure over here, so the drivers got their own special Amazon app. There's some kind of logistics happening here behind the scenes. So, you get the general idea. It's mapping everything that's happening in the ecosystem:

all the actors all the roles, all the stuff that's going on and looking for where the dependencies are and where the breakpoints are that occur within that ecosystem – very very important. And if you *don't* do ecosystem mapping, then it's my belief that you're not really leveraging the whole set of tools that service design affords. Ecosystem mapping is as *important as personas*. With the ecosystem map, you want to start with your *current state*.

It's not a map of the future, desired state. It's where you're at *now*. It's about understanding all the connections that occur in all those dependencies. It's about understanding how stakeholders, databases, devices, products, services – how everything kind of maps together and how that information flows and the exchange of value that occurs between – you know – all these different actors that are going on here

and – yeah – it's a *group activity*; just like a lot of service design things, you're showing here with your team. Now, here's an example from the Fiat Group in Italy – the Fiat Design Group – and they mapped out the future of transportation. So, they actually looked at the future side of things. And you can do that, but first do the *current* picture view.

It's important to – you know – *don't dream out what could be*; *understand what you have to deal with*. Now, Fiat's group actually added the what, why, how, who, when and where of the situation and then looked at the ecosystem across these different lenses that you can see here in this example. The activity here is to take your group and start *drawing* this out.

Each person will draw their *own* version of this. So, if you have a big white board – if you have a big one of these – you'll put them all together. Then each person presents to the group because you're going to see similarities and differences – and you can note those, write those down. Post those to a wall and draw the connections between all the individual maps, so you have so many different ones. And then use this alongside your journey maps and use it to guide your service blueprint. The ecosystem map is you building up to your service blueprint.

And instead of jumping into the surface blueprint, this is about doing your due diligence to *dig deeper* and find out what exactly is happening in that vital ecosystem.

(Jonas Piet:) One of the pieces of work we're working on is called Kudoz. It's a learning platform for people with developmental disabilities. And basically what we do is we link people in a community with an interest to people with a developmental disability with a similar interest. And then we have an Airbnb-type of platform with all those learning experiences, where – "Kudoer" we call it –

a person with a developmental disability books a learning experience from a volunteer host. And then, like with Airbnb, those experiences take place in the community. Obviously, a really big part is that platform. And we've got a mobile app as well. And our UX designers will work on those products. But then some of the things that I as a service designer work on

are starting way before people even enter the platform. It's "How do they know – how do they find out about this platform?"; "How do they know about Kudoz?". The first interaction wouldn't be that they sign up online. But the first interaction would probably be that they come across us at an event – a community event. And then, you know, maybe they get a flyer or another piece of information, or maybe they see a video, or maybe they see one of our team members explaining it – what Kudoz is and why it might be interesting for them.

Or maybe they're part of one of the community experiences that we do to get people interested to become a volunteer host on the platform. There are many interactions that aren't happening on the platform but that are a really important part of the flow through the service. And, as a service designer, I have to keep an eye on all these different interactions and all the different user groups. Whereas the UX designers, they mainly work with the people going on experiences and the volunteers who offer experiences.

So, only two of the user groups – not so much the staff. And they focus on the digital platform. So, as an example, if someone signs up on the platform to host an experience, then fairly quickly they meet up with one of what we call "Experience Curators". So, they meet that person. So, the role that that person has is designed by the service designer – what they do and what they don't do;

how they introduce Kudoz – the script, that's designed by the service designer. Some of the pieces of paper and the worksheets that they have with them and the storybooks to tell a compelling story about Kudoz, those are in this case designed by service designers. They will then have to do at some point a criminal records check. There is going to be some sort of a safety check. People have to brainstorm together to come up with a great idea for their learning experience.

And, yes, that goes back into the digital platform. But a lot of the interactions are actually not on the platform. They happen in real life. And, yeah, the service designer is really making sure that all these different interactions line up and that it's hopefully a seamless experience – but at least a positive experience that, yeah, gets people closer to the outcomes that we're after.

Let's take a look at service design from a wide overview perspective. In the beginning of the process, you've got user research happening. And that's ethnography – right, to be clear: user research meaning "field studies" – ethnographic field studies. It's where personas come out of and journey maps come out of. And the reason you're doing that is you need to do that deep listening: What are the pain points? If the service design project is internally focused,

then that means service design interviews with stakeholders as well as subject-matter experts. You're going to also then have that *workshop* – that *stakeholder engagement piece* that we talked about. And so that stuff is happening up-front. From there, you're going to have the use of the template business model canvas, the value proposition canvas – those two canvases. And, to me, bringing the realistic inputs to those canvases, you can do it in a couple of hours: one hour, two hours even. If you have the right people in the room, you could even sit down.

You can do it across the whole process, too, by the way. You don't have to just do – the business model canvas is done up-front, yeah, in that first bit. But you can go back and do it again with another stakeholder. Like, for example, I've had so many projects where we're all the way to the testing phase and they bring in a new product manager or a new person to manage the whole – a program manager. And it's like those people *don't know*. So, going back and doing the business model canvas with them could be a good idea. From there, then you move into prototyping.

Now, when you do agile service design, you might do some quick prototyping up-front, – right off of those journey maps, right off of the user research. Traditionally, what you do is you take that journey map, though, and you move into the blueprint stage. So, you've got your business model, value proposition defined. Now, map it out in the service blueprint. That's where co-creation comes in – so, with stakeholders again. All the stakeholders are working on that blueprint together.

And you might also *map the ecosystem*. So, what's happening in the ecosystem that everyone needs to be aware of? And it's at that stage then you kick up into *service prototyping*. So, then you'll start building these actual prototypes. They might include UX design of apps or websites. That's fine. They might include physical, tangible theatrical acted-out, hands-on "fun stuff" – you know. And that's where we have the testing – think of it as user testing: *service user testing*.

And then, finally, once you've done that refinement, you're going to roll it out, roll out the service. And, of course, you're going to measure the service. You're going to do that initially with like a survey or you're going to use other tools from UX design or depending on what's appropriate. So, there may be web analytics, there may be exit surveys or you might do a *diary study*, which is a technique for user research you can use to assess the service. So, whatever the technique that's appropriate based on what you're building

– again, you know, depending on what you're building will determine the technique. But you want to get that feedback immediately, to find out. It may just be going into the environment and doing a service safari on your own service. So, that's an overview of the whole process, and key points there: user research up-front; stakeholder engagement throughout as well as some early iterations or loops of that if you're in an agile service design environment,

as well as remember the measurement.

We'll get into defining Service Design and seeing where it's being applied. So, what is service design? And, probably more importantly, what *isn't* service design? So, service design is about designing an experience from a service orientation. So, it's like user experience design

– where you're designing for the UX usually of a digital product – but in this case the service may touch many, many other places – you know, "omni-channel" as it's called: different channels. So, the user might start out on the web and they might go to the phone and they might go to the store or they might go to a location or to a form. They might pick up a brochure; back onto their mobile phone. And however that whole service is being delivered – you know – sometimes you *have to* go to a different channel

in order to continue with the journey. And so, that's what service design is. It's a *wider kind of view* – stepping *back* from UX. I like to think of it from a *systems thinking perspective*. And by 'systems thinking', I'm talking about the engineering discipline, not systems as in database systems. Though systems are actually really important in service designs

because – you know – you have computer systems, database systems, you've got business processes and logic. So, service designs think about *everything* – not just what's happening on the screen. And they think about what the smoothest ways are to deliver that – but not just from the consumer's perspective; they think about *how* to deliver the service experience

in a way that's *appropriate* for the *user* and for the *business* and for the *systems* that are going to support that – the processes and all the back-end stuff. They're about being *exact* about that because – you know – it's *very* very apparent when there's a service experience failure. So, service design has to be *feasible*. It means it has to work again from a business perspective. And it has to be *scalable*

so that you can't just come up with a great idea but then it doesn't work for rolling it out to 10 million people. The other thing is *financial viability* is really important. And I think that's part of scale. So, there's engineering scale. But there's also "Is this going to work?" – you know. If it's a free service, for example, is freemium – that model – going to work? Or are you going to have to change the model and therefore maybe jeopardize your users?