In this article, I’ll cover the core requirements of an ideal feature development process – and answer some burning questions surrounding them.

Hey everyone – glad to have you here. Today, I’m excited to be bringing you some of my thoughts from a conversation I recently had with Tom Hammond at UserWise. We sat down for an in-depth chat on his Mastering Retention podcast to get into all things feature design in Free-to-Play games: the development process, understanding audience motivations, and beyond.

The conversation had me sharing my team’s design process, my tips & tricks for leveling metrics up consistently, and my answers to some really common questions. 

If you'd like to check out the full interview with myself and Tom, please check it out here:

Here are some of the highlights from the interview:

Let’s start with an absolute truth: one of the biggest challenges us Free-to-Play game designers face is keeping our players interested. Not just through their first, second, or fifth gameplay session, but through their first months – and years – playing the game. 

So how do we double down on that retention? How do we ensure they’re not just engaged by the initial premise – but by each of the new, exciting tweaks and additions that pop up while they play?

The key is developing features. And not just any features, but relevant features. Features that appeal to – and matter to – your specific audience. Features that have been tested and molded to perfection. 

In this article, I’ll cover the core requirements of an ideal feature development process – and answer some burning questions surrounding them. Because if my eight years as a practicing Game Designer (at some of the most renowned gaming companies) have taught me anything, it’s that the best games professionals are constantly asking questions. And that our industry is always better when we’re learning together.

So first, let’s get into the feature development process. From research and ideation through to adjustments and final execution, the process stages my team and I follow are filled with purpose – while staying as streamlined as they can.

5 Stage Process

1. Research:

As a rule, I play the games that are in direct competition with whatever title I’m working on at the time. If it’s a Match 3 game, I’ll play the top 11 or so games that we’re competing against. As I play them, I’ll keep an eye out for the new features they release; my colleagues will do the same, and then we’ll discuss which of those features are effectively working (in terms of keeping us engaged). If we identify a feature that’s working well for a game, in terms of a specific goal (like monetization), we’ll consider using it as inspiration for our own game.

2. Ideation:

Once we have a source of inspiration, we’ll break down why it’s working. If its goal was to increase engagement, how is it successfully engaging us? If its goal was to increase monetization, how is it getting players to spend?  Once we understand the specifics about its effectiveness, we’ll brainstorm ways to take its core elements and transpose them into a feature for our game. But no, that doesn’t just mean ‘copy-pasting’ the feature. In order to not disturb our game’s play experience – which is the most important thing to uphold – we have to craft a feature that works for the thematic specifics of our game.

3. Testing:

Once we’ve designed the feature, we don’t just let it out of the gates and throw our hands up. We release it slowly and methodically, in a way that ensures we can accumulate as much data as we need before it’s released to the full public. For my team, that looks like getting a closed test group of players together – about 100 or 200 of them – and having them play the feature. By relying on a closed, small release first, we’re able to answer many basic questions about how the feature performs – and how it fits into our overall game – without the risk of failing from a too-soon public release.

4. Adjustments:

Based on the performance metrics we’ve seen from the test group of players, we then get busy tweaking the feature in the hopes that, when it is eventually released to the public, it avoids the negative feedback (or unmet potential) we saw in testing. That underperformance could stem from bugs, a lack of alignment between the theme of the feature and the theme of the game, or the designs of the feature’s mechanics (or economics) themselves. Testing gives us the clear picture we need to understand, take action, and improve.

5. Release:

After the adjustments have been made, the feature can either go back to the testing stage – with another closed player group trying it out for further data accumulation – or it can be released to the public. Usually, a public release isn’t in the cards until at least a few testing phases and feature iterations have taken place. When my team and I are confident that the feature has met its performance potential, we release it to the public – but we never stop accumulating data. If that data shows us that more tweaks could be made to further optimize the feature’s performance, then we make them.  

There you have the 5 most important stages of any feature design process. Now let’s get to the questions from the interview.

When features don't work

Let’s say you release a feature and it just totally doesn’t work. What do you do?

