Service Design for Product Designers

Justin Zalewski at UXDX Community: [In-Person] Product Enablement Principles in partnership with Product Tank. Video: https://youtu.be/cvUOa_tZzk4

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

What even is service design?

[00:00:00] My name is Justin Zalewski, and like Rue[?] said, I'm the director of product strategy and design at Studio Science. We're a design and innovation consultancy, and today I'm going to talk to you about service design. Specifically, what we as product designers can adopt from a service design mentality and mindset to be more effective in our roles.

[00:00:20] But first, I want to let you know I am not going to today try and draw or redraw the lines between product design, UX design, CX design, interaction design, service design, all these other labels that we use. I just find it so tedious and unproductive. And so I really want to focus today's conversation on just, how do we get better at our craft of designing products and experiences?

[00:00:43] So I'm going to use the term product designer today, and I'm going to use it in this talk only to mean a designer that's working on a company's digital product. So they work on, or at least with, the product team at their org, but their title might be product designer, UX designer, etc. So I'm not going to talk about all that. What I am going to talk about is how product designers can benefit from incorporating a service design approach and skill set.

[00:01:09] But let's start here. Some of us have probably already heard about service design, but let's make sure we're all starting with the same kind of foundation. So, what even is service design? There's a lot of different definitions out there, but here are a couple of my favorites that I think really encapsulate what's valuable and what's unique about service design.

[00:01:27] So this first one from Livework. I love that this emphasizes that it's the application of established design processes and skills. It's not reinventing the wheel. A lot of the design process and thinking behind it is going to be the same, but we're thinking in terms of services rather than touchpoints.

[00:01:47] And then the second one from Birgit Mager. What I love about this is the emphasis on, we are choreographing these different aspects of a service, the processes, technologies and interactions. So we don't need to be the ones to invent the new technologies and interactions. Service design is a great connector of disciplines. And so when we think of ourselves in the role of choreographing or facilitating, bringing people together that are experts in these fields, we can help to break down these silos and really take that top-level holistic view of it. And then I love the second part here as well, of emphasizing that co-creation aspect. We're not just creating on others' behalf. We are co-creating with other stakeholders. We'll talk more about co-creation a little bit today too.

Digital products are services

[00:02:34] One of the first things I want to call out today is the difference in the mindset. These digital products that we work on today, or that so many of us work on today, are not just tools that people use. They are services that are designed to meet the needs of customers along some kind of journey. So for example, we could think of Airbnb as a product or an app, but Airbnb is a service. Airbnb serves the customer along the various stages of their vacation journey. And even on the B2B side, we could think of DocuSign as a product, but DocuSign is also a service. DocuSign serves their customers along the journey of getting a deal done, a document signed, what have you.

[00:03:11] So because these digital products are more like services than they are like products, product designers can be more effective by using a service design approach. Again, not getting into labels, not trying to advocate for title changes or anything like that. There is value to be had in those different disciplines and all that, but that is not what this is about. I want to focus us on how we can use that service mindset to evaluate and design improvements by looking more holistically at an experience rather than simply at the touchpoints.

[00:03:44] And that brings me to this. If you come away with just one thought out of this, I want you to remember that a clickable prototype is not enough. We love our clickable prototypes as designers, right? The clickable prototype is so often the artifact and the point of focus for product designers today, and not without reason. Clickable prototypes are so much easier to produce now, and we have more than enough options for how to create them. Most of the time the teams that we work with tend to spend a majority of their time and focus and budgets on the most visible parts of the experience. So designing these visual parts with a clickable prototype makes sense in that way.

[00:04:24] But here's the problem. When we stop at the clickable prototype, we ignore some of the most important elements of an experience and the service. And those are the space between the touchpoints, and what's required to make that service a reality. And by that I mean, who are the people, the processes, the systems that support that end customer experience?

The space between the touchpoints

