Service Blueprints

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.

(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.

Given that satisfaction aspect that was in ISO  standards and early talk of HCI – it was in NORD for so many years – why is it that now you've probably got a title – you could well have a title – like User Experience Designer or something like that. So user experience has become an intimate part and often the dominant part  

of the way in which we look at people  interacting with computer technology. So why is that the case? Well, part of it was the  shift to service orientation, and that's quite crucial, obviously, for what you're doing today. If you're service oriented, there's a different aspect of user experience than things that are more pay once and go on. So the Internet pushed this movement towards service orientation, the digital goods,

the paying on a subscription basis, rather than the paying once and for all. But because as soon as something becomes a service, then there are multiple choice points. If these are domestic products, then there's a choice point based by the actual user, rather than a client on behalf of the user, perhaps their boss. And if there are more choice points,  then usability and user experience increase in importance. Because if the person  isn't enjoying what they're doing,

if they're not feeling it's fulfilling them, then they're  going to choose another service and swap services. It's easier to swap services than to swap  harder, once-and-for-all bought products.   So there's a sort of a criticality to user  experience that grew out of this service orientation. However, that's not the end of the story. In some ways, and you might have heard that phrase,

"You've never had it so good." – there's an element of this towards user experience. Some of you will probably come across Maslow's  hierarchy of needs. There are multiple memes   with variations of this triangle going round  social media. You've probably seen the ones with Wi-Fi at the bottom. What Maslow said was that there are different levels of need. At the very base there are things like our  physical need for food. Are you hungry? Are you thirsty? Are you cold or too hot?

Above that, there are slightly higher-level needs for safety and security. And this involves shelter. Is your roof leaking? Is it a solid house you're in? Do you feel secure where you're at or do you feel  in danger? Next up the hierarchy are what's called love needs or social needs, for your children, your parents, your partner, your friends.

Next in the hierarchy again, is esteem or ego. The things that make you feel good. Prestige  in your job, status, self-worth, self-confidence. Then Maslow placed at the top of this, although there's variance sometimes, even additional layers. But the original one at the top of  this was self-actualization, things like being creative, autonomous, a sense of personal growth  and identity and learning, like you're doing now.

What Maslow suggested was we fulfill these needs in a fairly strict order. So we don't try and worry about higher-level needs when the lower-level ones are unsatisfied. So first of all, [if] we're hungry, that dominates everything. After that, there's safety. After that, there's love needs. That was Maslow's suggestion about the way these worked, and these have been used quite a lot in the psychology literature in order to try and

understand the kinds of decision making that people do. And there's certainly a truth to that. Now you can sort of see an equivalence of this for user interfaces. In one sense there's raw functionality. Does it do the job? Does my phone help me make a phone call or help me connect to the Internet?   Once you've got that bare functionality,  you know, does my light come on when I want it to come on? You then start [thinking] about usability. You know, is it easy   to phone somebody? Is it easy to use the Internet?  Is it easy to get my lights to come on when I want to?

And then, once you've got that usability,  you can start to worry about user experience. Is it a joy, the way in which my lights come  on, perhaps automatically, subtly, in just the right way? Or perhaps when I just make this faintest suggestion it's getting dark here and my household assistant realizes that means I'm about. And there's a suggestion in a way you  can think of these a little bit like the Maslow ones.

The functionality comes first. Then once you've got functionality, you then worry about usability, and then you worry about user  experience. And so you can think about it that, over the years, we've sorted out how to get  functionality and technologies improved. Our ability to work out what people need has  improved. Then we've sorted out usability, and then of course user experience becomes important at the top of the cake. And again, there is a truth to that. There is... in some sense we need, the lower level needs to be satisfied.

And certainly if you look in certain sorts of situation, if particularly – say, a safety-critical situation – functionality and usability, probably  more significant there than user experience. So again, there's some truth to it, but  not entirely true, I should say. There are contradictions. So I think there is a truth to this, it's worth thinking about and realizing that when you make design decisions, where you're putting your focus,

is it on user experience, is it on usability, is it on functionality? Think about which are *most critical* for people. However, if you look at both the Maslow's hierarchy and then think about this in terms of user experience,  there are clear contradictions. So, the Western obsession with slimming, which is about putting ego and self-actualization potentially, arguably,  puts prestige versus hunger

and sort of saying, “I'm prepared to be hungry in order to be the ideal shape that society says I should be.” If I'm talking too long, if my video is too long  and you get hungry, does your need or your desire for learning, self-actualization, overcome your desire for that hunger? Now there'll be a point when that probably won't be the case. But we do trade these things off.

Apple, of course, known for their user experience. They create delightful products that make people feel committed to them. It's about identity as well as about joy. But if  you unwrap an Apple box – their packaging is an experience, it's like opening these things.   However, often over the years, and this is going  back, you know, not a recent thing. Apple has sacrificed usability and functionality in order to get something that looks good, feels good,  

but sometimes may be a little harder to use.  And sometimes doesn't even do the right thing. And yet the computer I'm using now is an Apple  computer. So clearly they get something right, even though I know that they lose things as well along the way. So, there's both a truth to this hierarchy and not, but this certainly helps explain

one of the reasons why experience is so crucial. If everything else is right, then it becomes the key differentiator. The thing that says somebody wants to use your product, that you've designed, rather than somebody else's.

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.