The role of UX in the most played computer game League of Legends - with Alex Wheeler @Riot Games

Welcome everyone to a new episode of the Product Bakery. I'm again here with my co-host Christian and we have a guest from Los Angeles. His name is Alex Wheeler. Hi Alex. Before I start introducing Alex, let's talk about the elephant in the room. We have two Alex in this call and I'm absolutely overwhelmed. Yeah, that's a common problem. What are we going to do? Alex is the best name. We'll both just respond to everything. It'll be great. Yeah, we're both designers, both Alex. We can just answer all the questions you might have Christian. On the other hand, I was thinking you are the Italian so we could call you for example Alessandro or pasta al dente. I don't know. Okay, let's go with Alessandro. I'm happy with that. Great. Especially if you use this German accent. I thought it's Italian accent. Alessandro. I'm fine with Alessandro. Let's talk about Alex Wheeler. So Alex, you are a passionate designer since more than 10 years. You worked for more than six years as a digital designer before you start expressing yourself in the area of user experience design. And you are working now at Riot Games, the company that has developed the most played online game on this planet League of Legends. It's a pleasure to have you today. And Alex and I, we read your Medium article about defining and building user experience in computer games. And we were so curious to hear from you how your daily life looks like at a gaming designer. And we would also love to know how the whole process of developing this product and features within that product work. Yeah, absolutely. Yeah, I've been at Riot for more than four years now. I've worked on a bunch of different teams at Riot and UX is a space I'm passionate about. I think everybody on some level is passionate about UX, right? Everybody hates using bad products. But not every team at Riot works identically. But in general at Riot, it really depends what phase of the project you're on. So we can start by just defining like the different phases of products that exist, what we do at each phase, and then I'm happy to dive into any of them. But really, in any given project at Riot, it starts off in discovery. Because when you think about design and like building a product and working as like a product designer, there's infinite things you can do, right? There's infinite problem spaces, there's never a shortage of problems to be solved, especially in the gaming space, or in a game like League or in a game like Valorant, or any of the products that Riot makes. And so we start off in discovery, which is really what can we do? What should we do? And that involves a lot of talking to different people, aligning with stakeholders. And the design tools we utilize at that step is really a lot of alignment tools. So a designer's superpower is communicating via pictures, right? We do pictures better than most people. And so that's low fidelity wireframes, sketches, storyboards, you can utilize whatever thing you're most comfortable with. But that's the you're not trying to sell somebody on a specific direction, you're just trying to communicate an idea. And then the next big step is vision, right? After you've gone through discovery, after you've found where you want to focus your efforts on, you have to try and convince the rest of the world, and all the people with all the money to give you that money so that you can create the change that you want to see. And almost all the time, that involves creating a vision so that you can align developers, product owners, business people on what the world is going to look like after they have funded your project. And that involves a lot of, again, storytelling, right? This wireframing, user journey maps, user journey flows, and even a lot of times in vision, you can do backlog generation, maybe your dev team's rearing to go, and you've got a very compelling set of screens already designed and wireframed out, and you're communicating with developers in terms of technical feasibility. And so then you might do backlog generation, where you're walking through a user journey, trying to determine what stories actually need to go into Jira or whatever tool you use to track your work. And that's the vision step. Before we dive into each step in detail, I'm curious about the overall user experience within that game, because I used to play eight years of my life World of Warcraft, just saying. I still play well. I was playing today. Very nice. I was also thinking of just going back, but I'm still strong. But I also played many years League of Legends. And something that is, especially we as gamers know, that you're sitting from eight in the morning till midnight, you're just sitting there and playing the game over and over again. And the reason you're playing this is because you feel comfortable. If the user experience or the user interface would be shit, you wouldn't play it. And what I would love to know is, how are you getting to the point where you can deliver this nice experience and make people, let's be frank, addicted? That's true. It's actually funny. It's counterintuitive. The experience of playing a game starts when, not when you're playing the game, but when you decide you want to play the game. So for our different user groups, you have a new user who has never played before, right? Their experience probably starts on a Discord call with their friends who are playing the game, or maybe on Reddit, or maybe somewhere where they find out about the game. And every moment after that is part of the user experience designer's job, that website, that download speed, the install time, all of that. And none of that is why you're playing the game, right? None of that contributes to the addicting nature of the game. And experientially, what contributes to the addicting nature of the game is friction, which is counterintuitive to a lot of UX designers, because generally in tech, UX design is about reducing or removing friction. In games, in a particular game loop, it's about adding friction. Because if everything is seamless and smooth, the gratification you get from getting a little bit better at casting that spell, doing a little bit more DPS in WoW, or in League, CSing a little bit better, it doesn't feel as good. But if you can watch yourself get better at something that is difficult, that's addicting. People love the feeling of improvement, and that's good. So that's the difference between designing UX for a game specifically, then maybe the products around the game or the experience around the game, because in game, you're really designing intentional friction. But when we speak about intentional friction, which role is like user experience? And which role is like actually like writing also the story of the game specifically? How does this mix and match also the different roles? Yeah, absolutely. So for League, which is the product with which I'm the most familiar, I can talk about champions. So I worked on champions for a while. And our champions, Riot has a lot of articles about this, which I encourage people to go read. They're super fascinating. But there we have a narrative person, a part of the triangle, right? We have a narrative person who's in charge of thematically tying in the concept that we're working on to the rest of the game, the rest of the world, making that narrative feel real, relatable. A concept in games in general is thematic resonance, meaning you look at a piece of art, or you look at a champion, or you look at anything, an armor piece, and you feel attachment to it, because you really like it. Maybe you love medieval stuff. And so that alien doesn't really appeal to you. But that knight is oh my god, like, having never even played it, you just look at it, you're like, boom, that's me. That's thematic resonance. And the narrative designer has a large responsibility there. The other part of that triangle is art. And there's all kinds of art. But when it comes to games, you have concept artists, you have 3d modelers, you have VFX artists, you have sound people who are very much artists. And all of those combined create the visual and auditory representation that is a champion in the game. And they work very closely, obviously, with narrative to create a cohesive thematic package that resonates with a group of people. You have design and design is broken down into I think the question you were asking is their systems designers, aka game designers, or champion designers. And then there's UX designers. And the difference, UX and game designers are very similar. We're both user centered design disciplines. But the difference is game designers and champion designers tend to be very much systems focused. You're focused on how does this ability interact with every other ability in the kit? How does this kit interact with all of the kits in the game? How does this champion relate to these champions? How does this champion work in this role? If you're a damage dealer, how does this champion relate to all other damage dealers? Does this also relate to the story of the champion as well? It very much can. Yeah. Okay. And so all of these things, these triangles of narrative, art, and design are all worked on at the same time together collaboratively. Because you can't really do one without the other. A designer will come up with opportunity spaces. A systems designer will come up with opportunity spaces. A champion designer will say, hey, we don't have these play styles in the game. I think that these could be opportunities. And then the narrative designer will be like, yeah, actually, that play style matches with this narrative opportunity. And a concept artist will sketch out a thing. And then everybody will be like, holy shit, how'd you make that? And that inspires people to go. And that's how it goes. It's a very organic, very iterative, very collaborative process. And how do you move from, for example, an opportunity to a launch of a champion? Let's say you identified there is a champion that has the potential to disrupt the game. How do you, and especially what is your role in this process to get there as a user experience? Let's combine that. Yeah. So, as a UX designer, I have, in my opinion, the easy job. But I think everybody thinks that. Everybody thinks what they do is the easy thing. But yeah, it really comes down to a champion designer will come up with an opportunity. They'll be like, cool. Here's my idea for the opportunity in written words. It's called a paper kit is what we call it. Everybody has different names for it. But it's a set of written words that describe what the opportunity is, what that champion could be. What are the different abilities? Where do they fit into the game? How do they relate to other people like that? And then they all work together to create a testable, playable thing very early on. You want to get your hands on it as soon as possible. And that's when UX comes in, right? Because maybe a particular ability that the champion designer is very convinced systematically works in the game and would be a fun output from a systems point of view isn't immediately intuitive or doesn't feel very good to use. That's where a UX designer would come in, right? Maybe there's a UI that needs to be created for several champions. There's UIs that need to come in to sell big moments. There's overall experiential feelings. Maybe a particular champion I worked on walks through walls. And the systems design portion of that is we want this person to be able to ignore terrain, which creates these types of moments in the game. The experiential output of that is it doesn't feel very good to play against because somebody's just appearing and killing you. And so designing the visual communication of what does it look like when they're in a wall, when they're approaching you? How does that ability feel to use? That's really where the UX designer comes in and helps. I hate that feeling when someone comes out of the wall and just kills me and just kills you. What did you thought about that? At the same, it's like we talked about introducing friction. If I can walk through every wall, like it's pretty much friction. Friction is a super interesting topic. And I really encourage a lot of designers or even product people who are thinking about ways to make their product more engaging to actually look into a lot of gamification or game design articles, because the intentional design of friction is fascinating, right? Friction is inherently not great. And most people would agree on that. And so when you can get somebody to design friction in such a way that turns it from bad to good, that's just impressive to me. Is Riot organized or are you organized in a way that you develop these opportunities exclusively internally or are you also moving to the users and getting feedback or getting inspired to enhance the game? So testing again for champions is every day. We internally test it on our team multiple times a day, and then every other team also tests it. And a lot of times those people have no context for any of the decisions, why we did this, why we did that. They just experience it and they give us the raw unfiltered feedback and everybody at Riot is a gamer. Does this mean like playing the game multiple times a day? Yeah. So once we get it to a point where we think directionally, this is accurate, this is achieving the goals we want it to achieve. And a lot of that's determined by the game designer, not the UX designer. But when it gets to a point where it is good, we work with a group called Insights who are just awesome researchers and they run user labs where we bring, we actually bring people into Riot, into labs and we have a testing area that we can watch them play. We can, we have eye tracking software. We sit in another room with one side of glass, like we watch the way they interact. Where do I need to sign? Where do I need to sign? I have no idea how people get in on that. I have no idea. But yeah. So we'll actually bring users in. We'll watch them play. We'll get their feedback. And something that a lot of people don't consider is like when you're designing an Amazon or a Google, there's not different levels of users like gold, diamond, silver, but in it, in a game there is right there, you have your iron players all the way up to your grandmaster players who are playing professionally on stages in front of millions of people. The game needs to make sense to all of them simultaneously, be equally usable to each of them at all of those skill levels. And it needs to function in 26 countries around the world. So do you use any framework like personas to like, really always keep all the different kind of gamers in mind or? Yeah. Framework is a really popular term at Riot. Everybody has a framework, but yeah, it's audience types, which is like the core of what you're getting at there is huge, right? It's really important to keep the different audience types in mind and it goes beyond just skill. Skill is one vector by which you can segment an audience group, but there's also thematic resonance, right? Some people really animate and they're going to attach to these types of characters. Some people really like different types of themes and they're going to attach to these types of characters. There's also like roles, right? If you've played League, there's multiple different roles in the game. Some people are only interested in mid lane or top lane or bottom lane or jungle. And so that's another way to segment the group. And then you can bifurcate those segments with like, here's jungle users who are of this skill level, who like this type of person. So different variations of potentially one kind of persona. Exactly. Yeah. Interesting. Interesting. Yeah. But do you optimize for one specific audience or is like, really, do you constantly challenge yourself also? Does this work for everyone? Game designers have a much harder job than UX here because UX is like humans are humans. So like the usability is across all of those different groups. But game designers, they have the biggest challenge here. But from my understanding, generally, they try to over serve one particular audience group. Because when you're designing for a particular group of people and they're going to really like it, at least even if it doesn't resonate with everyone, a group of people are going to be really happy and they're going to associate with it. And that's another way to pull different people from other groups into that group. If you're over serving one group really well, you can potentially get other people to expand their horizon. If you want to get something very quickly developed to be able to have something playable, how exactly is this process looking like within Riot at the moment? On game teams, it's different team to team. On my particular team, I actually work between games for all the different games. It's different for us. But on a particular game team, if you wanted to prototype something really quickly, I'll say League, for example, if I had an idea, what I would do is probably either whiteboard it or sketch it up really quickly at a very low fidelity. Something to get my idea across. And then I'd probably implement it in-engine in a very sloppy way. It depends how early on or where we're at in the process. But I'll put it in the quickest, sloppiest way I can so that it accomplishes the thing. Because at this stage, I can walk up to the person testing it and be like, look, I know it sucks, but you're gonna have to do this and this. Try to give me feedback on just the way it feels. And so I have the ability to get people to ignore a lot of the jankiness of the implementation. But that allows us to quickly test things. Like I could do that at 10 in the morning and have a test done by 1130. And I could get real feedback really quickly, really iteratively. That's the benefit of playing the game multiple times a day. If you're trying to test something, you're not just playing to rank up and have fun. You're playing the game in a fundamentally broken state. Like a lot of these things aren't balanced at all. And so it's not necessarily always the polished experience that you've come to know and love on live. It's for better or worse, it's a pretty broken state of the game, but it allows us to test things quickly. And just to reiterate that it's a lot of sketching, quick implementation, and then testing. And then outside of a game team, on my particular team, if we really wanted to run a test quickly, we couldn't run it as quickly as a game team does, to be honest. But we would take wireframes and we'd probably take them to a medium or high fidelity. And then we'd use a tool like usertesting.com or we'd work with our developers, because a lot of the UX people on my particular team aren't super technically focused. So we probably work with our development team to produce us a prototype using those wireframes that feels real, but not finished. You know what I mean? You're not trying to convey to users like, hey, we're going to ship this, but you're trying to say, if this was real, how would it feel? But so coming back to the whole process, because you mentioned earlier, there is a discovery and then you would pass it over to the vision. I think maybe before moving to the vision, if you would have to summarize also the discovery phase, what are the key things that you need to look out when looking at discovery for games or in the gaming world? For sure. For me and my personal experience at Riot, it comes down to problems people are having. So going and meeting with people who are experiencing the problems you're trying to solve and getting a deep, intimate understanding of that problem. Because nine times out of 10, the problem being described to you is not actually the thing you need to solve. It's a symptom of the thing you need to solve. And that's your job as a designer. A lot of people give reverence to designers as the only people who can do this thing. I'm like, actually, everybody's a designer. The difference between a professional designer and a user is we should have the ability to articulate what we're experiencing or dig into what other people are experiencing in a way where we can identify the true underlying issues. And that's really the challenge of design. So in discovery, that's really what you're trying to do. You're trying to get a deep, intimate understanding of the problem spaces that you're interested in solving and identifying what the actual problems are. Because a lot of times, maybe you're looking at three or four different things. Maybe two of those things are actually the same problem. What are the techniques to get that out? We do a lot of user interviews, and then we take those and we try and construct what's known as a user journey map. I think a company called Adaptive Path has a really famous example of what a user journey map looks like. So just Google Adaptive Path user journey map if you're interested. But it's a very intentional breakdown of each step of the user journey. And then within that user journey, it's like, what is the user thinking? What is the user physically doing with their hands? Are they moving their mouse really rapidly? What are they doing on screen? And it's every little breakdown at each step of the user journey, what's happening. And this helps you have a really clear idea. of what's going on. But more than that, it's an artifact that you can share with non-designers and other business people, other product owners. You can take it and now you can communicate with a concrete thing rather than a he said, she said telephone game, which never goes well. Yeah. Yeah, I actually just recently had this where we worked with user journey maps and the client was like, really? Oh, okay, cool. That that really helps me understand the different steps and especially like working also or thinking about bringing in the emotions that users have in individual steps and looking at what exactly they're doing. It can help you like really get into exactly the details. Yeah, yeah. Artifacts like that are super powerful. You also mentioned the collaboration with the development team. What is your role looking at them? You also mentioned there's there are product owners, which is a word that is more common in Europe, I thought, the product owner, then the product manager, but... Yes, there's product owners. There are also those product managers in games or media. They're sometimes known as producers. You'll hear all of these terms used interchangeably. And somebody's gonna get mad at me for this, but they generally mean the same thing. Everybody's job is different, but generally. Yeah, so the third phase that I didn't touch on, so there's discovery, there's vision. And then the third phase is execution. And for me as a designer, this is where I'm accountable for handing to development a set of designs that is executable, that is developable. And that involves a lot of different things. I can't just hand a set of pictures over to people and be like, good luck. I'm responsible not for making the pictures. I'm responsible for the experience that ships into the world. And part of that is working with developers to build it. And so taking those screens or those wireframes into a fidelity that's high enough so that I can work with developers to implement it, and then work with QA to test it. Because a lot of people think of QA as the people who find just the bugs. And in some companies, that's true. At Riot, it's not true. QA is directly embedded on teams, and they're like the superheroes. But at Riot, UX works with QA to make sure that what is built and what is shipped matches design. It matches UX intent. It matches visual design intent. And we have a quality bar that we shoot for, and that quality bar changes depending on the team, the capability, and the product, really. But when you're shipping a product to 120 million people who are going to use it every day in 26 countries, you don't have a lot of wiggle room. And if something goes out into the world broken, it's not the QA person's fault. It's not just the engineer's fault. Everybody is a quality owner for whatever they ship. And so for me, it's design. And so when an experience goes out into the world, I have to be accountable for how it's going to be. And part of being accountable means I'm passionate about making sure that the developers who are building it have everything they need to succeed. And then after they've handed that code off, the QA people have everything they need and have my input to make sure that it looks right. So yeah, that's where the execution phase comes in. I do love your mindset here. But on the other hand, I'm just a little bit confused because what you're telling us is that there is a huge collaboration going on between different teams, between different departments in parallel to make sure you can ship this, for example, one new champion. As far as I understood, there is huge efforts going on around that whole project. When I now look into companies next door and just seeing like a bunch of people who have the same goal, which is working for the company and building products, whatever it is. But if you then look inside the details, many people doing different things in a complete different way, and there's absolutely no alignment. Why is it so aligned in a gaming company? And why doesn't it work for normal companies? What is the difference? It's a million dollar question. Because we're not sure if it's so aligned in every other gaming company. You're absolutely right. And to be honest, Riot doesn't get it right all the times either. I think our audience will tell you that more often than not. I think a lot of things contribute. At Riot, everybody is a gamer. So we all use the things at the end of the day. And so if something sucks, you can be guaranteed the person who makes it knows before Reddit even puts a thread out about it. But they also pay attention to that stuff and it matters. I frequently think of the problem you're describing as everybody sitting at a table saying we're aligned but with different shapes in the little bubbles above their head. At Riot, I think when it goes, people are aligned because product owners, people who hold the high level vision for the opportunity space, designers and engineers are all working together collaboratively in a good way. People are aligned when design meets technical feasibility meets product opportunity. And if those things are all going well, if you have a design lead and an engineering lead and a product owner who are all syncing regularly and have working knowledge of what the expectation is, what the thing we're delivering is and when it's being delivered, I think alignment is actually, I'm going to say this and it's definitely not true, but alignment is actually easy when you have people working well together. But alignment is probably the hardest thing in tech, to be honest. But I think where what you, Christian, are also seeing a lot is, and we experienced it ourselves, that when you work for a product that you're not using on a day-to-day base, it's also much easier to be misaligned or to ship something that's maybe not 100% finished. Because just speaking about, I don't know, you build a product for businesses, you yourself are never really worked behind a counter in a shop. You don't really care if there's a small bad thing in the user experience. Obviously, like what you're saying, Alex, is like when you use it yourself on a daily basis, it's also easy to convince your developer, maybe this one is a better experience than the other one because they really feel it and they really see it. Yeah. And in that regard, you're absolutely right. The place I was before Riot, I was doing design for industrial enterprise machines. So there aren't a lot of people who operate oil rigs in the South Korean sea. And there's six of them, to be honest, and they've been doing it for 40 years. And so when you get a task that's, hey, of the six people, four of them are about to retire. We need new people to come in here, but none of them can use the software. And you look at it and it was like 1985 design. It's super easy to improve. But should you? Because if you make a radical change, you move this button over here, and then something goes wrong and that person doesn't know the buttons there. That's a catastrophic failure on an industrial scale. When you're working on things where you aren't the user, and where alignment is really hard to get because the use case is so foreign to everybody involved in the making of the software, it's a lot harder than in Riot's case, where pretty much everyone is the user of what they're making. And so that context is deeply personally felt. Are you being evaluated on your gaming or league skills when applying at Riot? It depends on the team. 99% of the time, no. But if you apply to the test, the gameplay test team, yeah, you have to be exceptionally good. Most of those people are former professionals or current professionals. A lot of those people on those test teams are just absurdly good. Even the champion team, most of the champion designers I worked with, for example, I'm like platinum. I'm really good at some other games, but not league. I'm like gold or flat. A lot of people I work with are like diamond or masters players. I never got a contract from SKT, so I said, okay, then I will stop my career and will not beat Faker from the mid lane. But I think we're getting too nerdy here. But talking about the pro players, how about, we're talking about a complete league and I'm pretty sure that Riot is also making a lot of money with all these events and stuff like this. Is there a separate treatment for this pro players and how is the interaction with these guys? Yeah. So there's a really interesting phenomenon in gaming where in tech you have this thing called affordances, right? Which is once Amazon publishes an interaction pattern or Google publishes an interaction pattern, people, so many people use it every day that it becomes expected. And if you do something similar in a different way, people are upset because they don't know how to use it. In gaming, we have a group of users who are either famous, maybe they're influencers, maybe they're streamers, maybe they're pro players. And those people generally not all the time, but they generally determine a large amount of the way the game is played. If somebody if Faker comes out who for those who don't know is like the best mid laner in the world, he's very famous in the League of Legends community. If he comes out and this champion is really good, and you should play it with these items. Everybody is going to do that. Everyone around the world in that lane is going to play that champion with those items in that way. Even if it maybe isn't suboptimal, even if it maybe isn't the best, which it would be because Faker is amazing. And so it's really tough. I as a UX designer, I don't have to worry about this again as much as game designers do. They're doing the systems design and the people who inherently at that level are abusing the systems or exploiting the systems because they're just so good. They're pushing it to its absolute extremes. I don't necessarily think that the game is or any of our games are designed for exclusively those people. I think they try and make the game fun first, I just like as a base level for humans. And then they try to balance it around the fact that there are people who are insanely good who are going to push it to its absolute extremes. And then there are people who aren't as good and they're a vast majority of the player of the 120 million people, 119 million of those people are nowhere near diamond level, right? Like the people who are like diamond masters, grandmasters are the 1% and like grandmasters, like the 0.1% of the 1%. And so making the game for those peoples for just that group of people is just not, it's probably not like a good business decision, but trying to just make a fun game and then balance it around your total set of users. I think is more the goal, yeah. And if you say the baseline is it needs to be fun and you're trying to design a fun game, do you have any way of measuring that besides, let's say, the qualitative aspects of playing it yourself, seeing other people using it, playing it? Are there some KPIs? That's a super good question. The answer to the question, are there KPIs, is always yes, and many of them. The answer to are those KPIs good is always maybe. When it comes to what does fun mean, what is fun, that is a question that game designers academically have been trying to answer for a long time. And nobody's going to tell you the same answer to that question, so I won't even try. But I will tell you that when it comes to measuring performance, yes, we do a lot of it. We measure how many people are picking this champion, how many people pick it multiple times, how many people pick it like X number of times, all the way through. If somebody picks it day one and then doesn't pick it up again, we measure that. We measure how many times does somebody play it repeatedly? And then of those per total number of people who have ever played it, how many people have played it more than X number of times? And then also, there's just a measure of feedback, which is like forums like Reddit or the League of Legends forums or other places around the world. They're made for hating, which is a whole different topic, right? Like people who are angry are really motivated to type, but it doesn't necessarily mean they're always wrong. But it's also feedback that's hard to measure objectively in an Excel sheet in the KPI. Somebody says, this isn't fun. It's they're just a random person who said it's not fun, but they probably have a reason they said that. So digging into those things is really tough. But yeah, absolutely. The goal is always to try and measure how fun something is. It's just doing that is really difficult. I would say our game designers and our insights and our data people do an absurdly good job at doing it. And they do it by tracking a billion different data points across the board. Is there a data warehouse team or especially a special data team that you have focusing on this large numbers that are coming in? Because I'm pretty sure that 120 million users generating a lot of KPIs, numbers, and data. There are many data teams in many countries with many, yeah. There's a lot. Yeah. There's just an absurd amount of data to manage and handle and all of it's, or I should say all of it. Most of it's very useful. Riot isn't like a data driven company, right? It's a data informed company, especially when it comes to games and subjective design. It's not necessarily about how many people are clicking this button at this time of day, right? At Amazon or Google, we can very clearly drive KPIs around that sort of interaction level data. But it's more about having the data available when we ask questions that we can answer those questions and inform our path forward. And at least when you choose, Greg Street did an interview recently that, and tweeted that just, he's such a brilliant dude, but he talked about how it's not necessarily about using data to make an excuse for your design, right? It's about if you're going to go against the data, doing it intentionally and saying, these are the risks. And I know that because I have the data that shows me the way people are behaving. You said- These are great questions, by the way. Yeah. It's our job. We just got started with it recently. To some extent. But maybe, Christian, sorry, before I let you go with your question, just like simply speaking about KPIs, and you also used like the Amazon analogy, I think one thing that obviously that companies like Amazon that have a lot of traffic and can like really do a lot of data driven decisions as well do is A-B testing things. Is this something you can use in the gaming world as well? Is it like, okay, I maybe, yeah, okay, perfect. Yeah. How do you feel about that? It's less, and when we say games, I think it's useful to define. In a game, there's really two different portions. There's the actual game loop where you are an avatar, you have abilities and you're controlling it. And then there's the before you get into that game loop, you're in the client, maybe you're browsing the store, or maybe you're going through the meta systems where you're like doing the battle pass or the level up or talking to your friends and the friends list. And that alone, that client alone is like multiple designers and engineering teams worth of effort. You ask anybody what it's like to do e-commerce, there's a little portion of that client that's e-commerce. You ask anybody what it's like to do global publishing, there's a little portion of that that's global publishing, right? And so when it comes to things like, hey, we want to move the shop button over here and we want to do this, we absolutely do A-B testing. And honestly, we do A-B testing in every region because everyone's different. And that's something that a lot of people don't consider when you work on a product that's localized to one country. But people come up culturally differently in different regions of the world. And the way that America and EU use products is dramatically different than the way Russia and China and Southeast Asia, even like Oceania uses products. There's just fundamental parts of life that are slightly different or dramatically different that change the way people use stuff. So when we make a change to even something like the shop or maybe the battle pass, or maybe the way social works, we try to A-B test different ideas or against the standard in every region where we think there's a big enough shift in behavior that it's worth doing. For example, the social system in League of Legends and across all of Riot's games, because we have multiple games now, is different in China than it is in the rest of the world. It's the way your friends list fundamentally functions, how many friends you can have, what happens when you right-click on this, what happens when you left-click on that. It's different in China than it is everywhere else in the world, because they behave socially differently than we do. Where are the most toxic people based? Everywhere. I think for those who don't know, toxic is a term used in the gaming community to describe people who exhibit disruptive behavior, whether it's name-calling or saying disturbing things. Or just people who are just dying all the time and make you lose the game. Exactly. People who just decide that they're just going to die constantly so that you're guaranteed to lose. But we talked about the client side now. How about the game itself? I have heard many stories from people working in gaming companies, how gaming companies are differently approaching rolling out features to production. How is it going at Riot and what are you looking at? The, we'll call it out-of-game experience is, and in general, is very different than everywhere else in the world. Riot ships updates every two weeks. Most game companies ship updates once a quarter. Or if that. Depends on what your favorite game is, but you might only see an update a couple times a year, maybe three times a year. Ships updates every two weeks, guaranteed. And we hotfix things in between there, anything that's very broken. And we do that because the games Riot makes are highly competitive. League of Legends, which is our most famous game, the professional scene for League of Legends has more viewers than the NHL, the NBA and the MLB combined, right? The only sport in the world that actually beats us in viewership is soccer or football internationally. Yeah. And so if we change something in a sport that is that popular, it's a big deal, right? If you tweak the rules in soccer between matches, right? Like you have to be very careful how you do it because the perception of fairness is very important. And so in the actual game loop, A-B testing is less relevant because if you have a competitive game where people are being judged against the performance of other people, you can't judge them by two different sets of rules. For the out of game experience, like client stuff, it's very similar to traditional software. Anybody who's working on apps or websites or any traditional software, it's very similar. For the actual game itself, that's where it becomes a little bit more different. And that's where instead of doing A-B testing, you're doing a lot of iterative design, daily testing with users, bringing them in, trying to get feedback. Because once you ship a thing, it's in the world for better or worse. But going back to the client side, I think this is also where we can actually make the connection to the real world or to the biggest part of our audience who are building e-commerce software or stuff like this, which is to focus on your audience on A-B testing to make sure that you get enough data to really validate that the thing that you're building is either right or wrong or must be further iterated upon. Yeah, absolutely. And I think it's important for people to know like your audience's job isn't to, it's not to give you good feedback, which might sound weird, but your audience's job isn't to tell you what's right or what's wrong. It's to use the thing. And it's your job to interpret the usage of the thing as meeting your goals or not meeting your goals. And so a lot of people who skip out on the A-B testing step, I think are missing out on half of your audience at least is never going to give you feedback. They're just going to use the thing. And so observing how they're using the thing is going to tell you a lot more than the actual feedback people are writing in forums and stuff. Like you mentioned earlier, a lot of forums are just filled with hate and that's because anger is the strongest motivator, psychologically what happens in the brain, the reason forums are so filled with hate is people who are upset are more likely by a factor of five to actually take action on it than people who are satisfied or slightly less content. So most of the time, the feedback you're going to get in a written forum and forums isn't good feedback. It's angry, emotional feedback about something that is wrong. So I think A-B testing and putting in data points that you can pull data about how people are using your product, super important, highly recommend. I do have the feeling from the stories you are sharing with us that the whole cultural aspect is so important in your day-to-day decision making, because we're talking about different cultures, different ages, different type of people, different moods that people have. As a user experience designer, how do you try to combine all those things in your day-to-day business? Oh man, it's so hard. Like coming to Riot has been a huge learning opportunity for me. Like I've been here for five years. Everywhere else I've worked, I've worked at a lot of different engineering companies doing a lot of interaction design, web design, ad design, back in the day, like flash banner ads for movies. Most designers have done something like that. But a lot of that is for a specific thing in a specific place, and you never really have to think globally. And then all of a sudden you get to Riot and you're like, hey, we're gonna ship an account update feature. But in Europe, they have GDPR, which is a set of privacy laws that are only in Europe. We know this shit. In Brazil, it's coming, right? Soon. In Brazil, it's coming, but it's slightly different. America has its own thing. And it's not just the actual laws and implementation differences. The reason those laws came about is because of fundamentally culturally different beliefs or perceptions about privacy, for example. And those should inform, and it's hard, but that should inform how you treat your audience or the respect you show to your audience in certain situations. But now, to understand for everyone who has to design for multiple cultures, countries and so on, what's your approach when it comes to sharing or making also sure that insights are being shared with the entire company? Because I think you can make your learnings, but do you have also a place that you can access and be like, okay, if I have to design this, how should I best do it for China? Or how should I best do it for Europe? And this is what I learned. Where can you put it so that everyone knows about it and can use this learning? That's just such a good question. And I think on some level, everybody who's worked at a large company has felt this pain. And a lot of people are familiar with the term tribal knowledge. It's so hard to do well. When you get to a company, right, it's like 2,500 people or 3,000 people. For me, it's a medium-sized company, GE was 380,000 employees. So for me, it's a medium-sized company. A lot of people consider it a large company. Trying to, when I do a project, the scope of people that are involved in that project is it affects the whole company. But the scope of people that I work with day to day is like 20 to 50 people. And the learnings that I share with those people, it's really easy to share learnings with people who you work with every day. It's really hard at a large company when somebody is working on a different team that's no way related to your team and they're doing this thing to do that. And a lot of people have tried to solve the learning sharing problems with tools like wikis. There's a billion different wikis. I think Confluence is a really big one that people are probably familiar with. Sharing learnings is really hard. It's really difficult. At Riot, the way we handle it to the best of our ability is we have centralized knowledge repos where you can go and you can attempt to find whether it's raw data or actual learnings in the form of like presentations or decks. But then also every two weeks, we have design talks. So every two weeks, we have two designers from the company who come up and they share a thing. And a lot of times it's a learning that they had from working on a certain system, a learning that they had. We had a designer not so long ago who shared their experience. They've had to travel to China like 25 times in the last two years. They're learning from the cultural differences and the culture shock that they had and how if you have to work with Chinese developers or Chinese designers, here are the things you shouldn't say. Here are the things that you might say as an American. We say a lot of stupid shit that is going to be really offensive over there. And so just stuff like that. But to be honest, I don't know of a good foolproof solution other than if you have good deep learnings, make a shareable artifact, whether it's like a deck, a Google Slides thing, a PDF, make a shareable artifact and put it out there into the world. Like send an email to the company, put it on your confluence, do whatever you have to do so that if somebody wants it, they have it. Because yeah, there's just in a company of 2,500 people, there's probably one person learning a deep, important thing every 30 minutes. And you can't just give a presentation to the whole company every 30 minutes. Yeah. No, absolutely. The biggest challenge, and I'm working for a consulting firm, so you can imagine we have insights being generated. Pretty much every team is paid to generate insights and it's somehow also like our capital, right? What we built on. And one of my biggest issues is how do you keep it up to date? Because everything develops and you might have a deck. And the biggest problem is decks usually are static. And this is where the beauty of something like confluence comes in. But I'm not sure if you guys are using confluence. We have confluence as well, yeah. Just like also not the most straightforward tool to access or to find the latest and most important things. Actually to even write something down. Yeah. Come on, let's be honest. A lot of people always say to me when I talk about confluence, man, I wish it was more like Google. But I think what people don't realize is Google's not great at this either. Like Google any particular topic and you're probably going to get out of date information, right? Because you don't know what you want in the time period you want it. Like there's a specific set of filters. But you're absolutely right. Keeping stuff in or up to date is huge. I think designers in particular, maybe even product people, they're probably familiar with this in terms of design systems. Design systems are a lofty goal that anybody who works with design wants, but keeping it up to date is very difficult. That's why like Google has a whole team of people who do nothing but keep material design up to date. Amazon has a whole group of people who do nothing but keep their design system up to date. Microsoft, IBM. So all of these companies, they have full time human heads who do nothing but keep it up to date. I don't know if there's a better solution, but that's a good start. Design systems are definitely great, but then they also have the problem like you really need to make sure that everyone uses them because the second you have someone who writes his own little small components and hardcodes in something, you're already fucked. Yeah, exactly. Design systems are wonderful and for non-designers out there who are wondering how we got from sharing knowledge to design systems, it's because fundamentally the problems are very similar. But yeah, keeping things up to date, sharing things out and making sure that not only people align and use the thing, but that they use it correctly and consistently is very hard to do. Sounded almost like closing words, but Alex, if talking to our audience, we have many designers also listening in, what would be your three key values as a user experience designer that you would like to share with the rest of the world? Oh man, three key values. That's so tough. That you're considering. So many. You're getting paid for this. Come on. I mean, I'll accept that. No, I think. I think one, probably try to make yourself the user of whatever you're doing. Empathy is really key, building that empathy under like deeply understanding your users. It's key. And I think, I don't think there's a better way than to try and make yourself the user of that. So use your own thing as much as possible. I'd say number two in design school, you've probably in for the, anybody who's grown up in design, you've probably heard don't design for yourself. I think that's bullshit to be totally honest. I think you should absolutely 100% design for yourself. There's no better way to design because you're going to design the best possible thing. I think you need to be very aware of your biases, your habits, your patterns, and actively work against them. I think designing for yourself and then trying to consciously be aware of that is going to make you a bit better designer and it's going to make you more empathetic towards other people who are using it, especially when you contrast. I always do this, but no one else does. That's going to highlight for you things you should be paying attention to. And I think number three, and this is really important for people who don't work in embedded teams is as a designer, don't throw design over a wall. Engineers are humans. Product people are humans. Red lines suck. Work with those people who are humans to build the design that you want. Don't just make a PDF with pretty wireframes, with red lines, with a number of pixels and send it over a wall and hope that it turns out all right. Try to make yourself involved in that process and honestly try to bring those engineers into the design process so that they feel valued, so that they feel like they contributed, so that they feel like their opinions and voices are heard, because that's just going to make them more motivated to build the right thing. And they can give you early feedback on what's possible and what not. Exactly. Technical feasibility is super important. Great. So, Alex, it was really a pleasure having you. Alex. Great to be here. And I will jump into our debrief. And for you, I would say see you in Summoner's Rift. All right, man. See you on Summoner's Rift. Thank you so much. Great, Alex. Thank you. I'm pretty sure you might soon get an application from Christian. You send an application and I'll review it. It'll be great. Great. Work in progress. Amazing. All right. Thanks, Alex, again. Thank you so much. And have a great day. Welcome back, Christian. After this late interview, just for everyone, it's 1 a.m. in Berlin. So this is the dedication to give you the best insights even straight out of Los Angeles. Christian, this time, your turn. You're also the gamer between us. Are you going to pick up playing League of Legends again? He definitely convinced me to play this game again and also continue putting my money into it. I would love to actually have you two like playing live against each other. That would be fun. Yeah. Maybe we can still... We can organize it at least remotely. Yeah. Cool. But focusing on the topics. Yeah. Focusing on the topics. I think one of the most important things is that there is a huge difference between user experience or design in gaming companies versus normal companies. Do you think so? I just want to come to that point. When you focus on the product itself, it is... I don't know. Let me phrase it like this, the way he explained it, it should be like that in every company, which is not the case. So therefore I see a huge gap. Yeah, but it's actually impressive how much of an overlap there is. Like in my mind, game design was more like really only this part of like creative storytelling, having like artists designing characters and whole words. But seeing this whole user experience aspect, playing a role, both like in the gameplay as well as also behind whenever you're talking about outside of the game, everything that's like the shop, the chats and whatsoever. And the key thing is to really use the products that you're designing. And I still remember the coffee shop that we wanted to open back in the summer days to onboard. Employees to like really work with the tools. This is like the perfect example. Use it to feel the real pain points and you will probably remove all the friction or we learned like in gaming something that's good to add friction, but you will design. Which was, by the way, a very smart insight. This is something where we are hopefully able to inspire one or the other designer out there to maybe do the thing that you usually don't do and impress your people. But coming back to the point you said about using your products is definitely a must when you work in a product team. But what is even more important to me is the result out of this. So you have motivated people who are identifying a problem and really focusing in parallel on building a solution in a structured way. What we usually see is from our day-to-day business and from our past is there are many initiatives going on. Many people have different states, they're not talking to each other. And that was the reason why I also wanted to double check with Alex because parallelization and structure are the two things to success in my opinion when you are working in such an environment. Do you remember one of the things that I keep constantly bringing up and it's also one of the things that I always tell other designers in my team is this and having also the empathy for your co-workers and understanding why they're doing things. What we see in the example of Alex, the team members, they all work towards the same goal because they all work towards a better experience in the game. While maybe a developer in a more traditional product company who's not using the product you're either a very good storyteller that manages to convince the developer that this is a real problem and to really give him the intrinsic motivation to solve this problem. Otherwise, he will work for other goals. So it's really also about making sure that everyone really has the same understanding. If you don't have a goal or if no one is giving you direction, you will start looking for your own goal in your own direction. And this is usually the point where we start. Probably even before you probably have like your own goal and you need to align those goals and do it either through storytelling or in this case by simply all using it. And you will all try to avoid to have any user experience issues in the tool. One big takeaway that we should definitely highlight is make sure you use your own product and try to make sure that your colleagues are interacting with it as much as possible. I know it's easier said than executed, but if there is any kind of chance to motivate your team members to use it, just really invite them to do so. And communicate, communicate, communicate. I think that's also something that at least from Alex Daris sounds like Riot is doing really well. I agree. With that said, I think I'm also doing very well right now and I'm feeling ready to go to bed. How about you? Same. Tomorrow is another lovely day. Workday again with new episodes. True. So I would say hello at product-bakery.com for feedback. For any feedback. Yes. Feel free to follow us on LinkedIn, the product-bakery podcasts or on Instagram. And with that, I wish you all a great night and speaking to you next week again. Thank you, Christian. And. Goodbye. Have a good night.