Designing With Player Segmentation Data At Next Games

Knowledge / Inspiration

Designing With Player Segmentation Data At Next Games

Continuous Discovery
UXDX Community: Helsinki 2018

Jasmin will talk through player segmentation of the game 'The Walking Dead; No Man's Land'. Jasmin gives us a top level viewpoint of player segmentation from a UX designer perspective - how they do it and design and the feature pipeline based on what they found from the data.

Jasmin Dahncke

Jasmin Dahncke, UX Designer,Next Games

Designing with player segmentation data at Next Games.
Yes, I'm from Next Games, and today I will be talking to you about designing with player segmentation data in our game, 'The Walking Dead; No Man's Land'. And it will be a really quick speed run. And we will really look from a top level view, because I'm not a data analyst. But I will show you what the player segmentation is and how we do it. You know, roughly and then I will show you how we design. I will show you a little bit about our feature pipeline, how we make a feature based on what we found there.

So let's get started here. Yes, agenda, let's start with a quick **Introduction. **I'll tell you a bit who I am, who Next Games is, then I will tell you a little bit about Games as a service, because that's the business model that we are working with. And then we are getting to the segmentation and the **Feature development pipeline. **

Yes, my name is Jasmine. I'm a UX designer at Next Games, I have a background mainly in graphic design, I always worked in the games industry, and I worked a lot on merchandise. So I did a lot of magazines and book packs back in the day. And then 4 years ago, I entered the game industry as a UI artist and made the transition to a UX designer, because Information Hierarchy is really what's at when my heart has said, you know, creating an experience that is understandable and enjoyable to our players. That's what I do. And the company I work for is called Next Games, we mainly do games for really big franchises.

So let's start...

So we work really closely with license holders to bring these TV shows or cinema movies or books in a game experience to the fans. That's what we do.

Here you see some of our games. One of the first games we did was 'The Walking Dead; No Man's Land'. It's an RPG game, based on The Walking Dead franchise. And we are actually making another game with this franchise. This time, it's a Pokemon go kind of game. It's a location based game. So that's something really exciting. And you also... And one of the other IPs currently is Blade Runner, but not much more has been announced about that.

So yeah, that is something we are working on. But the game that I'm going to talk to you about is actually 'The Walking Dead; No Man's Land', and I'm actually thinking that this video might not work, I really wanted to show this to you. Okay, but that's fine. It's basically... How many of you actually play games? Could you raise your hand so I can see how I need to explain that? So quite many of you play. So this is like a strategy game, where you direct your characters in a turn based manner towards zombies and fight them. But because it's turn based, you have a lot of time to think, "Hey, how am I going to do this move", and then you figure out how to fight them. And because it's based on the IP, we have a lot of tie-ins with the show, you know, we have the content, you can revisit locations that you have seen in the TV, you know, you can fight the same bad [phonetic 03:24] as it's like Neguin, or you can fight as Rick. So that is what it's all about.

Games as a service

I want to give you an introduction to this because it's really important to why we do segmentation based on this business. So it's called games as a service. It's not really new, I think every one of you knows free to play, for example, it's a continuous revenue model. It is really different from how classically games were made, you know, you had a really long pipeline for a couple of years, you made a thing, and then it comes out, for example, God of War then you want, it took 5 years to make this game, and then they are then you are purchasing it for 60 Euros. So you have made an initial sale, and then you can kind of forget about it.

Nowadays, even a game like that gets patched. But back in the days, you know, this wasn't the case. But you know, nowadays with the mobile phones and the PC in your pocket, you know, games have evolved to this kind of devices and one of the revenue models that came with this, is this free to play games as a service that really took off because it's really easy, of course for people to try your product if it's for free to get, you know, to find out if they like it or not.

So something that is also pretty comes usually with these kinds of products is that; it's a life product with continuous development and you usually wanted to have a really long life cycle to basically pay back the initial development costs.

