 In this episode, you're going to learn how to create the conditions within an organization where service design can thrive. Even if that organization is traditional, regulated, and not very open to change. Here's the guest for this episode. Let the show begin. Hi, this is Angela, and this is a service design show, episode 111. Hi, I'm Marc, and welcome to the service design show. This show is all about empowering you with the most effective skills and strategies so you can design services that win the hearts of people and business. And the guest in this episode is someone who's definitely been doing that. The guest is Angela Obias-Tuban. Angela currently works in one of the largest banks of the Philippines, and in this episode, they're going to explore what it takes to embed a design way of working in a tough context like a bank. Some of the things you'll hear in this episode are how you can use design research to actually better understand the people around you and the things they need so you can tailor the offering you have to that and how something like quarterly reflections can help you to shape a design culture. So at the end of this episode, you'll walk away with some very practical advice that will help you to embed service design in basically any organization, even if it's as tough as a bank. If you're new to this channel, welcome and make sure you click that subscribe button because we bring a new video to help you level up your service design skills at least once a week. And I know that a lot of new people are coming here, so don't forget to click that subscribe and that bell icon. For now, sit back, relax and enjoy the conversation with Angela. Welcome to the show, Angela. Hi, Marc. Really nice to have you on. Again, somebody finally from a part of the world where it's really hard to find a lot of service designers. I'm sure there are many, but yeah, once again, I'm happy to have found you through Lauren in this case. Angela, so I gave a hint like you're in a part of the world, which is not the US. It's not Europe. Where are you? What do you do? Yeah, so I'm speaking to you from Metro Manila in the Philippines. So it's in Southeast Asia. Yeah. And what I do is I'm officially called a design strategy lead, which essentially means I oversee user research and analytics and also in part of planning for digital products and services for one of the Philippines' largest banks, Metro Bank. Again, a bank, just as Lauren said. Yeah, we are getting into the financial institutions in the latest last few episodes, but it's an interesting field. Angela, I haven't prepared you for this set of questions, but the people who are listening to the podcast now, what's coming by now is going to be a 60 second rapid fire. And just answer as quickly as you can. OK, OK, OK, OK. So first question, what's always in your fridge? Milk. OK, a lot of soy milk. OK, OK. Which books are you reading, if any? Right now, I'm brushing up on the field study handbook by Jan Chipsi. Yes, legendary. Which superpower would you like to have? Oh, my God, probably flying. I think I would like to get out of traffic. Maybe, you know, maybe one day. What did you want to become when you were a kid? Oh, I wanted to be a business person. I felt like my mom was a business person, so I wanted to be like her. I didn't even know what she did. She was just a business person. Yeah, you wanted to be like your mom, which is always a good ambition. A final question. What is your first memory of service design? My first memory of service design. Oh, um, um, probably an ideal video. I'm fairly sure it would have been an ideal video talking about service prototyping and trying to build. Like a rough prototype, maybe with boxes and trying to prototype a service. Yeah, uh, good idea has done a lot of good work for our field. So I'm not surprised I haven't had anyone from IDO on the show yet. Somehow, not sure how that happened, but maybe we need to, we need to change it. So the theme of this episode is going to be something related to how to design services that are useful, that work in an environment, which has a lot of traditions, regulations, heritage, so not the most easy environment to really practice service design and thrive as a designer. And I think you'll be able to shed some light on how you're dealing in that situation and, um, and give us some insights on how to create useful services. Right? Yeah, I hope so. I hope so. I'm sure we'll be, um, we'll get to some point, but when we were discussing this episode, um, you told me that this is a topic which is there to your heart. And I, I really liked, um, why that was. Can you give us a little bit of background, like, what is your first memory of background, like, why did you get into this and why is this important to you? Yeah, um, so I really started out my working life as a market research person. And through that job, I was able to see the power of listening to users and customers and listening to their needs, um, and trying to apply that to improve businesses and marketing, because that's mostly what market research deals with. It's mostly about advertising and brand, um, you know, product placement, packaging, but then, um, there was a particular point in my life. At that time, I was working for a media conglomerate and I was probably of over a decade ago here, like here in the Philippines and around 2009 and with, uh, I don't know if you want to, it's not fine. That's fine. Yeah. Okay. So in around 2009, I think that was the time that Facebook and like and video streaming was starting to become popular here in the Philippines. And we were doing focus groups to understand how people were handling that. And I was thinking, you know, I could witness that people couldn't remember what they were watching or they couldn't relate what they were doing on Facebook, for example, or on social media or in digital platforms in a, in a focus group setting, I feel like you had to watch them do it. So I was trying to pretty much influence our team to do more behavioral research. And that's, that's one part of it. It was trying to understand that, oh, look, when, when you are actually trying to plan and understand interactive services or interactive platforms, doing the classic, you know, survey or focus group doesn't really apply anymore. So I started reading up about all of those things. And that's how I started discovering, you know, ideal and all of the writing on it. And aside from that, not just ideal, but also again, as I mentioned earlier, Jan Chipchase who, who was doing a lot of work then with, with mobile phones and eventually mobile wallets. So that's, that's one of the things that sort of got me into, into that. And then the other thing that sort of pushed me, I think into this direction was so after having realized that, we were trying to help the company plan. And it really wasn't just, you know, when people start, when, when companies, very traditional companies start realizing that things are changing, they don't necessarily know how to adapt. And it's not just an adaptation of the actual thing that they're delivering. It's actually the whole operating model and the whole business model that they have to look into. And that's when I realized that even as a research person, I could only surface the insights. But I was always so frustrated about the solutioning. And then what I, what I realized from all of the ideal and all of the, you know, all of the design sort of, what was that, what was the trendy term for it before? I think before it was so interaction design. It wasn't even, it wasn't even UX yet in the olden days. And there's like human factors. They were more embedded in the planning teams. They were more embedded in the ideation work. So that's where I wanted to be. I wanted to be, I realized that I will always be frustrated, no matter how much I understand people, if I'm not actually part of the planning and design. And that's how I jumped ship into sort of a design discipline. Yeah, totally. And I think that's a big frustration, even if you're in the ideation stage and prototyping stage, that ultimately we want to impact the lives of people. We want to impact businesses. And that's also what I liked about your background story that you said, we need better services. Like a lot of services are broken, right? And that's what I got from your story so far, that's the thing that drives you deep down. Yeah, because at that time, again, having come from research, there was this one project I even had which was this whole year of focus groups trying to understand the Filipino, trying to understand people in our country and what they need and what they're looking for. And then you can see that it was so difficult for businesses to sort of plan what to do next or what to do with that information. So I realized I wanted to be part of shaping that. I wanted to be, I have this personal mission. It used to be, I think on my website, this is not up anymore, but that I really wanted to just create better products and services for people in our country. Because a lot of the services here in our country, like that's to say transport, we have some of the worst traffic I think in the world. We have very little public transportation. So just that's just a sample, but then it trickles down to a lot of things that the people in our country, because we are an emerging market, have just accepted to be, you know, to be, yeah, we just accepted that to be reality, but, you know, things could be better. And that's the thing I hope that is driving a lot of the people who are watching or listening these episodes that's somewhere deep down. We just feel an obligation to the rest of the people around us that we need to create a world where there is less frustration about services, where services are more consistent, reliable. Yeah, so I think a lot of people should be able to relate to your story. And I haven't been to the Philippines, but I can imagine that the challenges around services there are a different than over here in the Netherlands, for instance, but still deep down, I think we share the same passion. Now, you're working right now in an environment which has a long heritage. Let's keep it at that. What have you identified as some of the things that are holding us back from not being able to deliver on those services that we would like to deliver on? So have you, maybe not just in the bank, but in the systems around us in general? One of the things is, I think, you know, the world, as you mentioned, many people who are probably watching this series already care about wanting to improve services. And I think the world doesn't lack people who mean well, people who want to do better by other people. But the problem is really literacy, or at least in my experience, that's one of the things. And there's a lack of practical advice, because in the recent years, you know, design, like capital D, capital D design and design thinking has been quite popular. And I think that's also why, you know, many of us have, have roped now in large corporations, because there has been a big uptake about the value of design. However, not a lot of people are well versed in terms of applying it in an operational way. People understand the theory behind it, and people understand the value, at least in what I've seen. But actually applying it is the challenge. And as you mentioned, especially if I work in a company with a quite a long standing heritage, it already has a built in culture and a way of working. So that's really part of the challenge of doing it. Yeah, so sometimes misconceptions about design, sometimes just not knowing how to translate this into practice, forms of existing ways of working, which fight against new ways of working, right? Are there any other things that you feel are sort of holding, yeah, holding us back or holding the current existing nonworking systems in place? Yeah, so as I started to mention, of course, there's inertia. There's just the way that things are. And this applies to, I think many, I mean, many teams that I've seen, not just necessarily where I'm currently working at, but, you know, as I mentioned in my example earlier, the common thinking is if it broke, don't fix it. So if the business seems okay, or if the products seem okay, then there isn't much of a push to change how people are doing things. And, yeah, again, I started out in research and analytics or research and analysis, and I'm very big on metrics and measures. And one of the challenges that I've seen is that it's also a reshaping of what's the business values and is trying to measure. Because what happens is, if you really follow LitVay, so LitVay and my older corporation, like let's say on TV, on TV or like for TV businesses, the only thing that matters are ratings. So it's all about, the business is all about trying to suck in people to watch TV so that the advertising model runs. But, you know, because of the onset of LitVay digital platforms or, you know, the change in the notion of ownership, like I don't have to own a TV anymore. I don't have to own a DVD. How does that then change your business? Because the business, as it exists, has always been optimized for that measure and not for the new things that have happened. So for me, that's one of the things. It's people getting stuck in a way of working that is actually meant for something that is much older, for let's say a world that is much older. And I think that especially now with the quarantine and the pandemic, that's really surfaced that. It's really challenged how businesses run because now all of a sudden, like every single business in the world had to think, well, I mean, other than those that are already online, every single business had to think of reframing or reshaping how they work. So that's one of the things I think that is also the problem. Yeah, and I think you hit an interesting point. There are like measurements and measuring that has been a topic on the show often. And what gets measured gets done. And as long as we keep focusing on things that might have become less relevant and still keep optimizing our services and organizations around those outcomes, then it's really hard to change that. I think it's also really challenging to bring in new reliable metrics that are accepted by organizations. But yeah, I think that's one of the assignments that we have as a community to educate the people who are in the positions within organizations to start considering other measures. And I think if I can add, I think the metrics around services are quite difficult because some of them are qualitative. That's one of the challenges that I've seen in my work, that sometimes the way that you measure the value of the service, it takes a bit of processing because there's always, of course, time. There's time, there's cost. Those are the more basic things. But that's a pain point that people have along or across how they use the service that's not always easily measured. People can sometimes measure it by severity or the lack of severity or lack of severe problems. But it doesn't always accurately capture what you're trying to design for. There's a different way of measuring success around service-oriented businesses than around product-oriented businesses. I'm curious in your experience from the last few years, have you what have you done to overcome some of these challenges like inertial, like this measurement challenge or like there are misconceptions around service, around design in general. Can you share a few stories with us? Sure. They're not always pretty. A lot of them are things that I learned because I didn't do them properly the first time. Exactly. Which are the best stories? Yeah. Okay. So, for me, one of the things that I think I had to learn, so actually prior to joining, prior to joining the bank, the bank that I'm working at, Metro Bank, I was prior to do independent consulting and I actually worked with a lot of startups. So prior to that, I was very much used to a culture where I was primarily working with engineers and designers on a day-to-day basis. And then one of the challenges that I prepared for coming into the bank was being in an environment where not everybody is quite, let's say, equipped with a type of information that they would need to actually do the things that they wanted to do. A lot of people. Like what? Yeah. So one of the things, for example, is MVP. Just the concept of, oh, I don't want to talk about this, the concept of agile or agility and being lean because you write like a lot of, you know, even in service design, a lot of the design disciplines, it's all about prototyping and trying to get something out into the world to learn. And that is very hard for people who have worked in environments where you really have to push a polished thing out into the world or a polished, let's say, service. You can't really, like for example, one of the challenges of a bank is that, you know, it has a whole branch network and you can't, you know, they don't normally roll out a half-baked thing or a purposefully half-baked thing or they don't roll out anything to, let's say, just a handful of customers because the planning is usually quite broad. So one example is, there are so many, but one example is we've tried to get them into certain frameworks and one of the things that I think I had to learn was repetition. It doesn't, it's, you know, that's this whole old marketing or advertising thing like repetition, repetition, repetition. We work in, we work in the field where we design behavior and I guess I had forgotten that you can't just say or, you know, you can't just announce something and then expect people to run with it. You really have to, you really have to equip them and help them operationalize what they want to do or what you want them to do. So one of the challenges, for example, let's say something simple like testing, testing a prototype. I realized, you know, people want to do prototype testing, but it isn't enough that you do a walkthrough. So I started with doing a walkthrough with everybody. I would have a walkthrough with everyone who was part of, who would be part of watching the prototype test, but then I realized after the first run that they were so used to market research because in market research, everyone who was an observer really literally just watches. And they're not really part of it. They're not engaged. So I had to do a second run of walkthrough where I already demanded that we do a practice run and then also that every single person has a role. So that way we also controlled the number of people attending prototype testing and they also needed to be an active participant. So you can't just go to, you know, you can't just go and then expect that you can just sit at the back somewhere and then expect the research to run. We have to really be part of it. So that was one of the things. But with that, we also needed to have templates. Well, yeah, I think just to touch upon what you are saying, a lot of our work is also empathizing with the people we are working with and trying to understand from their perspective on what we're doing and their environment, like what's going on, what are their monthly or quarterly targets and coming from that position translates that into our design process. I think that's one of the most common mistakes I'm seeing designers and service designers make is just slap on the design process until every challenge they see and be super user focused. But forget the people who need to help you and you need to collaborate with to actually make this work. So there is, I hope it's changing, but it feels like you're also saying the same thing, right? Empathy for the people, not just for the end users, but the people who you're working with. I agree with that because one of the things that I actually tried and am learning is that the design work that we do happens in various levels. So there's the organizational level that we're trying to design, which is as you mentioned, it's about empathizing with the people that are also trying to make this happen because you want them to be able to do it. You want them to be able to also apply it to their own goals because it's not just, let's say, it's not just my job to understand customers and then apply it into my work. It's actually everybody's job and everyone has to be part of it. So there's the cultural and organizational layers and then there's also helping them understand the process of it, like actually how to do it. So I've done various things for those levels. Like for example, for the cultural layer, I can give, I have two very specific things that I think have worked for me. One, so the broadest thing that I can think of is I actually made, I made a people framework for our team. And this is a lot of people I know are not found to force-track. And I'm not saying that we should all force-track, but what I've learned to do, and this comes from my job as a research person as a qualitative researcher, is the force-track can sometimes help you surface if your people metrics are actually incentivizing the correct behavior. Yeah, I need that example. What do you mean? Okay, so for example, what you can do, I've done this in the various teams that I've joined, that are really engaging the different managers and to ask them to rank their team from their most valuable to the least. But that's not the importance. The ranking is important. And actually, a lot of managers usually refuse to give me an answer, but I try to tell them that I don't care about the rank. What I care about is their reasons behind it. Yes. So I try to ask them about each of the reasons why one person is better than the other. And we surface that to make a performance assessment framework. So for example, for engineers, I think he's the most straightforward. So for engineers, one of the managers said he values one person over another. And then when I asked him why, he said, oh, because although one of them is amazing at math, which is critical for code, the other person, which he ranked higher, had cleaner code and was a better team player, he was able to have such well organized documentation of how he worked, that he was also a good senior to other people, which was more valuable to him than someone who could just, you know, brute force, and crunch a lot of numbers to sort of do a lot of things. So having said that though, it really goes to show what the manager values in a team. And if you take that example, and then you apply it to the various disciplines that make up a team that designs a service, hopefully, you know, you can end up coming, you can end up with a framework that captures what you value as an organization. So for example, in our team, we always say that we value scrappiness, because we even if you work in a bank, we want to be able to still take lean. We're very inspired by the whole lean startup methodology, where it's, you know, you try to ship something fast, and then you learn, and then you apply. We're trying to replicate that, but within a very structured, it within a very structured and rigid environment, and we have some progress. But, you know, we had to, I had to take that scrappiness and see how does that, how is that sort of, how is that translated into behavior. So for the different members of our team, who is actually scrappier than another. So that's one of the things that sort of helped, helped me communicate to the other managers that I worked with about what type of behavior we should incentivize in our team, and what type of behavior we really are looking for. So that's one of the things on a broad cultural level that has worked for me. And that's interesting because you're applying basically design research onto the internal process. Yeah, but not so much on the end users, but on the people. Yeah, and that's quite interesting because you're taking somebody like a manager as a sort of the end user or consumer of this information. And then you're doing, using design research, the things that we know and do to surface the type of information that will help decision makers make more informed, embedded decisions that help to create, well, yeah, to improve team performance. Yeah, things they value. Because it really is about, as you mentioned earlier, it really is about shaping, you know, the work that we do, you know, service design is really about shaping people's interactions. And usually, you know, it isn't, I mean, I work in a field where it's kind of focused on digital, but even in a world where you're designing digital interfaces, behind the scenes, there are so many things that are run and done by people. Exactly. And yeah, and you want, I don't want to be disrespectful to their expertise. I don't want to be disrespectful to, you know, to the things that they have actually measured and done well. But it's sort of incorporating that into, you know, I don't want to say newer because it's not that new. It's sort of incorporating that into a different way of working. And I don't know, it's sort of a cheat. It's a cheat on my end. I know the other thing is evangelization. I'm not a very good evangelist. I don't, I still struggle on that end of the whole design thing. I know that some people are very good at it, the whole presentation of innovation. And I'm not, that's not my core strength. But because I'm a, I'm a research person, that's sort of where I attack it. I like that. Where you're more comfortable. Yeah, yeah, yeah. Yeah, sort of what people value in a, let's say in a team or how they measure a person. So that's the sort of where I apply. Yeah, as you mentioned, me applying my design research into, into internal team members. So, yeah, which is, I think, a really good development for the design discipline to applying it to the people around us. With services, I think it's, I've made quite a few videos by now where I think what a message is that it's really hard to design a service. The best we can do is to design the environment in which services emerge. And then it becomes a really interesting discipline as we're not so much designing the artifact in between quotes of a service, but we're designing the stage where the performance sort of has to happen on the moment. And then it makes a lot of sense to, yeah, think about the people around us as the design material. So we talked about, you talked about inertia, management, literacy, any, any other useful things that you have found in your practice again to overcome these challenges? Yeah, so that's, I guess, though the people framework is more about again the cultural layer. The other, the other thing is doing regular, I mean, so again, there's also about the actual work itself. So that is sort of trying to build a sort of culture that prepped people for what we want to do, but then there's also equipping them on a day-to-day basis. There are two things that I found that really worked. One of them being, one of the things that I had to learn the hard way was not templatizing things. And I actually, I have to give credit to one of my teammates who used to be like a business analyst and process engineer. She made me realize that not everyone can look at a document and make a template out of it. So sometimes we have to be really literal. So one of the things that I thought, that I thought was kind of easy to do was I made a presentation for us, for every release. So I was thinking, okay, for every release that we're trying to put out into the world, we have to be very clear about what insights went into it, what's the scope of what we're doing, what's the goal, who are we trying to serve, what are the learnings about the internal processes that also went into this particular phase. And I was trying to do, I was trying to model the usage of it. So every time we had like release planning, I would also do, I would show it. And then, you know, I'd try to walk, it was for me, it was like a fairly simple thing, like it was super clear with the goals, with the target. But there was like, there was barely any update on it. And we had like a fairly small team at that time. So I realized I had to strip it down, make it an official template, give it to people, and then sort of, sort of requiring it has to sort of track whether people were doing it. I'm not a big fan of, I'm not a big fan of tracking whether people are following a process. Because again, I think, you know, when you work in design, you're so used to people who, you know, because when you're a designer, your output really is the documentation when you're doing like a wireframe or a map or server's blueprint, customer journey, empathy map. Yeah, you're really used to working with these templates that like you have, not even templates, but, you know, trying to, a general framework and then trying to fill it in. So I kind of assumed that most people would be able to do that. But then I realized that even for, let's say, defining things, people really need to have something to follow. Especially, yeah, especially when it's about like designing an experience. It's very vain to people. So when you say they need something to follow, what is that? What did you eventually, how did you, how did your approach change? Yeah, so I ended up creating templates for people, and then also having walkthroughs for those. So rather than, again, before I thought I should just model the behavior, like if I model the behavior, people will naturally also see that the value in it that, oh, okay, that seems to be working well. I will apply it into my own work. And then, and then I realized that doesn't really work all the time. So I had to simplify, I had to also break down the documents that I made. And then I had to simplify it, make it like a template with actual definitions, and then also how to answer it. So for example, for creating a roadmap, I had to make a sample. Yeah, one, okay, what is in, what is in a first release? In a first release, there should like, you should have a theme or a goal, a clear audience. And then what are, let's say, the user benefits within that first phase. So I had to be quite literal about it. But yeah, I mean, that at least showed an improvement because people had something to follow. I remember that when I was creating templates at our service design studio, we usually at the back of the template, we just have a manual. Like one, one page, one side would be, when it would be physical, one side would be the template and the other one, the backside would just have arrows and annotations and start here. And I recognize also what you're saying, especially if you want to have people outside of the design mindset, using these kind of tools, they need a little bit of, what is it, examples, guidance, that's the right word. Yeah, yeah. Yeah, it was, I think, because again, because in the years prior to something into this type of environment, I was used to working with a lot of engineers and engineers are so, you know, rabid about learning. They really, like the whole, you know, the whole open sourcing and local sales, you know, they're all self taught or many of them are taught. So they're very active in terms of trying to sort of adapt these things. But then yeah, I had to remember that for people who are very used to how they work really sort of had to push them a little. And the other, the other example that I think I have of something that works is I started introducing quarterly team retrospectives. Because there were, you know, within a project there are retrospectives. But I wanted the team sort of have a view of how we were working together and treat ourselves as not a product, but to treat ourselves as something that was also growing and iterating. So for example, I just had this anecdote on why I think it's really important. In one of the presentations that I gave, you know, there was a presentation, I think it was a research presentation. One of my teammates approached me after and said that she was so surprised because she had never seen anyone admit to missing something or admit to a gap in her work, openly in front of leaders. And I didn't even, during my presentation, think of it because it was just, you know, for me it was just part of the process. You try to look at the work that you did. And then, you know, you have to improve yourself. You have to see the things that you were not doing very well. So I wanted to be very transparent about that. But again, to people who were working in corporate all their lives, that was, I realized it was quite unheard of and was unheard of to actually stand up in front of a group of people who were, you know, driving the business and actually say, I didn't do this well. And that's when I realized I had to get the team used to it. But it was like a muscle. I guess it's like a muscle. You have to get people to be using that, that transparency muscle. But it's okay. Like how are we gonna, how are we going to adapt a mindset where we can test things if we, we can't be honest with ourselves about things that aren't working, you know, within us or, you know, about how we ourselves work together. So yeah, that was one of the things that I tried to introduce. I kept it at a quarterly pace because I didn't want to sort of bombard everyone on a monthly basis. With, you know, having to reflect on how we were. What did you do in these reflections? Which questions were you asking? So I just, I actually just tried to follow one of the things that I learned from a Scrum Master that I worked with many years ago, where it was very, I liked his way because it was very kind. You try to look at your own habits and your own output and behavior and you ask yourself, so what did I do well and what could I have done better? So he mentioned that specifically because he didn't want any finger pointing that doing a retrospective wasn't about pointing out other people's faults. Because again, it was about trying to, you know, absorb a culture of being, you know, I guess accepting a failure because you want to be able to learn. I realized that that was the problem. Most people are afraid. I don't want to be cheesy and say, oh, I know people shouldn't raise failure. It's actually not the failure. It's the learning that's important. But if you don't put yourself in a position where you reflect on things that you didn't do well, then how are you going to improve yourself? And, you know, to be honest, like the first few, the first two quarters were a challenge. It was a lot of patting ourselves on the back and then still kind of blaming other people until I think it's a third run that we did. We really didn't do well that quarter. We didn't work well together as a team. I just went straight to what we can improve about ourselves. And I also tried to be snappier about it. I followed, I have to look for the link for that. But it was a process where you do one, two, like one, two, five, you do one minute with yourself, two minutes with a partner, where you talk about the key things that you wrote when you were, you know, doing the self-reflection and then five minutes with a group where you each talk about one of the, you talk about the themes that came up from your discussion. And then you try to talk about it as a group. And then because we were also getting bigger as a team by that time, so we needed to have a snappier dynamic. And then from there we wanted to be actionable. So after we surfaced all the things that we didn't do well as a team, I tried to ask the team to force rank, but to choose what they feel are the most critical things to work on for the next quarter so that we can track it. Because usually, you know, you'd come up with like 20 things that we can prove on. But you know, realistically, the whole team can't work on all of that. So we just have to be, we had to be very specific about, hey, as a team, what are the three things that we're going to commit to practicing in the next three months? And it was great because some of the younger team members really got into it in the, like in the, in the stages that we were doing it, where they weren't even trying to make acronyms for some of the principles that I wanted to try for the next quarter. So it was good because at least you really got like a team dynamic going about things that the team wanted to be better at. And especially if you're in an, if you're working in an environment, which is different and has different habits, different ways of working, and you're used to in a design context. For one, it's really good to recognize what the things are that you take for granted as a designer, for instance, the openness about failures and scrappiness. And I think a lot of us don't even realize that this is, this is different than most people are used to. So that's step one. And step two is then thinking about, okay, how can we improve? How can we grow? What can we learn from this and this critical thinking and reflective mindset, which is also part of the design mindset, but you have to apply it to yourself and to the context that you're working on. So that's, yeah, I can totally see that work and especially when the team is growing and you have some values that you want to adhere to. Yeah. Yeah. If you, if you had to summarize and give maybe people who are listening or watching right now, some quick tips on how to tackle these challenges, what would be like the key takeaways for you that you'd share with other people? Well, I guess this might be really vague, but I guess the theme for me is really, our work is about making services work for people. And that just, that doesn't just mean the end customers that we serve. Because yes, I mean, that's one part of the discipline. It's trying to map the experience of the customers that we serve and trying to understand how the services that we build line up to that. But there is also much to be said about understanding the processes and the people that actually make the service run. And my, I think my favorite tip is learn from, like one of the things I'm reading about Lean is that they have a thing called GembaWalk. What is it? Gemba, G-E-N-B-A. It's a GembaWalk, which means going to the place. So the people who made the Lean manufacturing or the Lean processes, like the beginnings of Six Sigma, they were saying that for you to understand a process of how something is being done, it isn't enough that you, it isn't enough that you try to like understand it or like do desk research. You really have to go to the place and watch the people who are doing it. And I think that it's really beautiful because he also says you have to go there ask why. So it's about, it's really, I mean, for me, like even, I think that was, I mean, the whole Lean manufacturing thing was what, 40, 50 years ago or probably 60 years ago. But even then, even then that was a principle. It was about observing the process of how something is done, but asking why. So that you are able to then sort of, you know, make solutions even for the people who are in the team. Because sometimes again, sometimes it's not straightforward. Sometimes it's not a straightforward to tell them, oh, we need to do prototype testing. We cannot expect them to, yeah, we cannot expect them to get into our world, right? We, we have to get into their world and then move from that place. At least I think that's some more effective approach. Agree. If you can't ram design down their throat. Yeah. Yeah. That's, you know, and the, the, the thing is we're not, we, we don't feel like ramming design down their throat. We, we're just so excited about design that we want to share this passion with everyone. We're so in love with it. And we forget that sometimes other people have other things that they need to worry about rather than falling in love with design. Angela, that was really interesting to hear some of your experiences. If people want to continue this conversation with you, can they reach out? And if so, how? Sure. I'm on Facebook. I actually have a Facebook page that I curated sort of all of my experience design related work there. It's my name, Angelo B.S. Subban, UX Research. It's in the show notes. Yeah. Tweets. Yeah. You can also tweet. My, you know, to find me on Twitter, my handle is yellow ice Don't ask. I was a teenager when I made it. So I kept it. Okay. So either Facebook or Twitter, and I'm making sure that all the links are in the episode, the description. Awesome. I learned a lot. You articulated some of the things that I think we need to articulate more often around the design, the discipline of service design. So thank you. Thank you for sharing that, Angela. Thank you so much, Mark, and I'm just so happy that you have this initiative happening in the world. I think it's such a great thing to be able to, like for me, to be able to listen to other service designers as well about, you know, the work, like actually how they do their work is incredibly useful because it's so hard to find practical advice on how to do our work. Thank you. Happy to hear that you're enjoying it as well. That's, that's nice. Thanks, Angela. I really want to thank Angela for sharing her experiences with us. And I hope that you enjoyed this episode and found some very useful and practical advice in it. If you know somebody who needs to see this episode, grab the link and share that with them. That way you'll help to grow the service design show family. And that helps me to invite more guests like Angela here on this show for you. If you'd like to get more practical advice on how to design services that win the hearts of people and business, make sure you check out this video because we're going to continue over there. See ya.