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.

This course, Design for a Better World, is based on this book, *Design for a Better World*. The book and the course present a unique view of the problems that we have today, a view that focuses primarily upon human behavior and the history of human behavior and the history of how we came to the philosophy that's called *modernity* – we emphasize that, where all the new, bright technology was wonderful, changing the world for the better

and everybody wanted exciting new things. It was the age of consumerism. It was the age of commodities. It was the age of large companies building across the world. Well, that has led to many advances in our lives, absolutely, but it has also  led to many inequities and the destruction of the ecosystem, destruction of the environment. So, what can we do about it?

In this book, I don't give approaches to every problem; I don't give solutions to all the problems I talk about the ones that are *uniquely fundamental for designers* because at the heart of these problems is human behavior, and design is uniquely  qualified to approach these issues because design is the interface – the interface between  technology and human behavior.

Let's take a brief look at where service design came from. I think it's important to understand a little bit about its origins and so you can wrap your arms around – you know – what it is as a skill that you can build out and develop on your own. This quick definition here from Louise Downe, who's the head of design for the UK Government Cabinet Office and Digital Services.

And she reinforced here that it's – you're basically figuring out what all the pieces are of an activity and then bringing those together around a user's need and kind of building them from the ground up. And that may mean new systems. It may mean a new app; it may mean a new brochure or a new loyalty program or whatever that new system to support the experience is going to be. Now, service design actually was first mentioned in the early '80s

by Lynn Shostack. And her whole contribution was that we need to look at that kind of "behind the stage". You know, we can see what customer service looks like and how services are delivered and products are delivered. But we need to spend more time and take more care with how the organization and how all the different employees are lined up in order to make a service happen.

Sarah Gibbons also adds that the responsibility of everybody in the organization is really necessary. It's not just something that can be left to management like it used to be. Now, I think of service design as something that is the culmination

and the bringing together of UX design, human-centered or user-centered design and design thinking, which is essentially an application of human-centered design. And then, as we've been talking about, this omni-channel or cross-channel environment; and this kind of merging of product and service together and ways to contact, for example, is very omni-channel. You might use a a chatbot. You might use a form on a website.

You might pick up the phone, or you may use a softphone like a Skype phone or web audio in order to reach out. So, I think we've come from this kind of desktop where we're sitting at computers – at least with the digital delivery and – you know – filling in forms and doing things online – to kind of getting up and moving around and being able to pull up those forms and being able to chat online right from our mobile phones. So, here our mobile phones take us out into these different physical environments,

these different service environments, and they bring that social context in to the design problem. So, on top of that, of course, we add business processes, procedures, operations logistics, workflows. And that's what really makes up service design and differentiates it from UX design. And the goals of service design are to transform this service delivery experience. So, it's not just the user's experience.

That's important – that user customer experience. But it's also the organization and all the actors that are involved in delivering that experience. It's taking something that's *digital*, *physical* and *social* for sure – right – because a customer's interaction with a customer service rep is a social experience; walking into a physical space is a social experience – and mixing that with human-centered design and design thinking approaches to service delivery.

And that's really where we're at with defining service design. Why service design? It's really about reducing complexity of these kind of complex systems and thinking about this *over time* – you know – the relationship with the customer; their pain as they're problem-solving throughout the lifetime of their – you know – maybe their actual life, but their lifetime as a customer; and *holistically* taking it from a big, big, wider systems perspective.

For service designers, service design's goal is really to align and take advantage of the *resources* you have in your organization; the *user's needs* – the understanding of user needs and empathy; and the *outcomes* that your organization is trying to get. It might be a conversion rate. It might be a signup. It might be getting someone to complete something on time – for example, a tax return or IPO filing and bringing that alignment to the customer, to the service provider

and the stakeholders that you're working with as a service designer in your organization. So, for me, what it takes to get service design right is you've got to keep your eye on the backstage as well as the frontstage and the systems and processes that connect it – so, almost like that *middle-stage* in between, that invisible line that crosses over.

And you want to also avoid missing details on the frontstage, at the interface side. So, that's where a grounding in user experience or experience design can be very helpful. It's important to *have your teams engaged*. There's a real emphasis in service design on *stakeholder engagement* and having what I call working towards a *total experience delivery* – a TED, if you will. So, a couple of acronyms there:

Total Experience Delivery – you know – that you're thinking about *all the moving parts and pieces* and you're *actually delivering them*. You're not just drawing it out or recommending it and then – like you might do with UX. Teams converting from UX to service design is definitely a challenge. But I think doing it right means that you're not just clear about UX but you've got the service design competency built on there.

And that means *specialist knowledge*. We've talked about systems thinking, the whole picture or the holistic thinking and then FTP – or "Framing the Total Problem" as I call it – FTP and TED. So, Total Experience Delivery; Framing the Total Problem. Those are two things that are really important in terms of getting service design done right.

(Frank Spillers:) I think service designers talk about this line of visibility. And can you just talk a little bit more about that – that dynamic between front-end and back-end? (David Bill:) There's actually two lines. There's the line of visibility and the line of interaction. So, the line of visibility is the interactions that the customer can see. And so, that's – let's say you're going to a pharmacy and you're getting your prescription, right?

It's you walking in the door; it's you going up to the pharmacy counter; you interacting with the attendant; she being able to punch in to the point-of-sale device all the information that you're giving her; that is then going into a database. That database is then being connected to some sort of distributor

who is getting the drugs from some sort of pharmaceutical company. So, you know, it's this massive web of interconnectivity. There's obviously lots of layers there, but the line of visibility is really what that individual, that customer can see. And then the line of interaction is what *that staff* is doing and what they're interacting with. And then all the back-end systems – that's what's happening behind the *lower portion* of the line of interaction;

the distribution – you know – the partners, all of that kind of thing; the database. (F.S.:) Yeah. (D.B:) You know – that stuff that *not* the customer *nor* the staff member is going to see. I think that while Service Design can answer a lot of big questions around how services are implemented, I think the trouble is that as much as it can really

dive into some issues when it comes to a particular service, the people, the culture of that organization has to be ready to really embrace it. And – you know – it's the whole idea of taking a horse to water. (F.S.:) Right. (D.B.:) And if you take a horse to water, that doesn't necessarily mean they're going to drink. And so, here – this is something where we're seeing this with the IRS

and the agencies I've worked with in the past. We can show them these different methods, but, you know, they're dealing with all kinds of legislative, technological issues that hold them back from really being able to do a lot of interesting work. It doesn't mean that you don't have good people who want to push the needle. But they're hamstrung. (F.S.:) Right. (D.B.:) And it's a bigger, more complex issue than we would like to really admit.

And I think that a lot of times stuff is just pushed underneath the rug. But I think what's happening – you know, especially in my case, and I feel like I'm lucky in that regard – is we have an agency that recognizes the need for something like this. And they've brought us in to help evangelize and socialize this idea, this concept, this approach of service design

as a means of improving the various products and services that they offer, and ultimately not only improving the customer experience but increasing their bottom line.

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?