Yes, let's move forward. So something about the key performance indicators about this kind of business. So this is how we measure our success kind of based on these KPIs. Why are these 3 KPIs important? Because our game or our product being free, initially, there has been no sale done, like in the classic video game business. We really need people to come back, we need to retain them, you know, through engagement also, and we need to convert them basically, at a later time, not through the initial sale, but they are coming back. And then they are making a purchase at some point based on something that they had fun, you know, based on the cosmetic maybe, or, you know, something other game related item that they wanted to get.

Yes, also something I really wanted to tell, regarding this business, you know, I don't know, most of you, I guess, make apps that maybe solve a problem for others, for example, musician, makes an app where I can learn an instrument, or, you know, there are apps that book me a cap, you know, we're making a game, we are not really solving a problem for people. So it's also much easier to drop something like a game, it's a pure entertainment kind of thing. You know, it only does something like entertain you, and you can have some fun by playing but it does nothing else in that sense.

So yeah, you can quickly forget about this and De install, if it doesn't work. You know, there is no backlash for you, you know? So that's important to understand also, when making a game, I think, yes.

So let's get to play a segmentation. And that is actually related to how good we get this? So we have these KPIs, we have this business model, people don't need to pay anything literally, then we have these KPIs like retention, engagement, conversion, that kind of, you know, these need to work so that our business can be successful. So how can we design with these on our mind or around them, and that is where this whole segmentation thing comes in, where we have a lot of data analysts who help us, who do initial research for us, and find things regarding these KPIs that we can improve.

So what is segmentation?

It's basically about finding out who's your audience, who's using your product? You know, where are they spending time in your product? You know, for example, our game is really big, it has a lot of features. So really, seeing from your data, okay, where are they? And what are they doing, how are they progressing? You know, it's quite important to find out. That is what this whole segmentation thing is, and I think most of you have done the transition to be really data driven companies, and it's the same for the gaming industry, basically.

So this game audience, how can we identify different segments? We made a really basic approach. For example, this is like, I think two years ago, now, we were thinking, "Hey, what missions do our players actually play?" And let's make a segment based on this, because, you know, we have a lot of different missions in our game, because we have so many different features to fight zombies in all kinds of ways. So we are like, okay, let's make segments based on the missions that they're doing. And additionally, we can ask other questions, for example, so you have these kind of audience segments, or player profiles, we also call them, so how do they actually progress related to the segment that they end because, you know, people are aging or like, also maturing throughout your product lifecycle, the longer they are staying in there.

So you know, they're not just going to stay in the same segment sometimes, you know, they are moving maybe from a beginner to a more advanced or elder player, we call it and they do different things in the app because of.... For us, it's about, you know, your progress with your avatar or your player level. So other features will be available for you that will be much more interesting, for example, and that is what this is all about, finding out how do they progress transition, and of course, important is also for us, you know, how are the segments spending, because, you know, it's free to play, we really need to understand, okay, and this comes also from a way of not just monetizing as good as possible, no matter what, but it's about finding the fun and the engagement and something so that you know, that you value this kind of visual and coin that you are saying that it has an inherent value for you to buy and you feel good about yourself. And you're like, "Hey, I bought this cool skin and it makes me look really cool. I really enjoy myself, you know, this is what this is about".

So this is what our data analysts did. They took one week of data, it's basically a snapshot of our game in that one week. The main measure was, "Hey, what missions do these people play? They use a lot of other techniques like clustering and stuff. I don't really know about that. And that is a whole other presentation. You know, it's crazy what you can do there, they are so smart, I can't even understand but it's really cool stuff that we get from them, what they read from our app."

So this is what they found. They found five basic player types. Story players, challenge players, the names are basically based on our features, you can I guess....

Story player

There are story models where you play, where we have our own part of The Walking Dead World where we are written little stories about...

Challenge players

This is a multiplayer feature where with your friends, with your guilds, you accumulate points from specifically designed zombie maps, for example.

