Building Bridges: The Service Blueprint Design System Integrating Design, Business Strategy, and Development

Kate Mlynarczyk, Jung-Soo Choi at UXDX Community: Tech Leadership Essentials: From API Mastery to Team Dynamics. Video: https://youtu.be/HH9jZcbz8fo

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.

Introductions: Equinix and the employee experience design team

[00:00:00] Kate: Hello everyone. As our topic was presented, we'll try today to show you the bridge between design, business strategy and development through service blueprint operations. I would start with a couple of little introductions. At first, if you know Equinix: Equinix is the world's digital infrastructure company that we work in. Maybe you have even seen one of the 260 data centers that we are building, located in over 70 metros around the world. So we're actually creating these interconnections. And what is really important: we have over 13,000 employees globally.

[00:00:54] I emphasize employees because, for us, a really important thing is the second introduction, about our team, the EXD team, which is employee experience design. This is what Jung-Soo and I are doing with part of our team here in the photo, so may I send greetings to them. Our purpose, as we stated with our leader, is that we are multidisciplinary designers who are stewards of the employee experience. Of course we are working on different data, and we are working for customers, but our really important mission is: if we take care of the employees, they will take care of the customers. That's why we are trying to develop our mission with an employee experience emphasis.

[00:01:42] And what is really important: we are working in pairs, trying to build this culture of pairing. A pair is a service designer and a UX designer. Today Jung-Soo and I are here as service designers, and we'll be sharing with you some lessons learned from creating service blueprint operations. Me myself, I'm Kate. I'm based in Poland, working with our EXD team, building a service design team, with some experience in service design so far, trainings and facilitation. And there is Jung-Soo here. Your turn to say hello to everyone.

[00:02:23] Jung-Soo: Hi, my name is Jung-Soo Choi. I'm a senior service designer with the EXD team as well at Equinix. I have previous experience in innovation-focused experience design at different companies. Nice to meet you all.

Forty years of the service blueprint

[00:02:37] Kate: We will come back to Jung-Soo, of course. But at first I want to start with a date, and this date is actually a birth date, the birth date of the service blueprint. The service blueprint is having an anniversary this year: 40 years of the very first service blueprint, which was created by Lynn Shostack 40 years ago and was published in Harvard Business Review. I dived into the story of Google data [?], and you can find the article, "Designing Services That Deliver", in our materials as well. Some of the structure of the blueprint is still valid, but let us think about some changes for the operations that happened.

[00:03:36] One thing that changed, from the structure of the blueprint, is definitely the amount of accessible data that we as UX and service designers are working with. Think about dozens of interviews, hundreds of data points, and many iterations with the persona cards, and it's all coming to the final thing, which is the service blueprint that we are all looking for. But sometimes it's many months of doing the work, pairing with the UX designer, doing research, and finally having something which we need to share out somehow. And it's not so easy, and it's challenging.

[00:04:17] Why are we talking about the service blueprint, apart from the anniversary fact? From the perspective of the UX designers we are constantly working and talking with, the service blueprint is something that can be a really good context for sprint discussions, and for some decisions with product owners and business owners, because sometimes you really need some proof, some evidence to show. And also, based on the evidence that is needed for the business teams and analytics teams, most often a service blueprint can show, and this is actually one of its goals, the inefficiencies within the processes, the gaps and approvals along the journey.

[00:05:03] And the last thing is the quote, the sentence: just before we sketch anything, before we mock up anything, let's first understand and validate the context, and have something to refer to. This is one of the most important things about the service blueprint. From the UX perspective, we won't be going through the whole structure of the service blueprint in this specific presentation, but of course we will be sharing how we have done the current version that we are working on.

[00:05:38] But coming back to the past for a little: from this 1984 structure, something needed to be aligned or adjusted for what we have now, in the era of lots of data and products and processes. It's about not having a service blueprint only for services, but also for the processes and the product experience along a given persona journey and the whole stakeholder ecosystem. To that end, the service blueprint components, or layers, all of the elements, somehow needed to be changed. Now, to make it more concrete, in the second chapter of today's presentation I will turn it over to Jung-Soo, and he will tell you more about service blueprint operations, our team's iterative process, and, last but not least, a timeline framework that we want to offer to you. Jung-Soo, it's your stage now for chapter two.

Three challenges of service blueprint operations

[00:06:47] Jung-Soo: All right, I hope you can all hear me. I think there are some video issues; I think I'm frozen on the screen. Kate, you can't see me because you're sharing, but right now I'm frozen. There are three major challenges with service blueprint operations. The first one is having the right level of detail: showing only what is really important for the viewer, the right audience. The second is operations versus communications. When you're in the internal team, there are a lot of things you can utilize to work and collaborate, but what do you actually communicate outside of the team? I think that is really important, and it's one of the biggest challenges. And last but not least, we have current versus future. There's always the question about what we show: are we showing the current state or the future state? I think it is important to show both. You want to show the difference that you're making from the current state to the future, to show the improvements and metrics.