[00:04:45] Let's talk a little bit about each of those. So, the space between the touchpoints. What's happening with your customers when they're not looking at the screens that you've designed? What are they distracted by? What other kinds of notifications are they receiving? How much time is passing? All these things that change their context, their needs, their goals. And how that experience feels to a customer as it's experienced in reality, not just as a touchpoint in a vacuum, is really what we want to be thinking about and what we're going to optimize for.

[00:05:15] So therein lies the problem with clickable prototypes. They're so focused on a linked set of screens rather than the reality of a person's experience, which can occur through different channels and different spans of time. But that can be difficult. That introduces some challenge. How do we prototype and test an experience over different channels, over spans of time?

[00:05:42] Well, I like the way that the authors of a book called Service Design Doing put it, so I'm going to borrow their terminology. They talk about direct experience versus indirect imagination. So direct experience is where people use the prototype, or experience the prototype in a way that lets them experience it themselves first hand, versus indirect imagination, which helps people to imagine the intended experience.

[00:06:09] And it's not totally binary. There's all kinds of gray area between the two, but you can think of these as two parts of a spectrum. So direct experience has a lot of advantages, as you might imagine. It's the most direct representation of the experience, so you can get the most genuine feedback and learning from that. But oftentimes we run into obstacles with scope, timeline, budget or participant availability, where indirect imagination can be a great option as well.

A pilot program: direct experience

[00:06:38] And I'll talk a little bit about each of those two. So, first example of direct experience. At Studio Science, we're working with one of our clients, they're a Fortune 500 engine manufacturing company, and we co-designed this pilot program with the employees that would be responsible for supporting this new service. So there would be these account reps that would be involved in this process. There's a digital part of the experience, but there's also a lot of people interactions within this.

[00:07:06] So we co-designed this pilot program, and the pilot program had the participants, who were employees in this case, test this newly designed service over the course of a week. And we would learn how the new service is working through daily feedback prompts, personal check-ins from our team at key points. So we gather valuable feedback, the employees get to test it out, see how it works for them, and we de-risk the new service for the business by testing it with a small cohort of customers before any larger rollouts.

Scenarios in a moderated test: indirect imagination

[00:07:42] Now let's contrast that with indirect imagination. An example here: with that exact same client in another situation, we were not able to line up a pilot program due to time constraints of the participants. But we were able to set up specific scenarios in a moderated user test that helped the participants understand and provide feedback on this new multi-channel service.

[00:08:06] So here's what we did. I'm going to show you a few screens of the prototype that we used on this project that I led, but the prototype has been anonymized to remove the client name and logo. And this particular prototype is a mix of work done by two very talented designers, Evan Strayer and Seth Richardson. We had participants go through this registration process using a typical clickable prototype.

[00:08:29] But when they got to this stage where they've submitted the initial registration, they're kind of done for a while. They need to wait for the client to approve their request, which can sometimes take a few days depending on a variety of technical and legal factors. So we can't just jump them to the next screen that they'll see, because that's not how it'll work in reality. We have to kind of reset the stage. So we say to the participant, "Now, after you submit your registration, imagine that a couple of days pass. You continue on with business as usual with your shop. What are your expectations of the company during this time?"

[00:09:02] And when we ask these kinds of open-ended questions, it helps us to test whether the experience that preceded this actually set expectations well enough, and it gets the participant to really imagine what they'd be thinking, feeling and experiencing, and what they'd be expecting during this in-between time. And then we transition back into the clickable prototype by saying something like, "Now, imagine that later that afternoon you receive this email in your inbox." And then we can pick back up on the usual clickable prototype testing process from there.

[00:09:34] So even though this was indirect and we had the participants use their imagination, we still uncovered valuable insights about how these gaps in time would affect the experience for them, and how we could adjust to better meet those needs. And we did that by intentionally framing up the scenarios with them using storytelling.

The backstage of the service