Grind player is again, another feature you are just you know, grinding away in one specific mission that has very specific drops that you are after, and PvP, it's player versus player mode, where people basically fight against each other.

And what they found is these four, they are super engaged, they play 5 to 20 missions, they spend pretty well, you know, they do all the things, all the right KPIs, you know, retention, engagement, conversion, all working well. And then they also found this out layer, they call them the sleepers. So we were like, What is going on that they are spending not a lot, and they are also there, because they don't have fun, they are playing one to two missions a day? And it's like, okay, maybe we should investigate what's happening. Why do these guys have this erratic kind of behavior, not logging in so much and playing so much?

So what we found when we looked a little bit more, and here, you see a transition, what we looked at, what we asked ourselves, "Hey, so how does this player transition throughout his life?" You know, does he actually become one of the star players or the others who are heavily engaged, but it turned out that either they stay the same, they stay at the same level one to two missions a day, or every couple of days, or worse, even they churn. So okay, in really big amounts.

So, that was like, kind of an alarm signal, we were like, Okay, we need to understand a little bit more about that. So something that we knew about them from the player types was that they mostly play story. So the one reference we had was story players. So we were like, Okay, we check this for the sleepers, how they transition throughout the player profiles, let's check for the story players, if there's anything different for their kind of life cycle, and how they transition through the profiles, and it turned out there were ups... Almost really... It was scary, there was almost no difference, they transition exactly the same, and these were really engaged players, you know, we saw that they were really playing a lot every day 5 to 20 mission and, and they are also turning into either asleep, or ensuring or into a churn play and never coming back.

So we know, okay, something's up with our stories. What is it that we need to take a look at? And what we found is, when we took a deeper look at what's happening there is that the story players, it's the first feature that we introduced in our product. So it's a very early game, so very young players mostly. And it's really difficult for them to do anything else actually.

First, the difficulty arises. So playing this kind of feature does not happen so quickly, it's not so much fun anymore, because you need to level up a lot. But they're actually.... We didn't unlock, you know, other features and time for them to engage with them. So, they couldn't really do anything. So that's why we figured out, "Hey, we need to do something about it", so the accessibility was bad. And the transitioning to other features was just not given basically, that's what we found.

And those are basically the findings from this whole segmentation, we had a really distinct problem now, or a question or challenge that we could pose or impose on design that we could give the game designers, the UX designers, you know, we had all these transitions that we could show, "Hey, we have found the story difficulty arises. Other features are locked". And this goes then to the team.

So now the dev team can actually take this problem and act upon it. And that is what is happening now. The feature development pipeline. Okay, so this is what we do now.

Now they come and talk to us, usually we are already involved all the time with what is going on in the research. But now we get proper onboarding, "Hey, we have found this thing." So, you know, data analysts and game designers and UX as they are, like, you know, discussing what have been the problems? And now it's our job to find out how we can make this better for these sleepers? How can we alleviate the problems that they have been facing basically, throughout the research that we just did, and there is a lot going on here, actually, that is not in the slide, you know, you check in with your team, something that I saw a lot now in the other talks, and I can just repeat it again, check in with your team... You know, most commonly, they already know, kind of what's up, they have ideas already, they have experienced the same kind of pain points because they have played the product a lot, or they have interacted with your product a lot. They might have really good ideas. And that is what happened here for me. I checked in with the team, and they already were like, Yeah, we have this idea, we have known about this problem for a long time, because it's not only for early game players, you know, I have also seen from my colleagues that they had problems, maybe navigating the game finding certain features.