First thing’s first: if you’re going through the proper stages of feature design – including testing and adjustments – you shouldn’t be in this predicament. That is, releasing a feature (publically) and having it fall flat on its face. With the right checks and balances in place beforehand, you’ll know what isn’t working… and be able to correct those elements, and test some more, before they reach your players’ discerning eyes. 

Now that I’ve said my piece on testing, I’ll share an anecdote with you. Yes, I have had a feature perform worse than we expected it would. 

A few years back, I was working at RockYou on an older game, and our objective was to create a new PvP feature. The premise of the feature was jousting: there would be two players, each investing one token to compete, and then they would get to joust each other as knights – with one winning and one losing.

What we saw very quickly was that the players who were winning were happy. They were earning great ROI’s on their token expenditure, and they were all excited to keep coming back. But the players who were losing? They weren’t happy at all. And since they weren’t happy, they weren’t motivated to come back and try again. 

My team and I had many conversations about how to fix the feature so that the losing players wouldn’t feel completely defeated, and we ultimately landed on the notion of reciprocity. Since the ‘losers’ were still spending their tokens to play, to make things feel fair to them, we’d need to give them something in return. So we ended up giving the losing players a small reward for playing… and that turned out to be motivation enough for them to keep coming back. 

That’s the power of informed adjustments.

Testing via liveops events

What do you think about building a feature and then releasing it as a limited-time LiveOps event as a way to gather data – before deciding whether to keep it as a game mainstay?

This is a trend we’ve been seeing a lot of recently, and it does help to avoid the issue of releasing something permanently… only for it to fail. But what else helps to avoid that issue? Testing! 

Testing should always be the primary step in feature design

"Testing should always be the primary step in feature design."

Testing should always be the primary step in feature design for catching mistakes and shortcomings before your players do, which means that whether you release the feature in a limited-time LiveOps run or as a permanent mainstay, you should already have data proving its worth.

The point here is that you shouldn’t wait until a public release to investigate whether the feature is working. You should have that proof beforehand – and give yourself the opportunity to adjust before any losses (in retention or profit) take place.

Planning features for all player motivations

Different players have different motivations for playing – so how do you design features that excite all of them?

Imagine this: you and three of your friends decide to play a game together. (If you’re like Tom, that game might be Divinity: Original Sin II.) You all like the game, but what you like about it is different: while two of you enjoy the immersiveness of the storyline, one of you is driven to acquire as much currency (or wealth) as possible – and the other is motivated by power.

That’s three motivations for a group of four. Now imagine how many motivations there might be for a group of 100,000 – or more. So, with that context visualized, it’s clear that this question is an important one to ask. And what better way to answer it than with an example…

In Candy Crush – as in every game – there are different groups of players. These groups are divided based on their skill and their history with the game. For this example, let’s say 20% of players are somewhere in the Level 1-100 range, and 60% are between Levels 1,000-1,400. Based on that diversity of game experience and ability, how can the Candy Crush designers come up with a feature that serves everyone?

The short answer is, they can’t. But they don’t have to. Let’s break down what we know about those two groups:

• The early players (20% group) have a primary motivation of progressing in the game. Whether or not they stay engaged comes down to if they’re satisfied with the rate they’re progressing at – that is, if they’re frustrated, nothing’s stopping them from leaving.
• The experienced players (60% group) are already engaged with the game. They’re confident in their skill, so their retention isn’t tied to their progression rate so much as it’s tied to the game’s ability to deliver fresh, exciting content. They have more loyalty (thanks to the effort they’ve already exerted), so they’re less likely to leave on a whim. 

If the goal of the feature is to monetize, we know that targeting the already-engaged players will lead to better results than targeting the early players (where spending is uncertain). But, if the goal of the feature is to increase the DAU (Daily Active User) numbers, then targeting the early players will pay off. 

The point is, no one feature is going to appeal to every subset of your playerbase. But when you zoom out and look at a game’s monthly collection of features, you should find that every player group (and motivation) is accounted for. 

