Past the pixels: Understanding service design
Develop effective products with measurable impact by leveraging service design. In this session, we will explore how to employ systems-level planning and design thinking to build human-centered products that deliver results.
Watch the talk:
Transcript:
Today we're going to talk about moving past the pixels. What does that mean? I'm going to ask you all to open your minds to new possibilities of what it means to talk about experiences. And to do that, I think we need to go a little bit back in time. Back to one of the most original of memorable technology experiences. Can anyone tell me what this is?
There we go. What was this Nokia 3000 from the 2000's famous for? Indestructible, that's right. That was the differentiator of the Nokia 3000. If you had a Nokia 3000, you could run it over with a Jeep, you could drop it off a mountain. I dropped mine off a mountain, it survived. Someone here actually ran theirs over with a Jeep, good. There we go, see? I thought we'd start with challenging that expectation a bit.
You have been asking me to blend a Nokia 3310. Some believe it's the toughest thing known to man. Able to withstand Thor's hammer or survive a roundhouse kick from Chuck Norris. So let's see if it holds up to a Blendtech Total Blender. I'll throw in my precious and press the Fires of Mount Doom button.
Oddly satisfying, isn't it? Even though it had this reputation of being indestructible, in the right context, it can't be destroyed. But that was important. When phones were becoming a consumer device and they were entering the market for the first time, the differentiator was the quality of the device. And that was a pretty easy differentiator because the experiences that happened to the device were all pretty limited to texting and phone calls. If you were very, very lucky, the game Snake. How many people played snake on their phone? And they go, "Yes!" Did anyone not have a phone with snake on it? I guess that's maybe even a better question.
Today it's a little bit different. Can anyone tell me what these three phones are? I heard two, what's the third? Pixel. Do you know which one is the iPhone? Yeah. Which one's the pixel?
Right, good. Your brain still recognizes the pattern, but what's the differentiating factor between these? And we're not going to get into an iOS versus Android debate here. They all basically give you access to the same world. The baseline for our experiences is now through these portals that we hold in our pockets. Now, I'm using the example of a phone. I could have used home assistants, I could have used computers, whatever it might be. But the reality is the power that technology gives us is becoming more commoditized. And since we just expect things to work, we have to change the way that we think about providing experience to people through those devices. Because when I interact with one application through this portal and I interact with another application through this portal, I'm going to judge them against each other, whether or not they're related, because that's my experience using my technology assistant.
I'm reminded of the show Quantum Leap, where come through the portal. No? Anyone Quantum Leap, just me? I got one Quantum Leap fan in the back. What I'll do is I'm going to help you see into the future, but more than see into the future, understand what it really means to make something that's differentiated. Because right now this is what differentiated means for a phone. Which is five different colors and two different sizes. I tried to find a picture, I saw it but I couldn't find it again, of a case for the iPhone 11 pro that had Arnold Schwarzenegger holding a bazooka, which may be the best adaptation of industrial design I've seen.
But when you have this limited differentiation, how do you find the path forward? This isn't a new problem. I figure I'm talking about iPhones a little bit here so I should go back to one of the OGs of user experience. Does anyone know who the person is that coined the term user experience architect? This dude, Don Norman, I [inaudible 00:05:00] someone. Don Norman wrote this book, The Design of Everyday Things. If you take nothing away from today's session, I would ask that you go and read this book. It is old, but it is still valid. Don Norman created the term user experience architect because he saw a gap in how people were talking about technology. This was in the 90's and this is how he defined it. He said it was everything around the experience, including the interface itself.
I think right now, when people talk about user experience and when I see people talking about it, I hear them talking about it in terms of usability and wireframes. I see them talking about it in terms of cool UI patterns and the new UX opportunities that are possible by using new software platforms like Figma. But none of those things actually provide the experience. It's the work that the team does and how that solution fits into a larger context.
A couple of years ago, they interviewed him. They said, "Don, how do you think the term UX is being used today?" I took this excerpt out. He wasn't too happy in the interview. He seemed pretty frustrated and I think rightfully so, because what it meant to deliver a good user experience had drifted to just be a cool UI. I think for a while, having a cool UI was sufficient even if the experience itself was lacking. I think most of us can agree that's no longer the case.
I'm going to give you some tools today on how to plan for and design that superior experience. It's going to be through one aspect of a full stack delivery effort, which is service design. Has anyone heard this term before? Couple of people, good. Couple nods. Is this new for anyone? Good, only a few nods. All right. Let's talk about it. Service design is really about understanding the complete system that something lives in. I think when we normally talk about software delivery, most people think of it something like this, which is there's a person who has a problem. This is by the way, my co-host today, they're going to show up a lot. And this problem goes through some series of actions and then they get to a solution. Then it's great.
This is in a baseline way, how we talk about software, all the way down to how some people write stories. As a user, I want to, so that and then the business gets. We're not going to get into the Gherkin story writing format, don't worry product managers in the room. But it is ingrained in the way that we talk about things. I'm going to challenge you to change the way that you talk about it [inaudible 00:07:30]. Being user-centered means moving beyond that framework of a simple problem and solution statement.
Now, user-centered design is good. We can all agree on that. Does anyone think user-centered design is bad? Thank goodness. I don't have time for that conversation. But how does that actually usually end up playing out? Well, it usually it starts something like this in a software delivery process. Here's a person, you might recognize the object next to them. It's a standard BRD. I think that's the traditional size of them, one human tall, for the stack of papers in the corner. This person has made a stack of papers with requirements on them and they're going to take these to somebody else and that person is probably going to talk to the person that has some money. They're going to say, "Hello, money person. Could I please have the money? I have a stack of papers. I want to turn it into something."
That person's going to go talk to someone else and they're going to say, "Hello. I want to use some of your money to go build this thing." And they say, "Okay, let me just look at the org chart real quick. Yeah, okay. Let me go find the right team to work on that. Hold on. All right. Yeah, okay. Yeah, I know who it is now. Okay, we got the team, good. Let's go ahead and build out that team. That's a good team." Now that we have the team together and we have agreed to fund it, we haven't talked to anybody about it yet externally, but we've agreed to fund it. Now we can start working on a big stack of papers and that big stack of papers can be turned into software. That's how it goes.
It's exactly that line. Nothing ever goes sideways, does it? You usually don't get the software right away, do you? Usually, once the team has the stack of requirements and the team starts to digest them, they then take those requirements back to the original requirements person and go, "Can you explain these 65% of items that I don't fully understand?" That conversation happens. The team that's working on it goes back to the person that usually has the funding and says, "Hey, we need three more people." That person then goes and talks to the person in the org and says, "Hey, I need access to these five other departments to do this successfully." Then that sparks off, yes, this line to this whole other team that started the same effort or a competing effort or something related.
Now, all of this happens and by the time this gets here, a new stack of requirements has happened from this new team. Meanwhile, our old pile of requirements is starting to age a little bit, starting to get a life of its own. The people that are around that stack of requirements start to change. Now you have these zombies that are chasing this old set of requirements because they've been told they must get the requirements completed. They're feasting on it. Stories, stories, and then next thing you know, that's it. The whole team's gone and done for.
It doesn't have to be this way. We don't have to make this decision between value for the business or value for the users. This is where service design comes in. [inaudible 00:10:31] say if you, as soon as you see that stack of requirements start to pile up, deploy the discipline of service design, you're going to avoid that churn and probably not turn your team into zombies. I think we all agree that we don't want to turn our co-workers into zombies. Service design means understanding the system a product lives within. Notice there's nothing up there about an interface. There's nothing up there really about usability although, that's part of it. There's nothing up there about a slick experience or cool animations. It's about the larger system, in the larger context that product exists in.
Now, when we start to talk about this problem, and let's say we're doing it the right way, we go talk to the person that needs to go on that journey. Here's a person, they need to go from Point A to Point B, whatever that might be. Maybe they need to go from Chicago to New York, it doesn't really matter. Wherever it might be, physical or otherwise, they need to go on a journey. And so we talk to them about what their Point A is and what their Point B is and we say, "Oh, I think other people might have to go on this journey too. Let's go find some of those people and talk to them." User research. So we go and we find those people, here's some of his friends, and they all want to go on the same journey.
When you talk to a group of people that all seem to want to go on the same journey, what do you realize? The journeys all have slight variations in them. They're not all exactly the same. And usually what it turns out is these are all people acting in a part of a larger journey that each have their own discrete roles to play. The more that you talk to these people, the more that you realize their challenges are unique, their opportunities are unique. That person in the bottom corner shouldn't have been in the research study at all. They're very lost.
So to build meaningful experiences, we have to design for people living real moments in their lives. That means putting ourselves in the position that they're in and trying to understand the journey that they're going on. That means moving past the place where we talk about running, skateboarding, biking, motorcycling, and having a car because this conversation never actually goes this way when you iterate. We talk about this model a lot as a mental model for iteration. And we all wish, well, what if the person at the end was just holding a picture of the car because the car's what they wanted at the end anyway. Why couldn't they just tell us that upfront?
Well, the reality is that's usually not even what they want to go for. When you talk to them, they might give you different details. They might say sometimes they need to run, sometimes they need a skateboard, sometimes they need a bike, sometimes they need a motorcycle, but that's because everything they're doing is small discrete parts of a larger whole. Any product that we make, anything that you build exists in the environment around it, it's not the product discretely. When I think about something like those different modes of transportation, I think about them as something that is mobility. Has anyone heard the term mobility before? I see some Allstate alums that I know in the background that are totally raising their hands right now.
Every industry right now is going through and starting to talk about the challenges facing their industry in the context of a larger whole. It's not about how do I walk from Point A to Point B? It's not how do I get from a current state to a future state? It's all the discrete ways that I might get there and all the different tools that go into that. In the case of mobility, a great example of that is the transit app. Has anyone seen this application before? Anyone use transit every day? I do. I can't get around Chicago without it. I think what transit does really well is that it takes all those discrete aspects of mobility and puts it into a singular application.
Why is this important? Well, the people that make transit are trying to solve for the problem of you getting from Point A to point B, they don't care how you're doing it. This has been so successful that any Lyft users in the room, Lyft now gives you transit instructions because they don't want you to open another app. They noticed that people were going to transit to decide where to go. They don't want you to go to transit. They want you to go to Lyft and then Lyft will tell you where the bus route is and Lyft will tell you where the train route is. Why? Because Lyft has stopped trying to solve the problem of how do you get in a car and how nice is that car and how many strangers are you willing to tolerate on that ride? No one's had a bad Lyft line experience, I know. They're always nice.
But instead they're saying, "Okay, we know that people need to get around." So they've re-addressed that problem of getting from Point A to point B, by incorporating those other modalities into their application. Transit takes it a step further and they say, "Great, here's the larger context of your journey and if you want to make this journey happen, if you want to make this journey work, then you should probably leave in three minutes and this route will work for you." Each of these items are addressing a pain point that you might have if you're trying to navigate a journey. Now I'm using a very literal example of physically going from Point A to Point B here. But this also applies to the way that people navigate a software solution.
One technique that you can deploy is known as service blueprinting. You might call it a service map. You might call it a really, really detailed customer journey map. I'm going to break down for you now, what that is and how to use that to identify these pain points. That way you can add to the experience in the larger context and solve these small problems that actually are the differentiator between picking up one application versus another, or being efficient or being inefficient at deriving that solution.
Everyone's familiar with the first step of this, right? The user journey, we've all talked about that. This is also the level that most stories are written at, and they don't go much deeper than this. It's just the path someone goes on. The reality is this is comprised of a second component, which is their touch points. And those touch points are with printed materials, applications, various apps they might use to complete a task. But it's all the discrete things that person has to interact with to go on that journey successfully. Some of those things are in your control and some of those things are not in your control. By documenting each of these things as discrete items, you can understand what is known as the complete frontstage experience.
Any theater nerds? The frontstage, very simply put, is anything that's happening in front of the curtain. Now, anyone who's seen any kind of stage production knows there are things that go into the show being successful that happen behind the curtain. We have the frontstage fully understood, we need to then support that with an understanding of the backstage. The backstage is any business process that's happening that is not directly related to the customer experience or the main user experience. If there's a secondary system that has to manage approvals, that's an important part of a backstage experience. If there's a secondary group that has to provide you with components, so that way your application can run, they are also a part of your backstage experience. Each of those components plays into it and they should be understood as core parts of that total customer experience.
Underlying all of that are the business support processes. This is the area that I think most people miss when they're mapping out an experience. The support processes are all the extra discrete things that a business might do to make something work. There's a central idea of the customer somewhere, that's a core support process. Your authentication, your authorization, that is a core process. If there is a external API you're pulling in to provide some sort of data, some sort of context, that is a key support process. If there is an additional set of functionality that they need in a secondary system, but it's not part of the core experience, it's a support process.
Each of these support processes have to be discretely understood as well. Now the reality is when you're documenting all of these, they don't tend to all happen at the same time. Everything happens in sequence. When you're documenting them, they tend to actually come out in chunks and there are handoffs that will happen along the way. When you document each of those things discretely, you're then able to arrive at what the core pain points are and assign those pain points to different groups. And I want to give you a couple examples of how that might play out.
How does this actually play out? Well, in practice you're going to need to go and talk to each of these groups of people individually. You'd have conversations with the users, yes, but also with the back of house or the backstage people that are supporting that process and interview them with the same attention to detail that you would a user interview. Then once you have talked to the people that own those backstage processes, you can then go and investigate their support processes that make them successful. You're thinking about this in the complete context of what you're working on.
A very simple example of this that I like to use is the process of ordering a pizza. Your frontstage experience ordering your pizza is whatever your favorite pizza app is on your phone. Door Dash probably at this point, Caviar, Uber Eats. You open that application and then you put in order pizza. That's the end of your frontstage experience. You have lost your ability as a customer to successfully make your pizza arrive, unless you're going to go to the store and make it yourself. What happens to that pizza order after you hit submit? It's sent to the store, it's probably going to hit some sort of cell phone towers. It's going to hit some sort of backend servers at the company. That company is going to have some sort of routing that sends that order to the store. How does the person at the store know they have to make the pizza?
Has anyone gone into a store and seen seven different iPads in the corner? They have to watch for it. The most successful experiences are going to print that order and it's just going to enter into the queue for the person making the pizza. Then as soon as that person acknowledges that they're making that pizza, ideally that pushes a notification to your phone that says your pizza's being made. And you can follow this all the way through to the driver and their support process of Google Maps, being able to find your house. Which if anyone's ever taken a Lyft or used GPS in Chicago, knows it's additionally challenging because we have alleys. Has anyone had their pizza show up behind their house in Chicago? But it's because of a failure of the support process of Google Maps. And that has impacted your ability to accept your pizza as a customer.
How does that look in a business context? Well, here's a nice, neat service map talking about onboarding new employees to a system. It's fairly detailed. I think when most people think of a service map, they think of something that's clean and detailed like this, where everything is discretely laid out and everything has a lot of unique detail to it. What results from this, is people spend way too much time working on the solution. Instead, I would say something that looks like this totally counts as a service map as well.
I think a lot of people don't invest in service design because they think it has to be this big fancy thing. Because if you go online to Google and you Google, what is service design, you're going to get a bunch of things that look like this. Now these are valuable and you might need to do something that's this high polished to convey what you're trying to convey, but doing smaller versions that are just basically essentially posted to notes are sufficient as well. Because the reason that you're doing this is not to make this, it's to help you identify the areas and the gaps that you don't see. It's the gaps that you don't see that create the pain points that result in some sort of struggle of adoption or unsuccessful product.
Sometimes understanding one journey is not enough. You have to understand multiple journeys to fully get the context. A group of people went to to a resort for one of our clients. I think this was a very challenging trip for them, they sacrificed deeply. I thank them for their service to Devbridge. One part of the trip was the customer experience and one part of that trip was going out and enjoying the resort and fully understanding and appreciating what that resort experience was. Another part of that experience was going behind the scenes and understanding everything that has to happen to make that possible. Another part of that was understanding all the underlying software that that back of house team used to create a great front of house experience.
Now, is anyone ever familiar with the way Disney does things? Disney has one of the largest back of house experiences of any company and you never see it as a guest. I think when you think of service design, everyone thinks of Disney or Apple as the example. But you don't have to be that complicated. You don't have to build in secret passageways into your application or into your company to leverage this discipline. It's all about understanding the discrete players involved and appreciating that each of them have a role to play in that customer journey being successful.
We broke that into three key areas of the journey. The pre check-in, the arrival, and obviously the fun starting. Then you use those different contexts to understand how the application should be built and how the application should be developed. What are the unique considerations for the technology? Should we change what information is displayed to the guest on the app, based on where they're at in that check-in process? Have they already arrived? Are they about to arrive? Do they have a trip scheduled or not? Then mapping out how that application might behave when discrete elements of the phone's technology were enabled. Is there connectivity or not? Is there reception or not? Do they have the information on their phone or not and how can we plan for the experience being that way?
Has anyone ever opened an app and tried to scroll through it and do something important like go to a ticket for an event and the ticket doesn't load or you can't find the ticket? You go to the box office, they're like, "Do you have the credit card with you," whatever it might be. Those moments are avoidable when you understand the dependencies that are involved in that successful experience. When Ticketmaster finally added add to wallet to their app, which wasn't that long ago, it changed the way that I felt about their app. If I got a Ticketmaster ticket, I would just have them mail it to my house because I trusted the USPS more than I trusted their application. When you do that, when you go through and identify all the discrete elements that might be involved, you're also able to identify what are the meaningful things to measure. By understanding where the pain points are and where the vital decision making points are, you can then match the metrics that you use to those moments.
Another example of this might be digitally onboarding to a financial product. If you're digitally onboarding to a new financial product, there's three key moments in that digital onboarding process. There's your experience making the decision to onboard, there's the physical act of onboarding and there is that first and immediate use. I'm using finance here, this applies to any customer acquisition process or any first experience someone might have. When we talk about this, I often hear people talk about it in terms of well, a person has a list of requirements and they start to gather their material. They take those requirements and they put them into some system. That system accepts that information, their personal information, and they verify their identification or either verify they are who they say they are. Great, the bank knows who they are, the bank considers it, approves them, and then they're done, they can party. The customer has been onboarded. They have digitally onboarded omni-channel style.
But no one talks about it like that. Has anyone ever woken up in the morning and gone, "Yeah, I think I'm going to digitally onboard omni-channel style to something today. A new financial product, maybe. Yeah, omni-channel onboarding, that's my Saturday."? No. What do you say instead? "I need a new credit card. I need a new credit card because my partner and I want to start combining our finances. We want to have a joint card where we can start on that journey." I need a new line of credit. My business needs to expand. How do I get my business to expand with that new line of credit? I have a thousand things I need to do. I have people I need to pay. I have equipment I need to buy." They don't go, "Sure hope my bank has omni-channel onboarding because this has really solved my problem."
Now we know as industry professionals that we have to have language like that to talk with each other effectively. Because if every time you had a conversation with one of your colleagues, you described all of the discrete parts of that process, every meeting would take five times longer. We create these words to use internally to speed up language so you know exactly what I'm talking about. If I told you, "Oh, wow! Yeah, I just totally watched all of Russian Doll on Netflix this weekend. It was great," you know all of the discrete things that went into me watching Netflix. TV, casting it, apps involved. I don't have to explain all that to you. But if I said, "I was sitting on my couch and I picked up my remote control and then I hit home and then I went through and I clicked through," we also don't need to be that detailed either. But we do need to understand if we're Netflix designing experience, where someone might be, i.e., their couch watching a program.
So it usually looks a bit more like this. Someone is having a really hard time, they have a problem they need to solve. Yes, they have to go and get requirements and they have to complete those requirements. All of that is true, but the final solution is only one piece of that final puzzle being completed. It's not the whole story. I think that's where a lot of teams get caught up when they talk about making a great customer journey or a great customer experience. Is they say, "Once my Point A to Point B is done," they're happy. That's usually not the case. There's usually additional pieces that have to factor into it to understand what that is.
In the case of digital onboarding to a financial product, there's a whole frontstage experience and support processes around providing information. The omni-channel experience is just part of it. There's a KYC, AML aspect where you have to actually validate that someone is who they say they are and confirm they're probably not going to use your product to launder money, both important. The approval, yes is important and they have the product. But then there's an entire secondary journey of their first use that you have to appreciate. And by the way, for any of that to work, there's support processes.
There's some sort of marketing funnel, advertising, awareness campaign that's happening that makes them choose your solution. There's session management, that's supporting any kind of omni-channel experience. That way each device knows that it's talking about the same customer in the same phases. Maybe they drop off, maybe they get halfway through the application. How does the system know to re-engage them, pull them back in? Now granted, that actual particular experience is maybe overused today. You can't look at anything on Amazon without getting an email from them going, "Pardon me. It appears that you looked at something. Might you buy it?" I think that's an example of over re-engagement.
But when you look at these moments where the pain points are, you can say, "Okay, how can I help them get over that hurdle?" The complete view of the customer, understanding all the aspects of their concern, also allows you to offer a superior experience. Then once they're approved, you have to send some set of materials to them to get them fully onboarded, their card or whatever it might be. Then there's the ongoing support processes and the support team that's going to answer their call or answer their chat or help them complete that onboarding process. All of those things factor in. So if your job is to onboard a customer, and you're just talking about the point the form starts, to the point they hit submit and the approval comes back, you're missing about 60% of the opportunity to deliver that superior experience.
That's really what service design looks to do. Is it looks to document each of those discrete parts of the experience as their own thing. That way you can understand where those opportunities for efficiency are. The customer journey is never as simple as what they tell you it is. You have to dig deeper and understand the struggles that they are going through, where those struggles are happening and why they're going to be partying when they're done. Both sides of this are vital aspects of that customer experience, in addition to building that deeper understanding of the business processes that support it. Service design means understanding the larger system that a product lives within. It's understanding the discrete components that make it what it is.
The customer journey is not the beginning or the end of the experience. We have to change the way that we talk about that customer journey and talk about it in terms of one step in one phase. So when you're having conversations about your user journey, you shouldn't say, "And then they're done," because they're not. There's always going to be a next thing, there's always going to be the next touch point they're going to have. Whether it's an internal system and process or a larger onboarding. You have to break each of those things out into their own discrete list of to-dos with discrete owners, and then track that ownership across the system. When you do this, you're able to exceed expectations. When you exceed expectations, that's where the customer happiness comes from.
If you look at this and you expect that this is potatoes and you go to grab a potato and it's not a potato, it's a paper. How many people have gone through a customer experience that is something like this? Where the initial customer signup looks so great and then you go to have one, it's that. This is the customer experience that we want. And you get that by imagining the larger system that it exists in. I don't know if you know, but this is the planet the potatoes come from, it's a fun fact.
How does that fit into the larger context of software delivery? A team may have no idea what they're doing or why they're doing it, but that's okay. You can deploy service design to better understand the opportunity that is in front of you and better understand the requirements that go into that opportunity that might not be a part of your product. How grateful would a team be before you start delivery, if you go to them and you say, "Here's my dependencies that I have on you to be successful. Can you meet these dependencies for me?" I trust that a lot of people in this room have had that conversation and have had a much better time interfacing with our groups because of it.
Then you can document and understand the outcome through the pain points and arrive at metrics that are going to be meaningful to measure progress. Build something small, decide whether or not it's working, if it doesn't work, great, the investment is small, build back in, solve the next problem. As soon as something is valuable, boom, release it to market.
Service design is one small part of this working well. But by understanding that entire system, you will be more effective as a team, but also you will be more empathetic as people that build software. Because anything that we build is replacing interactions that people might have otherwise. Anything we build is a component of someone's life. If you're building an internal system, you're building their work bench, you're building their work environment. If you're building an application that helps people onboard to a product, that product is one small part of their day. And the more appreciation that we can have for that as software professionals, the better products we're going to make. Thank you.
About the event:
Full Stack Friday is a monthly, meet up hosted by Devbridge at our Chicago headquarters. We get together to indulge in a delicious pancake breakfast and talk shop. We bring in guest speakers to present talks focused on issues relevant to product people and full stack teams. For more information about the next event, contact us directly.