Redesigning the new-player feature unlock experience to reduce early drop-offs
Redesigning the new-player feature unlock experience to reduce early drop-offs
duration
duration
3 months
3 months
role
role
Product Design/UX Research/Interaction Design/Debugging
Product Design/UX Research/Interaction Design/Debugging
team
team
Harry Potter: Puzzles & Spells Team
Harry Potter: Puzzles & Spells Team
tl'dr
I worked on the new-player experience for Harry Potter: Puzzles & Spells, building a playable prototype in Claude Code so we could test the flow with real players before anything shipped. The work is still unreleased, so this page is about how I approached it rather than what we built.
I worked on the new-player experience for Harry Potter: Puzzles & Spells, building a playable prototype in Claude Code so we could test the flow with real players before anything shipped. The work is still unreleased, so this page is about how I approached it rather than what we built.
what is harry potter: puzzles & spells?
what is harry potter: puzzles & spells?
A match-3 mobile puzzle game set in the Harry Potter world with over 10M downloads, with hundreds of levels, collectible magical creatures and live events. It’s a long-running live game with an established player base.
A match-3 mobile puzzle game set in the Harry Potter world with over 10M downloads, with hundreds of levels, collectible magical creatures and live events. It’s a long-running live game with an established player base.
the problem
The steepest drop-off happens before players see the good part.
In a live mobile game the first few sessions decide whether someone stays, and people form a judgment before they’ve seen most of what makes the game good. We noticed high drop-offs in the first few days of installing the game. The question was what to show, when, and how much to hold back.
my approach
01 Working through key decisions with product & game design
Most of the design work went into how to and when to introduce and surface new features to players for the first 30 levels.
I brainstormed decisions with the product manager, the director of design & the UX team, then iterated on how each one would actually feel to play. An idea can be right on paper and still land flat or unintuitive, so most of the work was finding the version that was both.
We also had to find the right balance in how much to change at once. Making the experience feel more intuitive mattered, but changing too many things in one release would have made the impact impossible to track.
Most of the decisions came down to pacing →
How early should a feature be teased before it unlocks?
Does a large unlock land better all at once, or in phases?
What gives someone a reason to open the app again tomorrow?
02 Bringing decisions & questions to senior leadership and leaving with a scope
I ran a UX review for stakeholders and senior leadership, walking through the reasoning behind each direction and naming the open questions rather than resolving them on the slide.
We worked through which elements could reuse existing Unity prefabs and which would need new ones, since every new asset is something a new player has to download before they can start playing. We also looked at how much someone should have to read at once, and whether related information was better grouped than sequenced.
It gave developers and artists a place to ask questions, size the work and agree where to start. Some of the best ideas in the project came out of that meeting!
03 Prototyping dozens of unique screens in time to test them
The flow ran across dozens of puzzles, and because something new is introduced in or after most of them, there was no repeatable sequence to build once and loop. Testing it properly meant building all of it, which was more than I could do by hand in the time I had.
So I split the work. Claude Code took the mechanical parts: cloning screens, wiring transitions, rebuilding the animations that recurred across sections. My hours went to the screens that were genuinely new.
What I learned about briefing an AI: Briefing well came down to being specific about intent, not just mechanics. Handing over a whole section at a time rather than a screen meant it could be cloned, wired and animated in one pass. Almost everything that cost me time was ambiguity I’d left for the tool to resolve on its own.
What cost me time
Saying what a mechanic does, but not how it’s viewed. The right technique depends on whether something plays when the screen opens or gets presented as part of a flow.
Making a rule only after something was built wrong. “Collectibles are always one-shot prototype, never Motion” became a standing rule after two sections had already been redone.
The habit that would have saved the most
Describe the finished state and how you’ll check it. “It should play once when the screen opens, and I’ll judge it by presenting the flow, not by clicking the static screen.” One sentence settles the technique before anything gets built.
04 Turning what we watched players do into proposed changes
We watched five players move through the prototype, and I brought back a set of changes grounded in where they actually hesitated rather than where we’d assumed they would.
Let's hop on a call if you'd like to discuss more of my work at Zynga!
what did i learn?
⏰ Pulling constraints in early instead of discovering them late
This project touched every discipline, from product and game design to art and engineering, and almost nothing could be decided alone. I went to each of them before settling a direction rather than after: sitting with the art team to work out what genuinely needed new art and what could be reused, and checking with developers on which assets would add to what a new player has to download.
Constraints showed up late as often as early. Surfacing them while a direction was still moveable is what kept it from having to be rebuilt.
This project touched every discipline, from product and game design to art and engineering, and almost nothing could be decided alone. I went to each of them before settling a direction rather than after: sitting with the art team to work out what genuinely needed new art and what could be reused, and checking with developers on which assets would add to what a new player has to download.
Constraints showed up late as often as early. Surfacing them while a direction was still moveable is what kept it from having to be rebuilt.
🧼 Don’t wait for the process to get streamlined
Prototyping with AI moved part of my work into design engineering. Instead of specifying something and handing it off, I was building what we tested, or combing through Unity to debug. The same applied when I noticed in-game copy was drifting depending on who was writing it, so I built a tone-of-voice agent the team could work from.
Once you can build, noticing a problem and doing something about it stop being separate steps.
Prototyping with AI moved part of my work into design engineering. Instead of specifying something and handing it off, I was building what we tested, or combing through Unity to debug. The same applied when I noticed in-game copy was drifting depending on who was writing it, so I built a tone-of-voice agent the team could work from.
Once you can build, noticing a problem and doing something about it stop being separate steps.
this was a wonderful experience for me! i got to meet such talented & welcoming folks at Zynga 🥰
“... and then, I have nature and art and poetry, and if that is not enough, what is enough?”
-Vincent Van Gogh
photo clicked by me at jim corbett national park, india.
one of the most refreshing trips of my life.
© made with love & cappuccinos by sriya benjaram 2026
the problem
The steepest drop-off happens before players see the good part.
In a live mobile game the first few sessions decide whether someone stays, and people form a judgment before they’ve seen most of what makes the game good. We noticed high drop-offs in the first few days of installing the game. The question was what to show, when, and how much to hold back.
my approach
01 Working through key decisions with product & game design
Most of the design work went into how to and when to introduce and surface new features to players for the first 30 levels.
I brainstormed decisions with the product manager, the director of design & the UX team, then iterated on how each one would actually feel to play. An idea can be right on paper and still land flat or unintuitive, so most of the work was finding the version that was both.
We also had to find the right balance in how much to change at once. Making the experience feel more intuitive mattered, but changing too many things in one release would have made the impact impossible to track.
Most of the decisions came down to pacing →
How early should a feature be teased before it unlocks?
Does a large unlock land better all at once, or in phases?
What gives someone a reason to open the app again tomorrow?
02 Bringing decisions & questions to senior leadership and leaving with a scope
I ran a UX review for stakeholders and senior leadership, walking through the reasoning behind each direction and naming the open questions rather than resolving them on the slide.
We worked through which elements could reuse existing Unity prefabs and which would need new ones, since every new asset is something a new player has to download before they can start playing. We also looked at how much someone should have to read at once, and whether related information was better grouped than sequenced.
It gave developers and artists a place to ask questions, size the work and agree where to start. Some of the best ideas in the project came out of that meeting!
03 Prototyping dozens of unique screens in time to test them
The flow ran across dozens of puzzles, and because something new is introduced in or after most of them, there was no repeatable sequence to build once and loop. Testing it properly meant building all of it, which was more than I could do by hand in the time I had.
So I split the work. Claude Code took the mechanical parts: cloning screens, wiring transitions, rebuilding the animations that recurred across sections. My hours went to the screens that were genuinely new.
What I learned about briefing an AI: Briefing well came down to being specific about intent, not just mechanics. Handing over a whole section at a time rather than a screen meant it could be cloned, wired and animated in one pass. Almost everything that cost me time was ambiguity I’d left for the tool to resolve on its own.
What cost me time
Saying what a mechanic does, but not how it’s viewed. The right technique depends on whether something plays when the screen opens or gets presented as part of a flow.
Making a rule only after something was built wrong. “Collectibles are always one-shot prototype, never Motion” became a standing rule after two sections had already been redone.
The habit that would have saved the most
Describe the finished state and how you’ll check it. “It should play once when the screen opens, and I’ll judge it by presenting the flow, not by clicking the static screen.” One sentence settles the technique before anything gets built.
04 Turning what we watched players do into proposed changes
We watched five players move through the prototype, and I brought back a set of changes grounded in where they actually hesitated rather than where we’d assumed they would.
the problem
the problem
The steepest drop-off happens before players see the good part.
In a live mobile game the first few sessions decide whether someone stays, and people form a judgment before they’ve seen most of what makes the game good. We noticed high drop-offs in the first few days of installing the game. The question was what to show, when, and how much to hold back.