 Thank you so much for that warm introduction. I think I'm probably the only person who's not title UX designer in this conference, and it would be interesting to hear different perspective from people who are doing different kind of work. So this is a case study in service design that I'm going to be presenting. I hope it works. I'm not going to go in detail about telling about my journey because she's explained it really well, but it's a case study in service design. I hope you will take something back. If not, I will at least hear a good feedback if you don't agree with the point of view. For those of you who haven't looked me up on LinkedIn, that's a quick snapshot. You might find some of the companies already here. It was nice chatting with some of the old folks yesterday. Currently I work as a lead service designer with ThoughtWorks. For those of you who don't know ThoughtWorks, it's a tech consulting company with some amazingly talented people. They do custom software with some really warm clients. Overall, that's going to be the journey for today's talk. We'll take a pause at about one-third of the presentation. Initially, we would just set up some fundamentals because it will be useful to see what I mean and what you mean and we are all on the same page. So we would talk about what is a service, what is a transformation, and what are some of the pitfalls that you should watch out for in embarking your journey in transformation. Towards the kind of two-third of the presentation is a case study where we have, after working on the project for about two years and it's still ongoing, we have kind of distilled or abstracted some framework that we felt had really worked for us. But with the canvas of the case study, I will deep dive and explain each of those points. And then we would, if I hope time will remain and we will have some question answers. If not, then I am here today. Tomorrow we can catch up for a coffee. All right. So what is a service? This conference is a service. Isn't it? Agree? Right? So usually there are many definitions of a service. This is the one that I like. It's a thing. It's a non-tangible exchange of interactions between a company and various users. Humans could be machines tomorrow, we don't know. Where someone in the context, usually human beings, try to do something. Like we are all here with some agenda or aim objective in mind, right? We want to network, we want to meet people, we want to hire, we want to promote companies, organizer want this to really happen smoothly. So there is always a goal and service is usually a non-tangible thing where there are products which are physical in nature, digital in nature, but it's an interaction between people and those touch points that we call. Agree? Okay. Now, things become interesting. We all have been consuming services. We have been users and consumers. But things become slightly different when we are on the other side of the table where we are not consuming, but we have to design them. And then when art becomes a science, it's important that we dissect and understand, okay, what exactly comprises these services and how do we go about designing them? So I've got a very simple example of a coffee shop, something that is very close to our heart. We have all experienced it just so that we set some basics in place. So when we go to a coffee shop as consumers, what do we do? We look at the menu, we probably talk to the barista if the person is around, we decide what to order, we place an order, we pay and hopefully we enjoy the coffee, right? These are all the things that we as consumers see also in service design language called front stage. Also, user interaction or user experience part of the service. And usually we believe as consumer, that's it. This is all, is a service all about. But is that so? We have good or bad experiences of the service. And the reason why we have good or horrible experiences is things that happen in the backstage behind the scenes. The delay in the talk by 15 minutes is all backstage that we've experienced today. It's not a front stage, right? I was here since 7.30, 7 o'clock probably because of the bun. So what happens in the backstage is there is someone procuring the best quality coffee beans for us, bringing them to the company providing coffee service. There are product, technology, design teams working effortlessly to ensure that those contactless payment works the way they intend to work. There is supply chain logistic, there are also chefs and people crafting amazing recipes so that people come back to the coffee shop, tell their friends that they should all come back or never want to come back and tell their friends that please never visit this coffee shop, right? So what you don't see and what you see, these two worlds needs to align. If they align beautifully, we say that, oh what a fantastic experience taking that flight or enjoying dinner in the restaurant or a holiday or a conference like this. But if they don't align, that's when the problem happens and that's why service designers have a job. Now we are wearing a hat of a designer, we are wearing a hat of a creator and this is a very nice framework and we all know, most of us are designers here, we always say that there are five E's of a journey, et cetera, but experiences are circular in nature. What I just said that when you walk out of this conference tomorrow, you will definitely would have made up your mind whether you want to come back next year. If you would have decided that you would want to come back, you will definitely tell five other people that, hey, this was a fantastic conference, please visit or if you have decided not to come back, you will definitely tell others, never visit a conference like this, agree? So that's how it is circular. We always pass on the bat and it's never a start and an end. Further dissecting and I'm gonna give you an example. How many of you have a water filter? Eureka Phobes or any other? Most of you? You sign a service contract with them and a service technician visit. Now that service technician may or may not be an employee of Eureka Phobes. So in the visible layer, not everyone who's delivering the service in the front stage, that's a front stage. Like you interact with that technician when he comes to repair your or change the cartridges. So when you interact with that person, you don't care as a consumer, but then that person may not be an employee of Eureka Phobes. He or she could be partners, third party contractors, right? But what customers see is they don't care. They think, oh, it's a bad horrible service by Eureka Phobes. So it's also important if you're designing services that you take care of the partners and not forget them. Coming to transformation. Change is really, change is hard, right? But then why do people or companies decide? Most cases, they want to stay relevant. They want to respond to changing needs of the markets and their users. And that's the reason why in spite of it being painful and complex and long haul, they would definitely want to go ahead with transformation. Now, transformations could be of many types. It's a vast, vast topic. It could be business transformation, sales, customer experience. Sometimes they want to change their entire business model. Sometimes, and most of the cases, we are all technology companies here. It's a legacy modernization kind of initiative where they want to change their entire tech ecosystem. Some of the quick reasons why, what's the value? Definitely benefit must be more than the pain. Some of my operations friends will agree that it removes redundancies waste in the process. It helps in increasing efficiency and speed because that's the only way you make money in operations. It improves time to market by building more agile and flexible responsive software ecosystem. It can also anticipate user needs. You know what might come and how what might disrupt them tomorrow. So they might want to change today. Also make a way for newer product services, collaborations. This is all great. But what about the user, humans, who actually are impacted? And I want really to remember the time when core banking started, when analog banking became digital. If you would have any family or friends, it was, there is a lot of anxiety. Yes, their life will become better. They will get smarter, intelligent software to work with, but not to forget that there is always a fear and anxiety because of the unknown. And we, if we are designing a service for them and we also advocate user experience and user research, definitely should not oversee this underline, undercurrents that exist with people. I'm sure all of you must have experience. People fear losing jobs when digitization, digital transformation happens. And those are real fears. Very quickly, it falls when even if we are entering into a project like this, I hope you agree. People think, oh, let's digitize everything. It will solve all the problems. I want to quote head of Deutsche Telecom here. He says that if you digitize a shitty process, you get shitty digital process, right? So that can never be a magic wand that will solve all your problems. So is this attitude or belief with stakeholders that, oh, if you re-skin the goat, the goat will become a tiger. You skin the goat with tiger, it start behaving like a tiger. That never happens. So in the context of user experience, by only changing the UI layer, the underline user experiences, journeys, logic will always remain a problem that will never go away. You would have seen there is a tendency to rush to solutions without even spending enough time in understanding who is this for and what are the problems. Thinking only as technology. With newer and newer technologies coming in, people want to solve problem around the technology and not really other way around and think that, oh, this is the solution for everything. And I know in some of the design colleges that I visit, problem for all solution for all problems is an app. No, it is not. And last two, because such programs are complex and large, it's but natural to start looking for your own self and your own team. It becomes extremely siloed. People lose focus of why are we doing this? What is the North Star for which all of us need to work together? And then it becomes this extremely difficult challenge to solve, anyway solving one challenge and this becomes another. And the last one, remember the user. People need to know that things will change. Why they will change and how they should be prepared. Change management, like management of change should not happen after the change has been done. So bring your users along so they will then become part of the change. I'm just gonna take a pause for a minute to see if you agree, if you have any other thoughts with the things that I shared before we move on to the framework. Any thoughts? Okay, all good, fine. Then, so like I said, this was a real project. It's still ongoing, started two years back. I'm just gonna read them for now and then we'll deep dive into each one of them. Though we put it in some logical order, you can start wherever you want depending on where are you being called in for the project. What is the maturity scale, everything of the project. So first one, establish an effective design operative model, and I know we heard a few discussions around design leadership. I think this is a very valuable point. Remove blinders, zoom in as well as zoom out as and when needed. Leverage cross-functional collaboration to craft solutions, solve problems. Include user-centric methods and metrics. Designers shy away from writing OKRs, not a good practice because designers are the only one who understand user the best. Establish some design governance because if you don't have guardrails and governance, program of such scale with so many teams can easily derail and start working in those silos that we spoke about. Because it's a live project, I have anonymized it, but it's a sales transformation project for a global client. Just to give a quick background, some numbers on right would give you some idea about the scale of this project. On the left, like I said, there could be many transformation initiative. With this company, they started on the path of two transformation. One was on a business side where they wanted to change their sales model. And on the IT side, they wanted to change the entire ecosystem of tech background, which would then respond to the change in the sales model. We were part of the one that's marked in pink, the IT part. But the business processes that you see on right side, 160+, were of a changed sales model. And tech needed to kind of talk to them and understand because that's when, that is what they are promising to their end customers. Two interesting things happened, service design was called in after three years. Like I said, when there is misalignment and a lot of problems, someone in the leadership say, hey, I think there's a discipline called service design, maybe we should try them out. Luckily, it has worked for them, still working. And what's in the middle is also you might have seen when such transformation projects are purely technical in nature, it's very grounds up. They first solution it, the architects sit together and define a solution and then the team is set up. Never ever they would start with what is the user journey the end customer would take or even the employees would take. And that is also result for a lot of fragmentation and problems later on. So what seems like solution becomes a problem later. A quick snapshot, we were operating in the operational world and I strongly believe service design can really do wonders in operations because that is the area, always never paid attention to employees. So sales operations as well as enablers who would then support end customers and retailers. So that was the space. This is what we all felt in almost for a month when we started. Like where and how should we start? It's just, this is this mammoth of a problem. And then we said, okay, understand, let's start by understanding what are the problems that we have at hand. First and foremost, looks obvious, like a user. We're all doing this for users, but no, it was a tech initiated transformation. When we used to ask architects, hey, who is this for? They would look at us like, oh, we'll figure that out later. So there was no clarity on who the user is, what kind of applications they will use, user facing applications, enabler applications, and what are the jobs to be done, tasks that they were trying to fulfill. I won't go in the details of all of them, but I think this was very interesting. We never thought this is the case because you need that for building blueprints that all service designers are expected to build. There was a big disconnect in that front stage and back stage between the business processes and the tech who needs to support that, and rest you all know. The last one is also interesting, you must have experienced this. You get on a call for an hour, you discuss the problem and solution in the same call. By the end of the call, you have a solution without even understanding the problem, you're spending time in it, and that was very common, and then that solution used to become problem few weeks down the line. So the first one, establishing effective design operative model. Oftentimes people ask me why is this a principle or a part of the framework, and I think it's extremely important because if designers need a seat at the table, they need to be invited to write conversation where decisions are made. It's important that where in the program architecture, we position designers or service designers, because service design as a discipline is probably the only one that works beautifully with business and technology. They are actually like the connector with the two. If they are not positioned well, they cannot be effective at all. And you might have seen, you have service designers in the team, the problem is they are not sitting at the right tables where decisions are made, and hence they cannot influence the decisions that business or technology is making. In our context, we were just two of us where all the product team, the tech backend, was split into these verticals with all their product owners and design teams and development teams, but service design was a horizontal function like a central team. We were also tasked or we kind of proposed that we run a design guild so that we have an overview at the same time, kind of a zoom in where we know what's happening into each of the verticals and the teams. So this, I think, is very important because that will set you right in the program. Remove blinders, zoom in and zoom out. It's not unknown, a lot of people know it, but I think what was important in the context of the program is when there was no clarity on the user and the application, we ran two initiatives. We said, let's keep all the journey maps aside and all the things that designers are supposed to do. Let's work with Confluence and Mural. Let's bring people together, ask them, hey, product owners, what are these applications called? How many of them are user-facing? Who are your users? Okay, so that is from the application side. Then after a couple of months, we asked all of the same people that, hey, can you define the business roles? We started off with Persona. It was not really working because of the scale. There are now 60-plus business roles. So we said, okay, let's go with the archetype, kind of a approach, and then we asked them to define so that in the end, they're both merge. Then we have a common source of truth. And we also defined a method by which people will approve them. So if you see on the right side, there are these approval layers. We also did versioning of them so that, again, we used to release versions so that people have single source of truth that, hey, now, at this point in time, there are 23 applications. These are what they are called. These are the users. And say, 50 users, your business roles. Right side is something you know, but oftentimes, Blueprint is like, oh my God, it's so complex, who will use it? Why, how to use it? What we did is we said, hey, this is not the right approach for this program. We said, let's start with the consumers of the Blueprint. Who is it for? Why is this, whether it's a journey map without getting into jargons and the, I would say, academic definitions of these things, we said, who is this for? What will they use it for and how? Because it should be owned by them and it should be useful for them. So sometimes it could be just like a user flow. Sometimes it could be swim lanes, depending on what is it for. But what it did beautifully is it helped them to uncover blind spots because there were things that silos and fragments, they had never seen what's happening on the left or the right of their teams. So it really helped them to, also the top leadership to understand, hey, what might go wrong? What is falling through the crack? And hence, the risk and then I'll come to the next as to what did we do with those blind spot because uncovering is fine, but then what? Another thing, and I'm gonna give you an example of this, very, very, I would say eye opener for the business stakeholders is, in the front stage, when a customer places an order and he or she changes their mind, there is a change log, change in the order, which has an impact on the pricing of that particular product. In the business process front stage, they thought that this is a great idea that if we tell the user that hey, this is what has changed and hence now it's so expensive or cheaper, we should include that as a part of the process when the salesperson or the retailer talks to the customer. Fantastic, but who is going to give them that data? The backend, the ordering team. Ordering team had no clue that something like this has been promised. So ordering team was absolutely never, ever in their backlog, in their prioritization, in their functional team, never considered this as a feature. Now when we did those journey maps and this is one of the blind spot and why these two worlds needs to come together is they said oh my God, this is not considered in the sprint. This will take three more sprints because this is a big technological change and we had to do blah, blah, blah. So then it was a discussion and why this is needed, should business process be changed or the tech backend be okay, whatever they have decided. So these things are important and this is what I meant by de-risking. Imagine if this would have been shipped and what would have been the effect on the service experience? Horrible, right? Third one is cross-functional collaboration to craft solutions. I think service design is best position to build relationships in the program. More important is because there are multiple things that are happening. It's not enough that only the program related people in the transformation need to know. There are so many other functions who need to come together to be able to deliver. If we build a right cadence and right level of connect with all of them, right time, I think it goes a long way and whenever we are coming to a table to find solution and collaborate, it becomes really, really useful. Second one is systems thinking. In this context of the transformation, I think many times people are just blindfolded. They want to only look at what they are tasked to do, but for user, they don't care. They will still be using some legacy systems. They will still be using some spreadsheets. There will still be some left in the middle and right to the transformation. So if we don't understand this bigger system that is at play for the users, we will not consider those handshakes in the new changed world. And then that will definitely create problems later because we would not build for those functionality. We would only think, wow, this nice, shiny world where user's life will transform overnight. And that's what service design forces people to do, think of the older things. They don't discard them. User-centric methods and metrics. I'm gonna, what am I doing on time? I hope I'm okay on time. We all are designers. We know desirability, feasibility, viability, fantastic. Does it work always? No, right? There's always feasibility first, viability first, and then desirability. Most of the cases where there are no designers or design disciplines at work. So those blind spot that I mentioned, we forced them to start with a hypothesis, a user research, not a big bang user research, very small. We also helped them to do it themselves. They'll at least bring in desirability first, then see if it's working, can we solution it with journey maps, ecosystem, understand, come together, then do a viability, feasibility, validation, and then decide, okay, this is what we're gonna do. And these are smaller sections, like which attribute should belong to which team. Simple things like that. But then it needs to be connected to the user journey, saying that, hey, what does user do, and what user needs to see first and second and third? So this, there was lot of resistance initially. Team said, oh, we don't know how our user is. This is enterprise, this is operations. They said, oh, no, no, in the new world, this role is a new one, there is a combination of business role, blah, blah. So we said, no, no, no, it's fine. Let's talk to the old world people, because the work is remains the same. It's not gonna change. You might call it something else tomorrow. But now I see a lot of teams doing it by themselves. So the idea is to also teach them and bring that change in their approach towards solving problems. Or we created the prototype, like a master prototype, because what was also happening is as you go along the program, they are really long haul. We're all, you know, three years, it started two years, we are in so five years plus. People tend to create their own user experiences for their own application. But like I said, for the user, when they look at everything in together, there were a lot of gaps in interaction patterns and ways of working, of the application itself. So we said, okay, let's show those boxes in the Signavio model what they are in real world tech solution. And then again, blind spots disconnect, started to emerge, and they could then fix them right time. User metrics, like I said, designers shy away from these methods. Okay, ours, they always want business teams to write them, but then the user point of view is never considered. So we said, can we at least try this framework where we say, okay, in order for XYZ business role to do this, can we start with that? So that at least that thinking from user point of view seeps into the organization and the people who are crafting these metrics. Last one, guardrails are again important only because of the scale of the program and so many teams, again, multi-vendor. It's not just one vendor. Even in single vendor, different humans have different and designers definitely have a very, very strong point of view and approach to things. So it's important that we all agree as to what are the guardrails that we would adhere to. So we crafted some service design principles because it helped them in decision making, at least they remain consistent because what was happening is one business role would use more than one application. Then it was hard for people to identify which one is the primary, secondary, tertiary where they have only read access, write access, et cetera. So this helped them to at least take decisions better. Language style guide, usually it's UX writer's job but we did that at a very high level because we felt the messaging, the language was also very, very distracting as well as very, very different for each application. Okay. I would say the biggest takeaway for me in this project was de-risking. I think we all, everyone wants to deal well in advance. So really surfacing those blind spots, changing the mindset was the biggest takeaway. The program is still ongoing. We are moving on to doing design operations and research operations because now the right set of approaches have been set. Now we want them to kind of go and do a lot of usability testing, user testing themselves. So we have taken a backseat of operationalizing those researches for them. So that's where we are in the process now and this brings us to my last slide that it's never done because people change, services change all the time and with this question answers if you have any. Thank you. Thank you. My name is Kama. Hi. Thank you for the presentation. I have two questions. First one is on, can you hear me? Yeah. Yeah, okay. Right. So the first one is on what is the typical trigger because for a service design project, right? Because you're investing resources in a business. You're involving a lot of people. A lot of time is being spent on these projects. And yes, in the course of the service design project you will uncover a lot of problem areas. But I'm curious on from a business point of view what would make someone quote unquote sanction such a project, right? To invest in such a project. So that's one part. Okay. Should I answer that first? Yeah, sure, sure. I think there could be many triggers. Standard trigger is if you look at the metrics that they receive from their customer experience, touch point where you call centers. And if that is high and everyone is trying to reduce human humans in the call centers these days. So that is usually first connect. And most common in a B2C kind of a setup is what I have seen. But at the same time when they had to, when it's a heavily operational kind of business that they are in and they need all of that to work in tandem. Like I'll give you an example from banking. It's very easy for people to say, hey, your mortgage will be sanctioned in like a week's time. But there are so many things under writers and there are teams and partners that need to work together. Is it even possible? So that when it fails, they would want to then bring in service design because they know that this is something that they don't have control on. And people need to look at both the worlds. I'm also touching a bit on the educational aspect of it or the awareness aspect of it. So how did they know that a service designer can help in this situation? From a business leader's point of view. Can you elaborate? For example, if in the example that they gave about this banking service, if they're seeing that, oh, we're getting a lot of customer complaints and we are basically not able to handle all the complaints with human beings that we have on customer support team. For me, like I'm just trying to kind of look at it from a very layman point of view. I would say, oh, we need more customer service people. And that's typically how a business leader would think like, oh, the solution is right there, right? Maybe I can't afford to hire more customer service people. Or then let's invest in automation too, right? So usually those are the kind of thinking trains, train of thoughts that pop up. At what point would they say, oh, a service design or a revamp of the whole service can help in this situation or a specialist service designer can actually contribute here to bring value? What I've seen in my experience is a sponsor or very senior stakeholder. Either that person would have had some experience working with or know what this discipline does. I've seen them advocating service design more. But unfortunately, people who have no, they don't know what service design can do have to go a hard way of failing and really, I don't see any other way. But now I think the awareness is increasing. In the Europe, at least in government sector, there is lot of value service design can bring. Also, if unfortunately businesses that are hardcore in service have now started to see value of service design, like banking, for example, is a service. It's not a product company. Now they have hired and we see J.P. Morgan so many designers out there. So I think they're seeing the value now. Also, each discipline has its maturity level. And design in finance has always been late comer. So that is there. Also, I don't know, hospitality and other industries which are highly service industries think that humans can do the job. Front stage staff can do the job. And it's not so complex in the back end. So that's when these things happen. But I think a sponsor, a stakeholder who's aware and understands is extremely important. If you don't have a sponsor and if you're not positioned well, it's hard. Yeah, I can understand. And to the second part, sorry if I'm taking too long. Again, in the same sort of umbrella, right? So for a business, they always look for like short term sort of efforts, right? And from what I saw in your presentation, it was like a multi month project. Did you face any particular challenge when you're asked, okay, can we do this shorter? Or is there any way in your experience to even make it? Is there like a short version of say a full-fledged service design project in a way? Yeah, not in this. Luckily, we have a client and a sponsor who understands it takes that long. And also it's a transformation program is running for that long. But yeah, I have experienced these things. What had worked is not really remain not really locked into this definition of service design where we say, hey, we need to do this full-fledged blueprint and et cetera, but start small and start with whatever you know. And I think it's important that we show them what is missing because once you see, you cannot unsee. That's the beauty of service design. If they see, they will definitely come back. Your job is to kind of keep showing them what doesn't exist. Like the initial threshold if they cross, right? Then it makes it much easier. Thank you.