So you know, there were other problems that would also feed into this. So what we decided to do was a mission hub, and central access point that would help guide players through different features that would show you what you would get, basically, rewards. And in conjunction with that, we would need to balance and this is more in the game designers table, this difficulty and the unlocks of the other features. So there is better flow from the story to challenge or grind, what have you. They did a lot of things there, which is, again, another whole presentation for game design. But yeah, this is how it goes forward, we find ideas, we start to sketch out something, you know, when we had an idea, so you do a whole lot of this. This was the start of the mission hub, 'Hey! how should we present all this kind of information, what should be on the screen', so you do a lot of this, and then you do a lot more of that, you do the mock ups for the game, and you know, at every point of this, you know, I'm checking in with my team, also, I'm sharing these screens with them, I'm letting them know the things I learned or, you know, what problems Am I facing? And, you know, I feel like my job is so much easier when I leave.... I feel like I let them work for me, but it just helps so much to get a different perspective.

So what we then decided to do looked basically like this. So we were like, Yeah, we are going to do this, we have this mission hub, we have our cool content featured here, here you see your story, you see the rewards, now you can actually see all of our features laid out. Unfortunately, I haven't added a screen like it was before. But you know, there was nothing, there wasn't even... There were only icons in the game in the main hub, where you were playing and there were no names, you didn't know where you were going. You had a camp, you know, a little bit like Clash of Clans, where you collect resources and build buildings, and you didn't really know okay, what do the other things do? And you might forget, so now you had the central accessibility point, all the features, all the rewards, it also said when they unlocked with timers and what have you.

Now again, at this point, you have written something, you introduce it to your team, you know, for me, they are always my kind of gating process, do they like it, do they think I'm on the right track to solve the problem? You know, usually they are like, what is this? You know, have you thought about this, and why did you do this? And then you just keep iterating, maybe not everyone is happy, but till you feel like yeah, this really addresses the problem that we set out to solve when we started.

So yeah, and then we do something that we call a feature brief and I really recommend it's pretty good. So you basically sit down now that you know, you have a mock up, you have an initial draft of how this should work, and you write down the product goals. Again, you write down the user stories, you write down partly the components or how this kind of works, it's like a point of reference. And the thing is, you know, also we are agile and things, you know, change a lot. So this doesn't keep up to date, but it should basically have this initial idea of why you did this thing, there can be the research from the initial segmentation, the product goals should be there.

Even if you just have a small description, I think it's enough and dump the screens there. But you know, then there's something that you can share. Also, we have a lot of other disciplines in the company that need a point of reference, like player support, or like marketing so that there's something that they can check out, of course, they always still need to check in with the team, you know, did something update or not, but overall, it really helps. And I also think that the moment you write it down, you might still find things that you actually haven't thought about.

So it's really helpful. And then the production can basically start, that's when you know, what we saw earlier in the other talk, for example, that's when the sprint is starting, you know, you have a design spec ready. So, people can pick it up, and create something based on that.

So we formed something called a Feature team. And basically, there is someone from every discipline, and these people back end program, client program, or UI artists, game design, or UX and these people are responsible to make these things, they have, you know... It's all on that table, they are going to do it, they are going to do the decision state, they are going to do every additional iteration, they are going to do the user tests. I think, for us, at least, it really helped us have problems earlier, throughout development . Who's responsible for this thing? Who does this? So really defining a team of people who do this thing, it really just helped to keep things going forward.

So, yeah, they... Actually, I went over something, so they did a component breakdown. So now at this point, they also need to look at this feature before example, and they be like, okay, to make this thing what do we need, you know, all the logic, all the buttons, you know, you need to go through every single piece to see, how do we build this. And sometimes, you know, for a feature as big as this, you have an MVP, so you have something Minimum Viable Product, but then you also have something maximum, but, you know, half the features won't make it in, it's just how it goes. So they need to do an initial draft also, okay, what really makes it here? What is essential to this game experience and what we might add later or never usually, that's how it goes. And yeah, then you implement, you iterate, agile, you know, you've seen this before, but this is not how we will end, there's still a lot of iteration, we do a lot of user testing, what I do, for example, whenever we have something that works in a built, you know, I go into a small user test at my company, I just invite the whole company, I see who shows up in the kitchen, and we do half an hour. And you know, you are just there to observe and to ask some questions. And something that we also needed to learn throughout this process is never explaining to anyone your design, I feel like that is my biggest lesson over the last years. It's so easy when someone shows you a thing, and you are like, Yeah, but this is how it works. But you know, no one will be sitting next to your users and telling them, you know, this is how it works.

