Iterating Fun - Simon Newstead
Month
Progress with friends
Count me as a fan of Candy Crush Saga on .
The folks at do a great job. Much fun is the over the top (and slightly creepy) presentation of a much-loved tile matching mechanic. But I also love the transition between levels on the Candyland map and being able to see my progress vs Facebook friends:
Woohoo level 10… see ya Mike…
Um… Charles, Angus, Sana and Mary, you guys have too much time on your hands *_*
Air’s thin up there
Seeing your Facebook friends* in a game can be a strong motivation to continue on the grind of a game.
* For many hardcore players who use dedicated Facebook game accounts with non irl friends, I think the argument still holds. You often have as strong a bond with them through other games spanning many years of your life
But it’s increasingly the case that:
This presents a question to game designers who spend many cycles on high level systems and players, those who bring in the big revenue.
On one hand you could argue that the real friend social layer is only needed to get you addicted to the game and helping the viral coefficient a bit, and once you’re up there at high levels the meta game and game-specific social components (friends, guilds, challenges, events etc) take over.
But to me it seems strange to have two separate friend layers within a game - Facebook and in-game, often used in different parts of the UX and game systems.
A marathon model?
Imagine in a game like Candy Crush Saga if that instead of showing a ever thinning list of FB friends as you progress up through the levels, you blend in-game friends (and foes and strangers) into the progress map.
It could be done programmatically.
A sprinkling of high level players, with serious bling showing the spoils of progress, as well as those with a similar cohort, trajectory or level to yours, to encourage you to keep on moving (analogous to how Clash of Clans throws high level players occasionally into the random PvP matching as well as those ranked similarly in level to you)
The way I see it, this model could be like a marathon:
All of these three groups are different, but aren’t they all runners in the same game?
Should FB and in-game be treated the same? I’d love your feedback. or .
Recently we bid farewell to a new feature…
It was a cute feature, one we liked. But at our morning metrics meet we made the grim call. When the daily Android build went out hours later, it was gone.
Sunsetting a feature - how to decide?
“Stella’s Assistant” was designed as a basic plant & harvest currency mechanic. Players would start a job from 5 minutes to a day, and get paid once done.
It was a small feature, an MVP hacked together on an assumption it would increase retention, helping remind players to return to collect their coins from Stella.
Other retention features we had launched performed well. Yet after launching it to our usual A/B test we found retention actually decreased in the group that had Stella’s Assistant, vs the control:
And to top it off, monetization also dipped:
We first verified the test was statistically significant. Next we thought it might have something to do with economy balance and tried with different payout values. Yet in no A/B test was the result positive.
Should I stay or should I go? Some tips to decide
When a feature under-performs like this, there’s a binary decision to make: iterate it or drop it.
How do you decide? Some questions to consider…
Is the feature meeting its stated goal?
It’s good to have a goal for each feature, preferably a specific number. eg- lift 7 day retention by 5%. Then when you release it you can see clearly whether it was successful.
In our case, the answer was no. The numbers don’t lie and for a feature designed to improve retention, to have it dip down, albeit slightly was pretty damning.
What is the underlying reason for its under-perfomance?
Often, numbers tell the what, but not the why.
In talking with players we found Stella’s Assistant just didn’t add much to the game. Whilst extra coins were nice, it felt like a weird farming sim feature tacked on to a fashion game. It also made the UI busier, and introduced an extra menu layer and more taps, pulling the overall experience down.
What is the opportunity cost of iterating?
As a startup, every developer hour counts, and the question is whether trying to improve the feature would have a bigger impact on metrics vs using that time to develop something else.
Apart from metrics impact, you have to weigh up the ongoing additional cost of testing and support.
In this case we weren’t convinced iterating it would move the needle much, and we had several other features that would have a much better “bang for buck”.
Does it have strategic value beyond metrics?
Some features may not improve the numbers, but may still have strategic value.
For example, a device registration system to stop cheating, an icon promoting a partner, or a parental safety feature that stops inadvertent payments in a kids game and builds long term trust.
In our case though, there just just wasn’t one.
Final tip - stay positive!
Abandoning something you have worked hard on, whether for a few hours or a few weeks is never fun. Us humans deal pretty badly when it comes to loss, including that at our own hands.
The key though is to stay positive, and realize you may have lost a feature but you gained a real learning - one that can only improve you and your startup going forward.
So, Stella’s Assistant rides the slow boat to Valinor and for us, the adventure continues :)
How do you decide when to kill a feature? I’d love your feedback. or .