In this episode, you'll learn how you can elevate the conversations that you are having from opinion-based to principle-based and thereby make better decisions faster. The best of all is that you can do this by leveraging an existing tool in your design toolkit. Here's the guest for this episode. Let the show begin! Hi everyone, this is Wolfie and welcome to episode number 155 on the Service Design Show. Hi, my name is Marc Fontaine and welcome back to the Service Design Show. On this show, we explore what's beneath the surface of service design, what are those hidden and invisible things that make all the difference between success and failure, all to help you design great services that have a positive impact on people, business and our planet. Our guest in this episode is Wolfram Thurm, head of design ops at Gojek, a company which is serving over 170 million users in Southeast Asia. In my conversations with service design professionals, I often hear that they feel like they have to defend their decisions all the time and even sometimes themselves, that no matter which arguments they bring forward, sales and IT always win the conversation in the end and that the organization prioritizes to be human-centered only when there is time, which let's be honest, there rarely is. Well, if you recognize some of these challenges, make sure you stick around for this episode because Wolfram is going to share how they were able to successfully mitigate some of these challenges by developing a set of company-wide design principles. At the end of this episode, you'll know exactly what the key benefits are of having these design principles, how you can make sure that they don't become just another post on the wall with the five commandments which nobody looks at and where you can start if you want to develop your own set of design principles. If you enjoy conversations like this, which sometimes are on the fringes of service design, but help you to grow as a service design professional, make sure to click the subscribe button and the bell icon because we bring a new video like this every week or so. That about wraps it up for the introduction and now it's time to sit back relax and enjoy the conversation with Wolfram Thurm. Welcome to the show, Wolfie. Hi, Mark, I'm so glad to be here. Yeah, excited to have you on. I don't think I've had anyone on the show whose name is Wolfie or Wolfram, which I also find a very inspiring name. Maybe you can share a little bit about that as well. But first, the first thing I always ask on the show is for a brief introduction for the people who haven't looked you up yet on LinkedIn. Who are you? And what do you do these days? All right, yeah. So I'm Wolfie from Germany, but living in Bali in Indonesia. After spending the last nine years almost in India, I've relocated here. I am the head of design operations at Gojek, which is like an on-demand platform operating in a couple of Southeast Asian countries, solving a lot of customer problems like food delivery, mobility, logistics, two-wheeler, four-wheeler taxi services, grocery delivery, and all these kind of things. And yeah, I'm heading a small team and trying to elevate the craft and how design works at our company. Cool. So I heard you say design ops, and that's one of the reasons why we got in touch. And I heard you say something about Gojek, which is quite interesting because it was a company that I didn't know anything about.  No, absolutely. No, I'm glad to. I'm happy to. I love what we do, so I love to talk about this to be honest also because I'm a strong believer in what we do. It's a social impact first kind of company, but with a very massive impact and a massive scale in Southeast Asia. So Gojek, as I mentioned, is an on-demand platform. We do logistics, mobility, food delivery, grocery delivery. We have two sister companies, one for financial services and one for e-commerce that came into being after a merger about a year ago and we've gone public as a company a couple of months ago. So it's an exciting time for us also, but yeah, we are quite large actually. So there are more than 2.5 million people, livelihood that actually depends on us in terms of our driver partners and merchant partners. Our company alone contributes more than I think 2.5% of the entire GDP of Indonesia. So that kind of scale is massive and as far as I know, quite unheard of for Western companies. And so it's a very meaningful job because it actually touches millions of people every day. In terms of our end consumers, of course, we have hundreds of millions, but in terms of people actually depending on us, there's still like millions of them. So that is quite meaningful. Again, it's insane and it's obvious that there are these companies out there which you don't know anything about and that have such a huge impact. Yeah, I'd love to hear more about that in this conversation. Before we dive into that, there is a 60-second, nowadays maybe 90-second lightning round, five questions, which you'll have the goal of answering as quickly and briefly as possible so that we get to know you a little bit better as a person next to the professional. So five questions for you. Are you ready? All right, let's do it. All right. What was your first job? I was a tailor in a clothing store doing custom clothes for men and women. That was actually my first job. But to be honest, my real professional first job was a musician. My professional background is music. I used to be a musician, western classically trained. I play the French on and that was my main profession. Cool. Yeah, I like how design attracts people from many different disciplines. The next question is again, very personal. If you could be an animal, which kind of animal would you like to be? Okay, easy answer. A cat, but I need to specify a cat in Istanbul because I think if you are a cat in Istanbul, that's when you really made it in life. What happens when you are a cat in Istanbul? They are incredibly well looked after in Istanbul. It's this whole cultural concept of looking after street animals and every single cat there has a fantastic life. Awesome. We'll note that one. Next question is about books. If you could just recommend one book to someone, which book would you recommend? Fiction or nonfiction? Nonfiction. Nonfiction. One book I always love to recommend is, it's called Creative Confidence. A beautiful book about design thinking in general. A very foundational short book. Amazing. I can second that recommendation as well. Next question is, you're in Bali, so I'm really curious to this question. What's always in your fridge? To be honest, like we have to say, if you can see the back of the fridge, it's considered empty, so there are a lot of things. I love my bread for breakfast, so there will be always bread and some cheese, some peanut butter, jelly. But most likely you will also find beer, tonic water and some booze. All right. And the fifth and final question is about service design. And I know you're in the design ops space, but I'm still curious if you recall a moment when you first heard about service design. To be honest, I think that was during college, actually, like studying designers when we first heard about it, but I had literally like no idea what it was. And that stayed the way for many years to come and only now more and more I starting to understand like the nuances and complexities of it. Cool. Now, let's transition into the topic of today. And I was reading through your notes and I came up with a sort of the summary or the pitch for this episode. And that is how to make better decisions faster. That's the promise that you need to deliver upon in the next 45 minutes. So we're going to talk about a topic called design principles, which is something that I assume will be familiar to many listeners. Design principles are a cornerstone of the design process. At least I think so. And I've used them a lot in my days when I was a service design practitioner. I'm curious to your maybe quote unquote definition of design principles. What are they to you? Yeah, that's a great question. Thank you. Yes, I agree with you. Design principles are being widely used. They are first principles that we use. They create books written on design principles like the shape of design, the loss of simplicity. However, for us, design principles were really like a tool that we needed to develop in order to improve the way we have design conversations, design critiques, the way we prioritize work. So when we speak about design principles, we don't exclusively look at what we work on, but also like how we work on those things. For us, design principles were a necessity that was born out of the experience of not being able to really get our points across in the way we would like to. And so we needed to really kind of improve the kind of ammunition that we have in conversations, whether it's a design critique or prioritization session or like an iteration planning meeting or even just simple documentation like documenting design specs, et cetera. Okay, so you already hinted upon a lot of things we'll explore. But before we dive into all the details, you have a set of design principles, set up a set of internal design principles as a team for the organization and you already sort of hinted upon why and what the challenges are, which challenges they needed to address. I want to go back in time as I usually do at the start of the conversation and that is to understand how did you as a design ops team, as a design or lead arrive at a point where you thought, okay, we need something and that's something might be design principles. Can you share a little bit about the journey, how you got to realizing this? Absolutely. I think one indicator was, and that actually predates my joining Gojek even, but one strong indicator that we had was that we kept having the same kind of arguments again and again and maybe also that mistakes were repeated again and again that we might have been failing to make our point again and again and as soon as we realized there's a pattern here, we saw the opportunity that a principled approach might actually help that. Of course, as for any design project, it's kind of hypothesis driven that we assumed that principles will actually help us to elevate the kind of conversations from what we felt was a lot of opinion based conversations to like principled ones, but that was the foundation or the breeding ground, so to say for developing design principles. Long story short, a lot of things went wrong, right? A lot of things went wrong or like went not ideal in conversations and we felt that design principles will give us the leverage to change that. Let's double click on these terms. You introduced opinion based conversations, principle based conversations. Could you color that a bit with some examples? What were some of the common... What kind of conversations might somebody recognize as being opinion based? If I'm a service designer, maybe UI, UX designer, what are the situations that I find myself in where I could recognize, okay, so this is what Wolfie is meaning. Well, I think for anybody who works in product development, especially digital product development, they're countless conversations where you find yourself confronted with a person's opinion that weighs more than your argument just because that person might have a higher position in the organization. I know there's this acronym I think we call them HIPPOS, the highest paid person's opinion. And that can be very frustrating if you actually, you might even have data to support your insights or you might even have like very good research data, could be customer data, could be any kind of thing, and you actually try to convince a person to prioritize a feature that would notably increase customer experience and you get challenged with a simple I don't think that's gonna work. If you remain in that realm of opinion based conversation, it's gonna be very hard to actually convince the other person to change their opinion if we actually believe that opinions in a situation like this matters, when in fact they shouldn't matter. And this is like a super frustrating process because you sort of have some evidence or something that points you in a certain direction and you encounter objections or critiques or, well, you don't get the support that you would expect based on the quote-unquote evidence that you present, right? That's sort of what's going on. But it's a limited perspective here, right? Because we're looking at the clashing of opinions and the idea of principles is really an idea of elevation, of elevating the conversation to no longer be opinion based, but actually about principles that both agreed on. Let me give you an example of one of the most beautiful principles that is closest to my heart. It's called what's good for the customers, good for the business. It's kind of obvious. Everybody knows this. Customer centricity is good. Customer centricity is great, et cetera. But a lot of people are still stuck in this narrative of design versus business that is saying that you have to balance business goals and customer needs. Obviously you have to balance those and obviously there is a bit of a dependency, but one has to understand that this dependency, the actual is not neutral. You can see what's good for the customer is good for business success. What's good for the customer is good for the business, right? Because you know that customer centricity will ultimately lead to business success. But you can't really say the other way around that something is good for the customer because it's good for the business. So it's understanding this nuances of what is the actual goal behind balancing customer goals and business needs. If you actually understand in a creon what the larger objective is and that goes much beyond a difference in opinions. It actually means like you are aligned on the larger objective and the vision of it. You immediately elevate the conversation from something about opinions to something about principles. And it's much easier to take a decision based on that principles, which kind of like circles back to the very high barbie set of making faster and better decisions. So when I was thinking about this, and I'm going to ask you to explain and share with us how this journey of coming up with these principles happened, but sort of the feeling of our company values came up on me like seeing those poses with the five company values and then we all adhered to them like we did an offsite session two days, like I'm exaggerating here, but I'm curious like how do you now there's so many questions popping up in my head, but how do you make sure that people actually live these principles? That's a tough one, right? Because it's very easy to come up with amazing projects and I don't know how many millions of amazing documents just lie around in corporate share drives and nobody cares about them. And I think that's one of the things that is always key. Let's talk about the adoption or bringing it to life first before we go into the origin story of it perhaps. So to me there are multiple layers when it comes to evangelism. I think there is largely, and that is basically just talking from my own experience and I might be wrong about this, but I'm just sharing what we've learned along the way. There is one leadership layer which is mostly purely about education and broadcasting, right? You might talk about this in a company all hands. You might talk about this in like large meetings where I just introduce it as a concept and educate people about the existence. The second layer for me is on a group or team layer and that evangelism is much more critical. It builds on top of the educational foundation and again that team or group layer, for example for us, happens as a workshop and again there we have to look at not only educating people not only explaining the concept but also applying the concept also reflecting on the concept. Again, that second layer of team of contacting workshops for me is very, very critical and it has to transcend pure education. It has to become interactive and it has to become memorable and beyond this that you can actually reflect on it also. We conducted workshops where we A, understood the principles B, applied principles in situations that we face today and C, we actually reflected on past situations in which those principles could have actually helped us to make better or faster decisions and that Trinity actually helped us to get a much higher adoption and the third layer of evangelism is one-on-one, right? It's relentless persuasion of a lot of people and keep talking about it, keep bringing it up and making sure that everybody actually knows that and the most effective way to do this is you have to find the right kind of allies we have to find those those people who have a lot of gravitational pull and if they become your allies they will become our own brand ambassadors for the principles itself. So that is one part of it, right? That's the evangelism part of it. The second part I feel is also about tracking there needs to be some sort of feedback of how well we are actually doing and that again is how we are going to measure whether somebody has or has not used principles so we had a bit of a lucky coincidence there I would say because we actually planned to develop a physical set of cards with our design principles that people could carry around in their pockets you find yourself in a meeting room in a heated conversation, you can slam the card on the table and say like hey, this is a principle violation and then while we were preparing for this COVID game and we had no longer an office to go to which kind of was a shock for all of us and that's a whole different topic to begin with in itself but for us that meant these physical cards were no longer viable and we actually created digital cards now all of our company conversation happens on Slack including like retakes and feedback and questions in Q&A sessions are being conducted on Slack so we developed like a custom Slack app in which we can actually use those principles and so instead of slamming them on the table you slam these principle cards now into Slack conversations and it's not quite the same but it gives us the advantage that we can actually measure how they're being used in which circumstances by whom how many times we can actually get data on like what are the most important principles that are used most often and we can actually get data on that so that's quite powerful in order to validate whether those principles actually have any impact or not. That's super interesting and I can see how that helps to sort of stare and iterate and prototype new ideas around this when you are sharing this, I'm sort of hearing that adoption is pretty successful or at least it's more successful than in many other examples that I've heard the thing I was curious about is this the problem that it solves initially feels like it's the problem of the design professional like they feel that they aren't being heard or the company isn't listening to them so there's a clear benefit for the design professional to have something like these principles why would the organization or the rest of the organization also adopt these because for the other people inside the organization it might be like come on just stop complaining do your work and what's in it for them? How did you pitch that? How did you get them to also get on this company? I think I have to be honest with you too I don't mean to over idealize this to keep these principles alive it takes a lot of work and dedication and at least a person needs to actually constantly be on top of that which is also I think why in the last cycle in the last six months perhaps the usage and adoption has actually declined but we have the right tools to intervene again to like bring this up so I'm not too concerned about this but when it comes to like yeah why would anybody agree to them obviously like a designer can just come up and say like yeah could you access the most important thing in the world and I might say like you might think that but I don't so that brings us a little bit to the making of the principles right and I think what you are referring to is like last 10% of it which is obviously like 90% of the work and that was actually getting everybody on board and that meant negotiating negotiating negotiating you actually had to find these common ground that not only your product or research or engineering counterparts would also believe in who are naturally like easier to convince but also your business counterparts which was much harder but we kind of went through that exercise again and again like meeting with them aligning with them making sure they're on the same page that this is something they agree to because we knew unless they agree to this unless they believe in the same principle for example what's good for the customer what's good for the business only if they believe in that as much as we do we can actually use this as a principle but that whole concept I mean that whole negotiation is part of what principles are about it's about elevating and trying to identify what is this like underlying objective what is the actual objective of the company and if you call yourself customer centric or design lead right it's very easy to call yourself this it's very much much harder to actually put this into action but if you truly want to be like a customer centric company if customer centricity is one of the core principles for your for your product development then you got to agree to some of these things and that is the route that we also took this sounds like a super strategic initiative this it feels like if this starts bottom up it won't have any chance to succeed you won't find adoption outside of maybe your team or department how did that go in your situation to be honest Gojek is a fairly bottom-up in terms of how we run things if a large-scale initiative is to survive it has to be a bottom-up initiative because that's where you know the groundwork has been taken it's it's much more often in my experience that top-down things fail than like bottom-up things that had the resilience to like push through how do I phrase this like we had an advantage in Gojek and that is that we had a wealth of experience how things went wrong in our past we didn't start the exercise of building principles from scratch from from zero we actually started with a wealth of I call them let's say micro case studies of instances where principles could have helped reach the better outcome for our customers as well as for the business so this becomes a very strong leverage in a conversation like this and I've had conversations with other designers professionals who want to introduce principles who are using this from zero who don't have that wealth of experience is how things can go wrong and how principles could have helped and I feel that worked in our favor in that negotiation to convince business stakeholders to also buy in because you can make a business case right yes I mean I would not only call it a business case but you can make a quantifiable case and I think customer centricity is not only about its translation into dollar values it has to be more than that otherwise it's just kind of fake and if if the company actually believes this then it's more about quantification and the quality of your argument rather than translating everything into a direct business value I would and in my perspective a business case is more than numbers value but at least you can make a case based on the failures and whether it's increased revenue or it's increased employer employee happiness or customer satisfaction like you can find argument that's it you can find arguments that help you to make to say why this is important why we should align on this right absolutely though I also have to be honest I feel that Gojek has been customer centric always so I feel that the battle that we are fighting is an easier one as compared to some of the other stories that I've been exposed to right like something as simple as what's good for the customer what's good for the business it doesn't take much to convince a business stakeholder that this is a good principle to follow it's not that it's not that case in the vast majority of companies today unfortunately yeah and with like with that I think you'll find a saying like that in many I don't know company values and norms statements company missions the tricky thing seems to me like again how do you actually live by this because when when the heat is up and often I don't know middle management has to make short-term decisions these are some these principles often become nice to have rather than actual principles yeah it's a fair point I think there are two parts to the answer to this one is to understand like what principles actually are and like how they apply in our case the other one is also like at what point in your product development life cycle do you introduce them so maybe I want to start with this one I feel what we've been trying to do is that when you actually start at inception itself or kick off or whatever you call this initial stage of scoping and planning if you actually use this stage to talk about hey what are the principles that we want to set here that will guide the decision making in this project and they don't even have to be our design principles they could be any kind of principles as long as they're not conflicting with each other that's fine because obviously like our design principles are not they're not all encompassing right there might be specifics that you want to add to a specific project if you can actually manage to have this conversation early on it's much easier to use the principles as a fallback even if things get hot the other thing is like how these principles actually apply right so when we arrived at the set of our principles it's largely and we can talk about this a little more in detail later also but it's largely like multiple rounds of affinity mapping that actually like lead to understanding what are the kind of like themes that emerge what are the kind of principles that would apply to those kind of themes and we had multiple models run should we arrange or sort the principles by a timeline like when they appear in the product development life cycle should we arrange them by stakeholders should we arrange them by what we're working on versus how we're working on the things they're like many models that one can apply for us we developed an in-between version that felt right for us so we have a combination of what we work on and how we work on but in reality the way the principles apply they don't make the decisions for us right they are ammunition to make the decisions and while the principles are not conflicting they can actually be perceived that way to give you an example one of the principles that we have is explore all possible solutions very design-focused iteration-focused principle that you make sure that you really go broad and that you don't buy in your first idea another principle is called launch to learn which means ultimately in order to learn anything you have to actually launch it and so while one principle talks about the exploration and spending more time in going broad the other one says you have to actually launch it in order to learn anything so you could say that those are conflicting however the way we look at principles is that it's not that those principles will make any decisions for you you use those principles to take a decision and yes I get that and it becomes an art like finding knowing how to balance and nuance and prioritize these principles I would love to hear a bit more about what other principles you also have that you don't regret or didn't make the cut but in my head I'm sort of trying to summarize this already and from the limited knowledge that I have of architecture before they start making anything there is like a brief that says something about probably sustainability these days and which materials should be used specifications that the eventual construction needs to adhere to I can imagine that these design principles have the same role but are more focused on the human factors in this case or maybe even on the design process and one more thing to add there the reason I'm saying this is you mentioned that it helps thinking when in the process they apply I think it's super critical like you said that when you have the opportunity to introduce them in the inception stage that it becomes so much easier to actually use them, live by them compared to when you want to introduce them in something that's already running so this isn't really a question but a long observation No I mean your spot on for us it's a bit of a combination of both what we work on so it can be leveraged for prioritization and it's also like how we work where it's more leveraged during the process I mean we have principles being used in research reports right if our research team comes back with a detailed report and a list of recommendations they actually use those principles to substantiate their claims they're just kind of a powerful application also maybe it becomes more alive if I can also talk about it's a total set of 16 principles which is a kind of large number so in all honesty it's also our version one we hope that eventually we can actually do a version two that might be the 10 commandments or something like that but 16 was the number that felt right for us because it's basically like four groups of four and we call those four groups the four eyes because there are four principles for impactful design there are four principles for inclusive design four principles for intuitive design and four principles for iterative design and when we look for example at the first pillar the impactful design it's not all of them are about process right for example start with a problem not the solution this one might be process focused and it's a very well known principle that you shouldn't jump to solutions but you have to really fully understand the problem first it not only talks about process it also talks about the quality of problem definition in itself right do we really understand the problem well enough to to move on another one for example though is like know what create looks like and know all your constraints to ship so know what create looks like means do you actually have like any kind of data do you have any kind of metrics to understand what your success actually looks like what will failure look like do you actually know when you have succeeded or not it's kind of shocking to see that many projects that I have seen other companies as well actually are not clear about defining when have we succeeded and when have we failed and constraints right constraints is not only feasibility it's not only mean it doesn't mean only to talk to your engineering partners early on to say that hey can we actually build this it's also understanding like external constraints cultural constraints political constraints all of these kind of things so those principles are not only focused on the process and how we actually do product development but really about like what are the kind of issues that we really need to work on and how do we approach that can I ask a question about this what I see with statements like this is that they leave a lot of room for interpretation which is good they feel subjective and again that might be good but if you want to move away from opinions and more to principles people need to have some sort of shared vision what this actually means so the examples that you gave what does good look like or what does success look like I'm curious if you're doing something to make that even more specific maybe provide cases of case studies like this is what we mean when we say this absolutely and thank you for bringing this up because yes the principles are meant to be not generic but in a way open-ended because they can't be instructive right they can't be that one-dimensional so the way they actually manifest in reality and that's part of our adoption strategy itself is we actually have a wealth of case studies supporting each of those principles there's literally like 20-30 case studies sometimes supporting and these are all examples from our own past of where this principle was followed or broken and how the principle could have or did impact the outcome of that particular situation so there's actually like a long long list of micro case studies because we don't want this to be like heavy documentation they're literally like one paragraph like two sentences long examples but each of those principles has a long list of those so it's kind of easy to understand how they manifest in reality and I think you need that kind of evidence to ground these principles otherwise I can see that people will really quickly turn this into well this is just your opinion like this is just what you find important but if you have examples where things didn't work out or did work out because you did or didn't follow a certain principle this moves it away from this is what I think to this is what happened and I just made an observation and this is absolutely so it's both right on the one hand it is instructive in a way that you can understand how these principles manifest in the other way this itself is a very big part of the argumentation to convince business stakeholders that those are the right kind of principles and by evangelizing them we actually increase our ammunition and leverage to substantiate why they are the right principles because through these kind of workshops that we conduct we actually gain more and more wealth of case studies and examples of how those principles could have helped in fact we also get data on what other principles could be there or what principles we might be missing etc but essentially this is like a crowing library of data you mentioned the workshop already a few times like can you share a bit more about that like who's doing the workshop who is going through the workshop what do you do in these workshops like because that sounds like a critical element in this entire process no I very very much think it is I completely agree with you I want to circle back to these like three layers of evangelism also three layers of education because a workshop in itself right it doesn't do anything like unless you can actually generate the perception of value in the audience it's just going to be time spent or in the worst case time wasted so we really had to make sure that those workshops actually lead to action so we set them up in these three layers on the one hand in the first layer we explained principles we explained how they came into being why they are the way they are what they are etc and we run through that with the audience in the workshop and by audience I mean we conduct we conducted workshops with smaller groups I would say with like product development groups let's say one product vertical is in one workshop so that means between 15 and 30 people perhaps so step number one is of course the introduction the educational aspect step number two is where it gets really interactive that's where we actually like have have set a whole bunch of random examples from our current or recent past of what's going on in Gojek with the task to the audience to actually match the principles to the right kind of scenario almost a bit like a quiz but more like an interactive exercise and one aspect that we realized there already is that it's not necessarily that one principle matches to one situation but mostly when things go right a lot of principles actually have been followed and when things go wrong it's usually the result of picking multiple principles so this is not like a one to one exercise but actually like understanding the whole matrix of how how various principles influence certain decisions and that's the second part where we actually apply the kind of knowledge and the third part which is the reflection part is where we ask the audience to actually come up with their own examples from our past at Gojek they could even be like examples from their previous companies we hardly have ever had any of those but that's where people actually reflect on their own past and that's why it makes sense to keep the workshops with a specific audience like one product group because usually that's shared experience especially with a more senior people and that's where we actually get these really really interesting stories that we didn't know about that actually are provided by the audience and this kind of input is a big part in not only understanding how those principles might be viable for you but actually seeing in your own examples in your own context on how these principles can actually amplify the kind of impact that you have so it's the combination of these three layers of education application and reflection that I felt is a powerful combination to that leads to behavioural change it hopefully leads to insights in those aha moments and it makes these principles come to life I think that's the key that people are able to translate what these principles mean in their own practice right absolutely yeah one one question related to this is it sounds like the initiative to organize these workshops to come up with these principles to maintain them is within your design is that the case that is the case yeah so the spark for it might come from the design leadership might come from an insight we have many many sources of where we get ideas from I don't want to ever claim ownership over an idea once an idea emerges we execute it and it also speaks of what design ops actually does in many organizations it's a lot of chasing people down and nudging people and reminding people and a lot of evangelism if one of the goals of design ops today and that's the case for our design ops team we actually embed customer centricity into the company's DNA then these kind of workshops can be again leveraged to inch closer to what's the goal like that but it means that yeah the initiative is on our side and as everybody would probably agree who works in larger corporations information just by existing doesn't reach anybody you have to very very actively like bring information to people you can never expect people to just find your information or come to you so chasing people down nudging people, reminding people sending out reports on usage and adoption on impact stories etc those are all like the tools that we can apply to keep adoption high and is increasing adoption of these design principles and making them better the quality of them better this is a weird question but is that your yearly review, are you sort of judged by the success of this? so the honest answer is not in this year, last year we did have this on our OKAS and we had a certain adoption target it was a percentage of all designers as well as a percentage of non-design users that we chased and we reported on it and we were accountable for that yeah and absolutely accountability, that sounds like something that we haven't addressed yet but it might be the magic ingredient here because even though you say you don't own this there is somebody responsible and there is somebody who is accountable for making sure that people are chased down, that this is brought forward in the organization that these workshops are organized if I can assume the big pitfall here would be like we have design principles and everybody owns them and then nothing happens because everybody owns them absolutely, there has to be ownership and there has to be accountability that was my job when I joined was the development and the follow up on this when I actually took over the team in all honesty is also when my bandwidth was severely compromised and I could no longer exclusively focus on some of these projects because my role changed from being executioner to being much more managerial and that's the issue that we face today like who can take this up because we are a post-IPO company now our budgets are not as lavish as they used to be things are not as easy anymore but the power of those principles remains and it's very much still there they are still being used they're still being leveraged but they could use a boost absolutely but because we kind of have this the setup and we have this toolbox we know what levels we could pull to speed things up again to boost adoption again imagine you move to a different company or maybe you get a big reset button in this current role and they offer you the opportunity to start again we want design principles because we experienced the challenges that you described what would be some of the things you maybe would do different in the second iteration coming up to these design principles based on the learnings that you gained in the past few years I assume to be honest it sounds a little commonsensical perhaps too commonsensical but in my reflection I would probably focus more on lesses more because I feel our principles are too broad they cover like too broad of a field and in themselves they're not like for me the fact that it's both what and how for me it's a bit of not a problem but it takes a little bit away of the punch that the principles could have if this would be more clear about like hey these principles are how we prioritize hey these principles are how we work it becomes more applicable so I feel if I were to do this again and that might even apply if you do like a version 2 of those I feel more focus in the way we structured the principles in itself would help them to become more effective how did the structuring occur in version 1.0 version 1.0 there's always chaos right so I I have to keep this in mind as a disclaimer as I mentioned multiple rounds of affinity mapping but that's an oversimplification so we had like these long long lists and lot and lot of anecdotal data of things going wrong repeating patterns etc and we're trying to like organize through these through the exercise of affinity mapping trying to identify meaningful themes meaningful buckets, meaningful like clusters of principles and we went through many many iterations and as I mentioned right we can base themes on timelines we can base themes on stakeholders we can base themes on all sorts of things and it was very unclear for us like what we should do we could even base themes and let me just put that out there also on like cool acronyms because it should sound like very memorable because yeah principles have to be memorable right so when the 4Is emerged for us it also felt like a meaningful mental model that we could apply that makes these principles more memorable for example and we kind of run a lot of feedback rounds of course like with the team with stakeholders with our partners in product and research and yeah it's the result of that process of that iterative process that we arrived at this version. Yeah it sounds like a lot like that design process where things emerge things emerge you go broad you go narrow we always do this it's one learning for design itself right the projects that we execute or the programs that we run we run them like design projects we have a problem space we have a solution space we have diamonds we have diverging and converging phases the same logic applies here in the development of the design principles and yes there's always like a spoonful of chaos and unpredictability involved as well but that is what design is all about and yeah that's kind of what happened to us you let me ask you another question about the process getting to this as we're now sort of reflecting on that you mentioned the 9010 rule I'm going to go for the 8020 rule if you look at the activities that you undertook over the past few years there are always a few activities which sort of give you the most impact what do you feel have been the is a 20% of activities that gave you the biggest benefit the most value in this entire process that's a tough question I feel that actually we spend a lot of time and effort at the very very specific wording and phrasing of the principles together with our UX writers and writing professionals which is an amazing experience for me as a UX professional to actually understand like the power of writing and writing professionals and the kind of value that they can actually add but we would literally like spend hours debating over very specific words just not only do they really convey precisely what we want the principles to convey but also are they worked in a positive or engaging way like are they all following a similar pattern etc so there's a lot of nuance to be considered so that part actually helped us a lot and actually I feel even though it was a lot of time that we invested the effort was worth it because creating that punch behind a principle is really really critical for it to be effective the other thing that I want to mention is the countless debates and negotiations with our partners about those because without them as you mentioned earlier the principles would be meaningless because they would be just designs they wouldn't actually be carried forward by our partners in research or in product or in engineering or in business even and these negotiations were tedious and again a lot of follow up chasing people making sure people actually read them give their feedback understand them etc but again I feel this was really really important I saw a couple of other initiatives similarly that didn't spend as much time in doing that and there is a significant difference in the way they are adopted I'm happy that you mentioned this because my question tries to evoke maybe quick wins, fast wins the easy process but the good thing maybe here is that it's not easy it takes a lot of time a lot of effort you have to go through this to get to a meaningful result there isn't maybe there is but we haven't discovered it yet it doesn't sound like there is a 20% you can only focus on like you need to focus on the 80% as the other 80% as well you absolutely have to I completely agree and if you see the 16 principles today they all are very obvious they all sound very commonsensical but it's the hard work that actually made them appear very commonsensical and obvious and I feel 100% it's worth it though I also have to agree that everything needs to have a timeline you can't just like explore endlessly and especially as designers we need to remind ourselves sometimes of this but here all those effort that kind of happens behind the scenes that you can't really see behind the end result definitely made a big difference of course the 16 principles that you have it's like all the conversations that happen to get there sometimes I see these principles and many other artifacts within our field as an excuse to have meaningful conversations it helps to say we're working on principles and therefore we need to have this conversation together we need to align on this topic yeah and that's not even a side benefit that's maybe and then I'm sort of getting on your seat that's maybe the biggest benefit that these conversations have happened there is a strategic component to it like how do you establish how do you position design in general in the organization and obviously these conversations play a part like obviously running initiatives like this along with a lot of other initiatives that my team runs these are not only there's always a secondary benefit of how this actually contributes to the role design plays overall in the organization as well yes and design principle conversations are very critical to understand like hey what is the kind of role that we actually play so somebody is listening to this episode and they are actually pulling their hair out because they've just come out of a meeting where they met a hippo and they weren't able to get their points across and this wasn't the first time so now they are super inspired by your example of using design principles what would you say to them like where do you start to where do you start this process yeah I mean for us it was honest introspection of where things could have been better and understanding the patterns that emerged there and I think that is a good starting point because if you start with zero experience of how things go wrong there's a it's pure chance whether your principles that you develop are meaningful or not there are a million of principles there are like websites there are books written about all of them are important they are wonderfully phrased and all of them have examples but do they actually mean anything for your specific product development that remains to be seen I think it makes sense if the emergence of principles is based on real examples and real experience and that's where they become powerful and I think that is the starting point and then once you have those examples so you do an introspection maybe alone or with a few of your team members you see all those cases where things could have gone better like what's step two then you start building principles if you talk about double diamonds that would be the divergent aspect of it the gathering of data and then we converge we actually start to narrow it down just to circle back to this point I do believe that this has to be like a community-driven approach if you do this in isolation again like a top-down enforced principle might not be as powerful as a principle that has been developed collectively and has actually carried forward and believed in by all and in order to do that you have to also let go of a lot of this decision-making power you actually have to distribute decision-making power to where the information is the experience is done by the people on the ground solving actual customer problems they are the ones who face the issues in reviews and fighting with their product manager counterparts or engineer counterparts or whatever it is they are the ones who actually make the experience, they are the ones who should be involved in deciding on what those principles should be this is a Simon Sinek a concept which I believe he calls distributing decision-making power to where the information is I think that's what he calls it in his book Leaders Eat Last which is again one of those books I would recommend but this is a very powerful thing to do because not only are you ensuring that the information you work with to develop your principles is actually first-hand experience and not watered down through like Chinese whispers it also means that when you actually do develop those principles and apply them you have your brand ambassadors built in the system because they are the ones who are invested into changing the status quo they are the ones who actually solve the problem so it is this kind of bottom-up thinking for principles I think is very essential for it to be actually something that is carried by all and not just enforced by a few one question that I have about this and then we'll sort of start wrapping up this episode this stage between introspection and reflection and seeing like the failures and then defining or designing the design principles is like was there a stage for you where you needed to go to leadership to get permission to actually go into the organization and run this? I don't think so I'm a strong believer in ask for forgiveness not for permission so I large corporations tend to be very by nature become more bureaucratic and if you actually believe in the bias for action then you have to just get out there and do things and convince through outcomes rather than asking for permissions up front I never felt that the workshops itself would be their own success criteria if people would leave those workshops and saying that's a waste of my time and that's a strong indicator that I was wrong about my assumptions or my team was wrong about their assumptions but getting the feedback from those sessions actually is kind of validation enough even for leadership to see hey there's value in this and I think the reason I'm asking this is it has to be part of your job description sort of to have the space to work on this challenge like if you're I don't know a service designer right now and you're seeing how design principles could be beneficial but that's not the thing that you've been hired for that might be a challenge you need to find somebody in the organization who has responsibility accountability ownership of a challenge like this that I think that that was what I was trying to okay no absolutely but I to be honest I feel this is probably like another whole episode worth of stuff and it comes to like how do you actually justify your existence right if we really like go to the root of this question it's about that like how do you what's the kind of narrative that you actually build to justify your existence to justify the projects and programs you want to run as design ops and I could imagine that service designers are facing very similar challenges where they actually have to kind of quantify what the hell what value they're actually adding to the business and that is not an easy thing and quantification of use experience is already hard and many people struggle with this and now if you take it one level up and saying like how do we quantify internal processes that don't even are directly touching our end consumers that's an even harder thing to do but there are many many metrics that one can apply and that we do measure and keep track of I don't want to go too much into the details but obviously like principles can be correlated to a speed of delivery to velocity a lot of the programs and projects that we run can be correlated to engagement to employee retention to morale productivity and as soon as you actually prevent people from leaving your company that's a hardcore business metric and if you talk about speed of delivery if you talk about and it's not all about translating what we do into dollar values again it could also be translated into time it can be translated into all sorts of things this is actually something I could probably talk about for like another hour because it's obviously like an issue that we also face and something we work on very very actively like how do we actually empower the people in our organization to have more impactful conversations with their counterparts about like justifying like why a thing they want to do is the right thing to do that in itself is the topic for many books as well but yeah data as everything and being able to substantiate your claims or your concerns with any kind of data points that's the way to go I know that we had that as the alternative topic for our conversation today let's just agree we'll do a sequel episode and dive into that data aspect of our work because I think that will be super beneficial to the listeners as well but for now we really have to sort of start wrapping up and maybe a question that would be good for that is if somebody made it all the way to the end to this moment in the conversation which I applaud them for and I hope they enjoyed it so far what is the one thing you hope that they will remember from this chat? Great question to me it's the idea of when we talk about elevation of conversation we're not only talking about making our counterpart understand what we want it's also about us actually elevating ourselves up to that level above and really starting to look at the people we need to agree with not as our opponents but our allies and actually find that common ground whenever I see there is a conflict in a professional setting there is almost always just a conflict on that layer the moment you level up the moment you zoom out and become strategic and talk about what are the common goals the moment you align on that it's a completely different conversation and you become very powerful thought partners to your product and business counterparts rather than they are like a pack in the wheel and principles can help they can be a tool they can be ammunition to do that there are other ways to do that as well but this idea of elevation making sure you find that common ground is very transformative in order to be a professional in any setting yeah makes a lot of sense and it doesn't make sense to see people who are working next to you as your enemies you hopefully have these same purpose same goals and when you're struggling in conversations it's probably not because of the shared goal but it's because of operations, practicalities, tacticals, stuff like that or simply a limited perspective in order like you might not know what this other person is going through as well but anyway anyway I think that's a great sort of thing to wrap up wrap up on that's what I wanted to say thanks so much for sharing your perspective coming in from the design ops community I really think that the service design community can benefit a lot from what's happening there knowing a bit more creating a bit more awareness this was a great conversation about design principles and how they can help to make better decisions faster I think we'll let the listeners decide but I feel you managed to definitely deliver upon that promise and show the potential there so thanks again for coming on and sharing this with the service design show community thank you so much Mark for having me I really hope I was able to add a tiny bit of value to maybe one person that's all I hope to achieve and thank you so much for having me I really hope that you enjoyed the conversation with Wolfram as much as I did and that you got something useful out of it if you haven't done so yet make sure to click that subscribe button so you won't miss any of the future episodes thanks so much for watching and I look forward to see you in the next video