[00:07:44] This is a capture from one of our workshops. You can see that there are a lot of stickies, a lot of data, a lot of input that we're gathering from the collaborative cross-functional team. What you typically have in internal operations are these walls. You have war rooms with lots of data, lots of stickies, lots of information. This is one of the images I actually got from the internet, from Emerge [?], so this is not our image, but this is typically how service blueprint operations will start.

[00:08:18] Thanks to digital tools like Miro and Mural, which are really great collaborative tools, you can synthesize and digitize a lot of the content. All the stickies that you've seen on the walls will be synthesized or digitized in this manner, and this is really great for teams working remotely. But still, in this format in Mural, this is in no way shareable to any stakeholders or outside parties.

From war room walls to a moments-focused blueprint

[00:08:46] What we have done is create shareable content. When we have a service blueprint, we convert it in Figma to create a prototype which can be shared easily with different stakeholders. You can see that we have different components already built in a design system, so that this is easily manageable, easily editable by different parties.

[00:09:09] But we noticed that even that level was too granular, too detailed. What we have created now, the latest version of our service blueprint, shows just the high levels, and we're focusing on the moments. Typically in a service blueprint you have all the actions and steps captured, and the front stage and backstage of what's happening in the organization, but here we're focusing only on the critical moments.

[00:09:34] This blueprint is actually a step towards development. When you have this blueprint focusing on the moments, you have the key interview artifacts, you have site maps [?], you have the vision and moments captured, and this actually shows a sort of roadmap to prioritization.

[00:09:57] I think this is really critical to how we partner with UX in service design. You can see that the first diamond here is very much on the service designers, where we are tasked with doing the discovery, focusing, honing in on the vision. The second part, with the product design, is how you work as partners with the service blueprint. But the service blueprint eventually will be a single source of truth, where you have this roadmap and the important moments captured.

[00:10:30] So how might we overcome these challenges? I think by having the right tools, and showing the right level of detail to the respective party, whoever is watching, the right audience. But also capturing the right moments and having some sort of format for validation.

Blueprint share-outs and current versus future state

[00:10:49] Kate: Okay, so I will take it from here, and I will talk with you about something which is also a lesson from our side, which we named the blueprint share-outs. The share-out for the blueprint is something that we are all wishing for. Actually, maybe we as UX and service designers are not wishing for this share-out, but others are wishing us to do it from the very beginning. From our different engagements, and recently, in the last months, I can say that there were three major service blueprint processes that we ran within our team. All of them were different, of course, from the perspective of the structure, or the goal, or the design that happened after. But there was something common, and it was the challenges with the share-outs for the blueprint: when exactly to share it out, who to share it with, and how to approach that.

[00:12:01] You can think about three scenarios. One final share-out: working only internally for many weeks, sometimes months, on one blueprint artifact, and then sharing it out at the final stage. Good, but you can answer for yourself. From our perspective, it could mean not having space for validation during the whole journey of creating the blueprint, which is not a good thing, because then you have only a 50% chance, or even less, that the leadership or executives will be really happy with the service blueprint. Big broad share-out: in many cases this scenario is mostly to impress, or to show the final artifact.

[00:12:53] But the first scenario is something that we are wishing for and working on in our team: regular design program updates. Creating a culture of validation, something like a council [?] for the service blueprint, with the other teams involved in the process during the workshops, during the research, during the understanding of the most important major changes within the blueprint. These share-outs are really important from the perspective of whether the service blueprint will be in use or whether it will end up on a shelf.

[00:13:31] Another lesson is something that Jung-Soo already mentioned, and it's about current state versus future state. This is something where we also have a lot of challenges. You can imagine this story, and I have been hearing it for many years: just skip the current state. We already have the documentation, we already have lots of documentation and data inside, we know how the current state is working, so let's just focus on and jump to the future. Which means that we are most possibly missing the pain points, missing the inefficiencies, missing the processes and waste cycles inside, by thinking only about something that is solution-based, in the solution area.

[00:14:25] So how might we show the future design based on the current state? We can tell you that one of the possible ideas for that is phasing [?], and this is the idea of our team recently: of course mapping the current state, but then having a tomorrow vision, which is the next quarter, maybe the next months, and then also having the north star, which is the future. But the future is based on pain points, it's based on the data and all of the things that we compared to the current state and the tomorrow vision. This is a potential opportunity to really answer this question about keeping the current state. And for chapter three, which is the last chapter: a truth about the service blueprint. Jung-Soo, I'm putting it to you for the last minutes.

A living document, not a static artifact

