top of page

Programs used:
InVision, Adobe Photoshop/Illustrator/AE, Unity

NicePng_wizard-of-oz-png_661923.png

Daily Retention Feature

Our DAU was an area where we could improve the games performance. This system was developed to boost that number up

problem:

  • Stakeholders wanted to increase the number of daily user logins by at least 3% and increase monitization by at at least 5%.
     

  • The team had tried a similar design that failed to meet a similar acceptance criteria.

pain points:

  • Designing this, the focus on the user experience and visuals were to ensure that it felt entirely different, though the core concept was the same.
     

  • The lack of performance of the previous feature was never fully explored.

Research Methodology

  • Why didn't the previous feature work?
     

  • What would be different if ________ ?
     

  • What if we had know ________ ?
     

  • What would change if ________ ?
     

  • What other way could we ________ ?

research phase insights:

  • We focused on the parts of the previous feature that failed. I engaged with users and reviewed messaging analytics which revealed the feature instructions were too lengthy and unclear.

  • Our studies showed that users, both old and new, disliked any disruption in the core flow of the application. Moving forward, we knew we had to design carefully because this feature would affect user interaction.

hypothesis:

To increase user logins and monetization we should focus on keeping the feature undisruptive to the core flow. Adding a character to the experience should make it interactive instead of task-orientated.

This feature had been given an aggressive deadline. To consolidate resources I decided to keep the character to just one pose and face with a change of costume and color. The main color for each level would be reinforced in all other areas of the feature as a user progressed.

Feature Flow Chart

as is

FlowChart_BasicFlow.png

with new feature

FlowChart_Flow.png

Implementation and Testing:

  • With only 1 designer, 1 artist, and 1 developer on the team we had to be transparent and work in phases to ensure no one was blocking the other. Communication and visibility were critical because the developer was remote.

  • We made the deadline for the final review, but a stakeholder requested a change that was not listed in the original acceptance criteria. The feature would not be launched without this addition.

New Review Request

This new request from the stakeholder, not only put the timeline in jeopardy but also created a break in the core feature flow. All research indicated we had to develop an approach that would not break the existing flow.

FlowChart_FlowEdit.png
MunchFix.png

Original Final

Through quick ideation, the team identified a few unusual but workable solutions. I spearheaded the option of adding an alternate version of the ending animation. Working in tandem with our developer, we quickly wire-framed the fix. After presenting it back to the stakeholders and getting approval, we quickly implemented the solution.

Adjusted Final

results:

After the new feature was activated there was a ~5% increase in monetization as well as an ~3% increase of user logins over the next 2 weeks. The feature helped up retention and allowed the team to be congratulated for our innovative thinking and ability to adjust efficiently and effectively. 

conclusion:

After the post mortem meeting, we decided that an additional meeting once the flow charts were complete with the stakeholders would be beneficial. This process would ensure that no acceptance criteria were misinterpreted or lost during research and the finalized flow charts.

Kam Seidl 2025

bottom of page