Whether that’s one monthly feature for monetization and two for engagement, one monthly feature for story-driven players and two for wealth-driven players – or some other mix entirely  – every game has its sweet spot. And the key to finding yours comes down to understanding your players – and planning accordingly.

Mastering retention tip

And for the Million Dollar Question: What’s your favorite tip or trick for keeping players more engaged – for longer? 

Designing F2P games comes with many challenges. They’re just part of the territory. But one of the biggest challenges – if not the biggest – is keeping our players’ interest. Not only today and tomorrow, but years into the future.

The LTV (Lifetime Value) KPI, for any F2P game, is a chief metric for designers to pay attention to. It quantifies the average relationship between your players and your game, telling you not just how profitable your title is today – but how its potential is trending tomorrow. Is it increasing sustainably? Is it losing its momentum? By understanding how much your players are willing to spend – and for how long – you’re getting to the root of your retention power. And that understanding allows you to act, and improve, intentionally.

To put it simply, the key to improving retention is having the right combination of features and audience. Because you might be creating the coolest, most exciting features, but if you’re not targeting the right audience, the players that stop by your game won’t stay for long. Think about it like this: if you’re a car-racing kind of player, stumbling into a home decorating game won’t do much for you, regardless of the game’s features. But if you find a racecar game with thrilling, fresh content? If it’s consistent, you’ll keep going back. 

So ensuring that you’re targeting the right audience is always the first step. Then, once your audience is secured, you need to introduce them to the game simply. Show them the core elements in a way that’s accessible and inviting: if I happen upon your game, I should be able to figure out what the game is, what the objectives are, and what my overall aspiration is in the very first play session. When I understand those things, I’ll feel confident playing… and actually want to return.

After the basics have been digested, it’s time to offer up new challenges. And that’s where delivering features comes in. Give the player more to do, more to accomplish, and more to discover. Give them more rewards – and then more challenges still. Keep them motivated and excited, and watch your engagement levels – and monetization ability – grow.

I’ll end this answer off with another example. Let’s say I find a new Match-3 title. On Day 1, I get to know the game, and it gives me the basic understanding I need to feel interested. I come back on Day 5 for my second play session, and the game says, thanks for coming back – we missed you. We missed you so much, in fact, that we wanted you to have these 10 gems. 

Where does that leave me? As a new player, it leaves me feeling excited – and appreciated. I have more wealth to my name, so I’m excited to see how I can use it to my benefit – and since the game showed me it appreciated me on Day 5, what will it show me on Day 20? Or Day 50? With that degree of anticipation, I’m motivated to keep playing. 

In the F2P world, players have an endless sea of options. That means that whatever you can do to differentiate – from tiny, innovative features to welcome-back rewards – won’t go unnoticed. 

In Conclusion…

From one Game Designer to another, I know that developing the right features can be complicated. I know that trying to increase retention or heighten engagement KPI’s can feel daunting. But the truth that helps me most is this: in the world of game design, immediate perfection doesn’t exist. 

You won’t hit the perfect feature on your first try. You won’t know exactly what your players want – until you give them the things they don’t. 

The key, with developing features and upping retention alike, is the process of molding. The process of testing, analyzing, and adjusting. The process of questioning and learning – and then acting. 

In other words: the key is being open to change. Everything you do is to serve your players, so get rid of the ‘failure or success’ mindset. Because it’s not one or the other – in all likelihood, it’ll be both. There’s no shame in testing and there’s no shame in fixing, but there is shame in going into the process with the belief that it’s already in perfect shape.

Features can’t be born perfect, but they can be molded to be with the right intel. And if you’re still looking for more direction on what that molding process should (or could) look like, I’d recommend you take a listen to the Mastering Retention podcast episode I recorded with Tom.

We get into more questions, more tips, and more industry trends – right or wrong – for developing features in F2P games. From the dangers of copying a game’s successful feature to the confusion of fielding anger from players when metrics are strong, it’s truly a deep-dive.