[00:09:54] All right. Now, the second thing that clickable prototypes make it really easy to ignore is what's required to make the service a reality. We find a lot of times organizations are trying to improve customer experience by designing touchpoints across the end-to-end journey, and they believe this will better serve customers' needs. However, these initiatives are usually one-sided, and they fail to account for the complete system that supports that customer experience.

[00:10:21] So in service design we refer to the supporting system as the backstage of the service. These are the people, the processes and technologies that are required to enable that customer experience. And when we map out the backstage, it's a great opportunity for co-design.

[00:10:36] We've all probably had this experience of having a new process dictated to us that requires us to do more work, or maybe to work in a way that we know doesn't fit the reality of the situation, and it's frustrating, right? So when we co-design with the people that are involved with the service, we can help prevent this for them. They're not being designed for, they're being designed with. And then as a result our solutions are then much stronger, because we're learning from their lived experience, and it de-risks the solution going forward.

Three risks of ignoring the backstage

[00:11:07] Because when we ignore the backstage, it introduces all kinds of risks for the company and for the team. We could fail to implement the intended experience. So when we design around all kinds of assumptions about capabilities, it adds risk to implementation. An organization might design touchpoints that require customer data from the CRM without realizing it's in this old legacy system that makes integration really difficult. Or we might be trying to improve delivery times, and we design some system that requires additional work from warehouse employees, but they're already operating at max capacity. So when we map out the front stage and back stage of a service, for example using a service blueprint, which we'll talk about in a moment, it helps us to identify and account for those capabilities before they become blockers.

[00:11:55] The second risk is we could fail to actually deliver that intended experience. Being blocked in implementation is certainly frustrating, but implementing a service that fails to actually deliver value could lead to even worse outcomes. It could be high customer churn, low customer adoption, a damaged brand reputation. So when we design the service holistically and with the relevant stakeholders, customers and employees, it helps to ensure that that organization can actually deliver the service, and that we're not at risk of making empty promises.

[00:12:28] And then finally, a big risk is that we could burden that team that is tasked with delivering the service. We could fail to support them. They might end up shouldering the burden of a poorly planned solution. And when organizations do this, they push forward a solution that doesn't really consider the impact on employees. Employees get burned out, as you might imagine, because they're trying to achieve goals that the design of the service makes impossible. So employees feel undervalued. They might feel resentful, like leadership is out of touch with the reality of their jobs. And when you've got a problem like that, no amount of training or employee engagement initiatives or fancy perks or anything like that is going to address the root problem of unrealistic demands in a job.

A surprise benefit: finding the other departments

[00:13:17] Now, another example here of a surprise benefit of mapping out the backstage and the systems required for a service. We were working with this client of ours on a customer adoption problem, where they had built a robust digital product to help their employees follow this proprietary process, but people weren't using it. So we went in and mapped a service blueprint along the customer journey, figured out where the design of the service is misaligned with the reality of the employee experience. No surprise there.

[00:13:47] But what was surprising is that we found other departments trying to tackle this same problem through different one-sided solutions. So we kind of had one of these moments where we're like, hey, tech platform team, you're also trying to solve the same customer adoption issue, but tackling it from a kind of technology-first perspective. We need to learn more about the technology, and we can bring the customer perspective through the research we've been doing. So we were able to realign the departments around one common goal, and this holistic approach saved the organization months of time and effort that would have been totally redundant.

Two ways to start: relationships and a service blueprint

[00:14:24] So, to bring it all in and make it tactical, these digital services that we are designing require an aspect of service design. And that doesn't necessarily mean that we need to call it that, but keeping this kind of service-oriented mindset and bringing this into our work is going to be really valuable to help us all make a bigger impact.

[00:14:49] So here are two ways that I recommend people start. First is to build relationships. Building relationships is such a critical part of co-design, but I also want to recognize that it's not always easy, especially for me. I'm very introverted and it would be much easier for me to design by myself in a room listening to music with nobody to bother me. But that is just not how change happens, especially in services and especially in larger companies, where there are just so many people involved in actually delivering a service, and when it can impact so many people.