So, you just have to sit there and you have to be like, yes, I will write this down. And it's really a tough lesson. And it sounds easier than it is but not, you know, answering to this, you know, help, you know, to this request, people who seek help, you know, that's tough, and you need to go back with your team and discuss these things that you have found that don't seem to be so easy to understand for people.

Yeah, a lot of bug fixing, and polish if you have time. We never had time, for example, for this polish. But nowadays from the production side, we have allocated one week after every sprint just for that, because we never already have these features. It doesn't happen, you know, you still implement to the last day when there is freeze, but that doesn't mean you know, for at least for us, when there's the freeze for features doesn't mean that it can go out like that it's usually there's always some tweaking, some feedback missing some animation or what have you, you know, so, I have to say it really helps to allocate a little bit of more time to Polish basically before QA, it can also start at the same time the QA, but it helps to have a little bit of more.

So, you know, this is what we set out to do right, we wanted to have this cool accessibility hub, which we tweak the transition flows, you know, we unlocked features earlier and you know, what we ended up with, what is currently in the game for example, is this. So, you know, this is how it goes with the iteration, with the Agile, you thought you made this thing, and it kind of is still that thing. But you know, a lot has changed, you know, based on business needs or based on user feedback. So this is where we are at now. And yeah, that's it, you have the thing you release, and you know, it's not over, you need to wait, you know, play a reaction.. For us, for example, I do this kitchen kind of tests, small samples. If we are lucky, we have some play test clouds, some bigger samples where we can test but not always so, you know, now it's the time that you're actually seeing, does this thing work?

Again, in the past, we didn't allocate real time to react on what we may find after initial release. But nowadays, again, we have someone for one week after each update, who actually looks fixes not only stuff, but also looks at, "Hey, this thing that we decided to do is working to a certain extent for people, can they understand it?"

So you go back, you fix things, you add the missing feedback, that what you thought, "Hey, this is not maybe necessary for the MVP, but then you find out Yeah, okay, it was necessary. Let's add it". And for games, what comes in a lot, you know, it's about mechanics, how do certain things under the hood work? How do people progress? What do I need to collect to do the next thing? Also there, it's not always super clear, we need to look at that.

And, of course, if you have time to review the data, we did this feature, because we read the data research, and we found problems, you know, for this, for example, we never had time to go back and review that. Again, this is just how it goes. If you can allocate it, you know, I definitely recommend it.

Nowadays, it's like, we have so many other things in the game. It's also just really hard to measure. We have so many features in there and so much new stuff, it's really crazy. You don't really know exactly anymore. Okay, what is the one thing that tipped the scales necessarily?

So yeah, this is how we work. You learn about your audience, you segment the data, ask the data guys in your company to work with you, let them explain what they are doing. Maybe you can find pain points, then you can react to them, you can design solutions, create mockups, test with your team, "Hey, does it alleviate the problem?" You implement, you iterate, and you test. And that's really it.

So Data's MVP, that's my takeaways for you. If you have data analysts in your company, then you're already... Also you're really far ahead, you know, go and talk to the person, these guys are awesome. They can help you learn so much about these people that you will make the stuff for.... It's really crazy.

Second thing Feature brief, you know, writing down what you decide to do helps to understand it more find maybe flaws in what you have been setting out and, you know, more power to the team was feature teams and also asking the team, you know, "Hey, we wanted to do this thing". What do you think, you know, this is not just the thing that you're working on, and maybe it's stronger in games, I don't know. But you know, this is not my CEOs product or my marketing product. You know, we are doing this thing. So I feel like, trust yourself and trust the teams to know that they know what they are doing. Yes, and that's it. Thank you.