PRODUCT DESIGN CASE STUDY
Designing a Daily Engagement Loop
Helping players return, claim rewards, and enter paid-entry contests through a daily streak system
The platform already had rewards, but they were mostly campaign-driven and disconnected from a clear daily return habit. I designed a daily engagement system that connected app open, reward claiming, streak progress, entry tickets, and paid-entry contests. The strongest version improved repeat-play behavior, kept reward-claim behavior strong, and became a recurring platform mechanic.
CONFIDENTIALITY NOTE
This project involved confidential product and platform details. Screens, flows, company-specific data, and performance metrics have been abstracted or recreated.
Visual note: Product screens and diagrams in this case study are recreated and anonymized. They represent system logic and design direction, not production screenshots.
ROLE
Product Design Owner
OWNERSHIP
Streak system, reward states, ticket path
PLATFORM
Mobile skill-gaming
STATUS
Shipped experiment → recurring feature
CONSTRAINT
Confidential details abstracted
01 — CONTEXT
Rewards existed, but there was no daily habit loop
The platform already had a Rewards area, but most rewards were tied to campaigns, weekly or monthly promotions, gameplay, or deposits. They created value, but they did not give players a simple reason to return every day.
The product question was not “where do we put another reward?” It was: how do we turn a daily claim into a clear path back into paid-entry contest activity without making the experience feel confusing, overly promotional, or hard to trust?
Before
Rewards were campaign-driven
Rewards changed weekly, monthly, or by promotion
No daily streak or countdown existed
Players had less reason to return daily
After
Daily claim appeared on app open
Calendar showed streak progress
A visible claim rhythm created anticipation
Entry rewards connected back to paid-entry contests
The key decision
I moved the system toward a seven-day streak model because it made the habit easier for players to understand and easier for the team to test. A real calendar month created too much rigidity. A weekly structure gave us a clear rhythm, supported different program lengths, and kept the reward logic flexible without making the experience feel arbitrary.
02 — MY ROLE
I owned the system around the reward moment
Owned
Calendar/streak system, locked and claimed reward states, countdown behavior, Rewards page entry point, ticket detail treatment, contest-list reward entry, and stakeholder alignment.
Represented for alignment
Locker selection and reward reveal screens were represented in Figma so product, legal, and implementation teams could evaluate the full experience.
Not owned
Final animation production and game-engine implementation were handled by game artists and engineering.
03 — PRODUCT LOOP
The reward loop had to lead back into gameplay
Daily reward to paid-entry contest loop
App open
Daily claim
Calendar / streak view
Entry reward
Reward ticket
Highlighted contest → Play Now
04 — FINAL SYSTEM SURFACES
Three surfaces made the loop usable
The daily loop was supported by three connected surfaces: the calendar/streak view, the Rewards page ticket, and the highlighted contest entry. Together, they helped players understand what they claimed, where to find it, and how to use it.
View full-size system surfaces
The final system connected three surfaces: the calendar/streak view, the Rewards page ticket, and the highlighted contest entry. Together, they helped players understand what they claimed, where to find it, and how to use it.
05 — SYSTEM EXPLORATION
The calendar model had to support habit, not just display dates
I explored month-based calendars, four-week views, single-week layouts, vertical lists, and horizontal carousels. The decision came down to which structure could create a repeatable claim rhythm without tying the product to a rigid calendar model.
The selected direction used a seven-day weekly structure with week navigation. It gave players a simple streak pattern and gave the team flexibility to run the program for one, two, four, or more weeks.
View full-size wireframes
The selected direction used a 7-day weekly structure with week navigation, giving the team flexibility to run the program for 1, 2, 4, or more weeks.
06 — MYSTERY REWARD DECISION
Anticipation needed a clear boundary
I explored whether players should see future rewards before they claimed them. Showing upcoming rewards made the system more transparent, but it also reduced anticipation and made reward value harder to control across the streak.
The selected direction kept future rewards hidden until claim. Players still had a clear rhythm: return, claim, check progress, and come back for the next reward, but the system preserved enough mystery to keep the loop interesting.
View full-size experiment model
Experiments compared how much reward information players should see before claiming. The selected direction kept future rewards hidden until claim, which preserved anticipation while allowing the system to control reward value by streak day.
07 — KEY DECISIONS
Three decisions shaped the final rewards loop
7-day calendar architecture
The weekly structure made the program flexible across different experiment lengths without tying it to a real calendar month.
Reward-to-gameplay bridge
Entry rewards appeared on the Rewards page and inside relevant contest lists so players had a clear path from claim to Play Now.
Value communication
Entry rewards had to show prize pool, standard entry value, discounted/free state, expiration, and game context without using betting-style language.
08 — COMPLIANCE & VALUE COMMUNICATION
Clear value made rewards easy to trust
Entry rewards had to explain value without using betting-style language. Players needed to understand what they received, what the entry normally cost, when the reward expired, and where they could use it.
I treated the ticket as a product decision, not just a visual component. The card had to make the reward feel useful, time-sensitive, and connected to a specific contest without creating confusion around cost, prize value, or eligibility.
View full-size value breakdown
09 — Experiment Progression
From experiment to recurring mechanic
The experience moved through live experiments before becoming a recurring platform feature. The early tests helped the team understand how much reward information players needed before claim and which version created the strongest return behavior.
Once the strongest direction was clear, the system expanded to larger player groups and became part of the platform’s ongoing engagement strategy.
Shipped loop
Daily reward claim on app open
Mystery rewards
Calendar / streak view
Week navigation
Next-claim countdown
Free and discounted entry tickets
Rewards page ticket card
Highlighted contest entry
Deferred or reduced
Deeper calendar-claim states
Direct gameplay entry from the reward flow
Cross-product reward concepts
Contest notification banners
Site-wide discount rewards
10 — OUTCOME
The experiment became a recurring engagement mechanic
The strongest version improved repeat-play behavior while reward-claim behavior stayed strong. The direction expanded beyond the initial test and became a recurring platform mechanic.
Because this project involved confidential product details, I am not publishing internal numbers or proprietary performance data. The NDA-safe outcome is that the work helped turn daily reward claiming into a repeatable engagement pattern, not just a one-off promotion.
Tested reward visibility variants with live player groups
Expanded the strongest direction to broader rollout
Connected daily reward claiming to paid-entry contest activity
RELATED WORK