[00:15:24] And the second thing is to map your service with a service blueprint. I'll talk about this in just a second. A lot of us are probably familiar with mapping out the customer journey, and this is just one form that a service blueprint can take. This is a template that we put together at Studio Science, and I'll provide a link to download this on the Figma community for anybody interested.

[00:15:47] You can think of that top row as pretty synonymous with a customer journey. It's really mapping the customer actions. But what moving one layer deeper into a service blueprint helps you do is map those other layers. So down into, on the front stage, what are employees at the company doing, for example, to enable that customer experience? Who are customers interfacing with at physical retail locations? What kinds of emails are they seeing in their inbox?

[00:16:23] And then going to the backstage, it's what's happening behind the scenes that the customer might not necessarily see, but these are critical factors to actually enable this experience. So we can map out along each stage of the journey, what back-end systems are in place, or need to be in place if we're looking at future state. What kinds of employees need to be trained in certain situations? What people does this rely on? Which helps us not only account for the capabilities, but also lets us know, who do we need to bring into this process to make sure this is all going to work the way we need it to work.

Three points to take away

[00:16:56] So if you want to try this out and check out the template, here's a quick link to download that free template on the Figma community. But yeah, to sum this all up, here are the three main points I want to emphasize to bring a service design mindset into our work. We need to be considering the experience more holistically. So we've got to make sure that the service we're designing addresses the needs of all stakeholders throughout the entire service.

[00:17:22] And second, we need to shift our thinking from touchpoints to the journey. So think about how that customer interacts at each stage of their journey, and keeping in mind that services are sequential. And when we can visualize this in a service blueprint, for example, and design those interactions and those experiences at each stage, it's going to help keep us more focused on how customers actually experience that, broader than just a clickable prototype.

[00:17:50] And finally, taking a co-creation approach. We need to design solutions with internal and external stakeholders. And by that I mean the decision makers within the business and members of the target audience, of course. But also, let's not forget about all the people that are involved throughout the process that are required to make that new service a reality, or that'll be affected by the new service.

[00:18:12] So where do you need to break down silos and get in touch with people on the engineering team that are going to be affected by this, or might have insight and knowledge into the systems that'll support it? Who do you need to build relationships with on the finance team, even to understand how do we need the payment processing of this new solution to work, and so on? So keep these three points in mind as you start to consider the experience more holistically, transfer your thinking from touchpoints to journey, and embrace a co-creation approach to the services and experiences that you're designing. And I'll be happy to take some questions now.

Q&A

[00:19:01] Host: Excellent, thank you very much, Justin. Just a reminder to everybody out there, if you do have any questions, please do write them in on whichever platform that you're watching on and we'll pass those questions through to Justin. I loved your example of moving from just building a product. I can't remember the person who said it and it's going to bug me, but she said, "I always have to remind myself I'm not designing a page, I'm designing a process." I always think that that's such a great way of thinking about it, because we fall into the trap of just going, okay, I just need a page here and I need another page. But you always need to be thinking what the user's process is that they're going through.

[00:19:44] Justin: Yeah, exactly. I think a lot of us got into the design field even if we're not strictly visual designers, but what drew us in maybe is because we tend to be very visual people. And so it's really easy to get seduced by the visual deliverable and kind of forget about everything that's behind it and alongside it.

[00:20:03] Host: Yeah, I know I'm guilty of that.

[00:20:06] Justin: Me too, yeah.

[00:20:07] Host: One of the things that you were going through. One of the benefits of saying I'm designing a page is it's nice and neat and it's kind of compact. But once you start considering, okay, everybody who's interacting with this, what's the user doing, the scale of it just keeps expanding. So how do you avoid, what's that example? How do you change a light bulb? First you create the universe, and then you make it. So how do you keep the scope kind of manageable?