[00:15:18] Jung-Soo: Thanks, Kate. In the last part, we want to talk about the difference between a waterfall and an agile environment. I know a lot of companies say that they're working in agile, but a lot of it looks like this: you're going from idea to business case to roadmap, and at some point you have design, and then design goes through to development, which is build, test and deploy. And what happens with service design and the service blueprint is that it becomes an artifact that's very static, and it stays as a document of record, but it doesn't really get used.

[00:15:53] What you want in this agile environment is to have the service blueprint as a living document. There should be continuous circular feedback, and the service blueprint should evolve as the project and the data that you're gathering evolve. It should be continuously moving, as a living document.

[00:16:15] Kate: And for that matter, if you would like to connect with us on more details, you can start with this process, which is based on our experiences. It involves not only a process checklist: the main team, not only service designers and UX designers, but also the supporters and the collaboration with other teams from the organization, which is really critical for the process. Making a data inventory: making sure that you have all of the current data. In big organizations, it's really a big challenge to get to know all of the sources, but also make sure that you create the inventory along the way of creating the service blueprint. Of course, a communication plan with the share-outs, and the goal and the use of this blueprint, to eventually make the service blueprint valuable and in use. And the last thing is the updates and readouts. They bring us back to the loop: the work on service blueprint operations is something that cannot stop, as with the design process in many cases.

Key takeaways

[00:17:31] For the ending, we have some key takeaways, from the perspective of arguments for UX being involved in service blueprint operations, and I will go through all of them. The inefficiencies shown up on the map: this is something that you can really use from the service blueprint, as well as the opportunities that you can find, if the service blueprint is well created. Another thing is that it can give you proofs, evidence and arguments for product, business and IT owners. In our case, for example, life cycle times and waste cycle times equip us and UX with an artifact which supports the decisions and supports the recommendations. Sometimes we really need that apart from only the design.

[00:18:28] Another thing is that it's an effective way to build alignment on the experience. Yes, the blueprint share-outs, but also working on the blueprint during, for example, workshops. This is a way to align everybody on the really important things, which are shown at scale and in one source. And last but not least, the service blueprint operations approach: as Jung-Soo mentioned, this is not an artifact. We cannot work on a service blueprint in only one of the phases of the design process and then just go further. This is not a one-stop discovery artifact; it's an approach to working on services, processes and product development. That's all for today. Thank you for listening, and we're open to questions, here or somewhere else, on LinkedIn and other channels.

Q&A

[00:19:25] Host: Yes, absolutely, thank you so much for that. We have a few questions that have come in, lots of different types of questions, and it's clear that this has caused a lot of pain for a lot of people with regards to project planning. The first one I'd like to break down is: how frequently should you update your blueprint? I guess that's coming from the fact that you did a few updates. What did that look like for you, or how much is too much?

[00:19:59] Jung-Soo: I think as frequently as new information, new data, is gathered. Business is always changing, goals are always shifting, there's transformation. So again, if it's a true living document, it should be updated frequently: if you have a new interview, if you have new data sources, it should be updated.

[00:20:19] Host: I love that. "Living document" kind of answers the question.

[00:20:24] Kate: I can build on that with an additional sentence. It really depends on the data, as Jung-Soo also mentioned, but it would be nice to have a standard, for example once every two or three months, with a coordinator of the service blueprint, for example a service designer or UX designer inside the company, and to have this kind of regularity and frequency as a standard. Of course, that's if the product or the software or the process is a living process, but normally it is in today's world.

[00:21:00] Host: Yeah, fantastic. And how do you get all stakeholders involved? You talked about the main team. How many is too many people?

[00:21:15] Jung-Soo: Typically we start off with an alignment workshop. In a typical workshop you want to have all the cross-functional stakeholders, but you don't want to have everybody in the room. So I think a dozen or less. We typically have a workshop with about nine or so individuals, maybe 12, but representing desirability, viability and feasibility. If you have all those represented, that's a perfect team to start.

[00:21:41] Host: Fantastic. And how much can Miro or Mural, whichever people might use, link with other tools? You've talked about making it a living document. How have you, or how would you suggest people, make it a living document where updates are almost automated, so that it doesn't become too manually intensive to update? Do you use anything, for example Airtable, Asana, Teams?

[00:22:14] Jung-Soo: One of the examples that we shared: we actually converted all the content that we had in Mural into Figma. We built it in Figma, and there was a design system and components, so that it can be updated just by copying and pasting into FigJam, and that in turn will show up in the Figma prototype.

[00:22:33] Host: Okay, great, fantastic. That is all of the questions. Shri has said hi to you, Kate, good to see you. Thank you so much, both. That was really, really great, and your presentation will be live next week for everybody. Thank you for joining us.

[00:22:52] Kate: Thank you for inviting us.

[00:22:56] Jung-Soo: Thank you for having us.