[00:20:42] Justin: Yeah, that's a great question, because it can get overwhelming, because you could take it to an infinite extent, right? I think you've got to know where to start and where to stop. So I advocate for two things. One is to take an iterative approach. If this is a new thing for your team or organization, to not try to do too much all at once. To go from the step of mapping the customer journey to starting to add in other layers of what supports the customer journey. Or, there might be many different kinds of services and experiences that your organizations have, and don't try to map everything all at once. Find a place to start and you'll find out what process and what level of scale and scope is feasible for your team.

[00:21:33] Justin: And then the other thing that can be a challenge sometimes is figuring out who all do we, like, we can find millions of people to include in the process. And so, there's a great book that I think it's called Co-design for Real, Beyond Sticky Notes, but I want to say Kelleyan Kurcher[?]. I could be getting her name wrong, but if you Google that combination of words surely you'll find the right result.

[00:22:00] Justin: But she advocates for this approach where, with co-design, you've got this core group, this inner circle of, who are the best representation of the stakeholders and the kinds of experiences that we need to bring into the process. But also to establish your bigger circle of knowing, here are these other perspectives we need to make sure are brought in to inform different elements of the service, but we don't need to demand quite as much of their time. So we can be respectful of how much of people's time we take, but also just to be realistic about how many people can productively be a part of a collaboration like that.

[00:22:49] Host: Great. No, it's a good point. The more people you have, the slower everything tends to go. One of the points on your slide about the frustration of the people who will have to support this. So you don't want to make their jobs harder because they have to support it. But how do you balance the conflict of, it might make the end user's job easier by making the back-end person's job harder? So what is the best way of managing those, because then you might lose the trust of the stakeholder, or the confidence? How do you play that and how do you manage that?

[00:23:31] Justin: Yeah, so I think it's important to emphasize how much the quality of the employee experience actually affects the end customer experience, where a stakeholder within the business might take the perspective of, oh, if we just sacrifice this element of the employee experience, it could be a boon to customer experience. And there's so many studies about, like, our CEO Steve Bruden[?] turned me on to the value service chain[?]. But there's a lot of writing about this, of how that so directly affects the customer experience when employees are unhappy or not empowered or overworked.

[00:24:18] Justin: And all these things that might seem like a good idea on paper, like, let's just give them 20% more, or if we could just move this responsibility over to this department, on paper that would fix so much, right? But without the actual perspective from the employees that are delivering that work. Well, let me say it this way. Contrast that kind of top-down dictated approach with a co-creation approach. We could then learn from the employees, maybe there are ways to actually be more efficient in the work, so that it could cut costs, because maybe management is assuming that all these things need to be done and the employee might know some things that management does not. I will say often knows things that management does not.

[00:25:07] Justin: Where they could know, all right, here are the things that we see making a difference for customers and that are critical to keep things moving forward, but all of our time is taken up with these other things too. It just gives you so much more insight to actually figure out where to prioritize, so that you can not sacrifice the employee experience, because that's going to damage the customer experience inevitably. But you can still find some good middle ground where we're still able to optimize for the business outcomes as well, some of which are sometimes keeping costs in check.

[00:25:42] Host: As you were explaining that, what popped into my head, because I love that answer, but it was the decisions of management. I always think of being on a call and it's like, "We're experiencing higher than usual volume, but your call is very important to us." They're always saying "higher than usual volumes."

[00:26:02] Justin: Yeah, yeah. Somebody the other day I saw say something like, don't tell me that you're experiencing higher than average call volumes. You're always experiencing it. That's not how averages work. It can't always be higher than average.

[00:26:17] Host: Yeah. Now, brilliant, that finishes my questions. I haven't seen, so Kassim, I know that you were commenting before, I'm not seeing any more questions come in, but I think I'll wrap up there. So I just want to thank you once again, Justin, for sharing your insights and knowledge.

[00:26:36] Justin: Yeah, thanks for hosting. Thanks everyone for joining.