SplashLeague: turning a retention drop into a weekly classroom ritual
At a glance
SplashLeague turned SplashLearn's classrooms from twice-a-week visitors into weekly participants: a live quiz event that drew about 43,000 students in its first week and scaled to 183,000.
Role: Lead Product Designer/ Product Owner responsible for research, product definition, Strategy. PRD, design leadership, post-launch quick iteration, analysis, stakeholder management.
Timeline: Mid-July to September 8 launch, then 4 months of weekly iteration
Team: Design (with 1 senior designer), 8 Tech, 4 Content, 1 Art, 1 Research, 2 Marketing
Tools: Claude (Work, Design, Code) used across the process to ship faster
The problem: classrooms that logged in, but didn't come back
โข Retention signal: reviewing the year-on-year classroom retention table, I saw a 12% YoY drop.
โข Login data: teachers logged in at most 1 to 2 days a week, and students at most 2 - the same story from the other side.
Goal: Increase weekly classroom logins and, through them, year-on-year classroom retention. Since YoY takes time to show, I used weekly classroom retention and teacher login days per week as proxy metrics.
Research: finding the teacher's routine
โข Research approach: user research into how teachers actually conduct their classrooms, mapping their routines and mental models.
โข Key insight: teachers already run exit tickets and short quizzes whenever they teach something - the opening for a weekly quiz.
โข Offline vs live: offline would have made it just another assignment; a live quiz could engage teachers and students in the classroom at the same time.
Validating at scale: an in-product survey
To size the opportunity, I ran an in-product survey that appeared when teachers logged in. It asked:
Do they want quizzes weekly, biweekly, fortnightly or monthly?
Should math and English be on the same day or different days?
How should the calendar look?
The survey answered the biggest design decisions: a weekly cadence, and math and English on separate days, because both on one day would overwhelm students.
Defining the experience: from user needs to a mental model
Before designing screens, I wrote out the problem statement step by step: user needs, the mental model, and the core business goal. Then I defined the whole quiz system.
When: I used login data to find the peak days for teachers and students. The result was Math on Wednesday, English on Thursday.
How the quiz works:
15 questions in 3 rounds of 5, escalating from easy to medium to difficult, with answers and explanations shown between rounds.
No negative marking. We debated it, but it would demotivate kids, and our goal was engagement. A wrong answer should never feel like punishment.
Rewards for the behaviors we wanted: fast answers, 3-question and 5-question streaks, early-answer bonuses, and a completion reward.
What the teacher needs to know, at every login:
On non-quiz days, which quizzes are coming up.
On quiz day, a clear "The quiz is live today."
On both days, the topic, question types, number of questions, how scoring works, and how to guide students to log in and start.
Live during the event: participation, questions answered, class score, and class rank against other classrooms at state and country level. We planned rewards at both levels so more classes had a shot at winning, because rewarding only a few at country level would demotivate the rest.
Scoping under a hard deadline
Timeline pressure: September is SplashLearnโs high-traffic month and we started in mid-July - about 1.5 months to define, design and build.
โข Parallel tracks: I brought tech, art and content stakeholders in from day one so each function could start in parallel, and the research team lined up usability testing as designs became ready.
I cut the scope with the tech team around what we could realistically ship.
The MVP had three things:
Teachers see upcoming quizzes and the live quiz day, and can share instructions with students.
Students see the quiz at the top of their dashboard on quiz day and can start playing.
Teachers see which students have joined and how many answers are correct.
Deferred to later phases: live class score and class rank (state, country and grade), certificates, shareable badges, parent invites, anti-cheating measures, and peer motivation.
Designing fast: parallel tracks and daily loops
โข Execution model: after detailing every flow, I handed off to a senior designer and we executed together - rapid iterations with daily connects, staggered handoffs so engineering could build while we designed the next part, and AI-assisted workflows (Claude) across design and code to keep the pace.
โข In parallel: I wrote the PRD, scoring logics, ranking logics, defined the metrics and events we would track, and took regular feedback from founders and stakeholders.
โข Pre-launch quality: usability testing and user acceptance testing, and I verified the scoring logic against test data.
โข Bug caught before launch: class scores were being calculated incorrectly against class strength. Fixing it before day one saved the launchโs credibility.
The solution
Teacher home: the upcoming-quiz calendar, quiz-day banner, and the instructions to share with students.
Student dashboard: the quiz pinned on top on quiz day.
In-quiz experience: the three rounds, streak and bonus feedback, and round summaries.
Teacher live view: who's joined and how many answers are correct.
Rewards: the completion reward and the badges.
Launch and the weekly iteration loop
We launched on September 8, and in the first week about 43,000 students played.
Then the real work started. For the next 4 months we ran a strict weekly rhythm around the Wednesday quiz:
Wednesday: quiz goes live.
Thursday: analyze scoring and participation data.
Friday: plan changes.
Monday: build.
Tuesday: ship, ready for the next Wednesday.
The data showed what to fix. When many kids were scoring very low, we made quizzes easier and more adaptive and reworked the scoring so motivation stayed high.
Iterating on what the data told us
Gamification. More rewards and peer-to-peer invites to pull more students in each classroom into the quiz.
โข Cohort-based bonuses. I identified that classrooms of size 5+ and 10+ were the cohorts with the most impact, and designed participation thresholds that awarded bonus points without distorting the overall scoring.
โข Making reports useful. Teachers found the reports confusing. Through usability testing and teacher conversations, we rebuilt them as real-time, question-level reports with better grouping and insights.
โข Fixing a participation drop. About two months in, teacher participation dropped. Looking at how many teachers and students visited the quiz page, and running a quick two-day survey, I found the cause: teachers were simply forgetting about the quiz. We added reminders on Wednesday and Thursday, with live participation prompts from the first quiz onward.
โข Habit support. With marketing, we set up weekly emails around the quiz.
Impact
โข 43k students played in week one to 180k by week 8.
Teachers loved the SplashLeague enough to post about it on Facebook and in their school channels.
SplashLeague replaced our annual Springboard math test with weekly math and English quizzes, with schools winning $20,000 worth of prizes including subscriptions.
A weekly shipping cadence held for 4 months, driven by data rather than opinion.
Key highlights
Design started with the business problem, not a feature idea. I found the retention drop, researched the routine, sized it with a survey, and only then designed.
Owned strategy as well as design: scoring logic, cadence, rewards, PRDs, metrics and events, and stakeholder alignment.
Scope was a design decision. The MVP cut was made with the tech team and kept the loop intact: teacher knows, students play, teacher sees.
Designed for motivation. No negative marking and easier quizzes when scores were low, because the goal was engagement.
Led a team through a tight deadline by involving every function early and working in parallel.
Post-launch was a system, not an afterthought. The weekly loop and the cohort-based reward logic show how I use data to keep improving.
SpringBoard 2026 โค๏ธ
SplashLeague replaced our annual Springboard math test with weekly math and English quizzes, with schools winning $20,000 worth of prizes including subscriptions.
AI driven launch of SpringBoard 2026
โข Interactive prototype created via Claude design from brainstorming to execution to convince stakeholders for SpringBoard overhaul.
โข Builds coded prototypes with Cursor, Claude Code testing real interactions rather than static flows.
โข Uses AI-assisted synthesis across research transcripts and support tickets to find themes, then reads the raw source behind them.
โข Explores far more design directions per problem, then narrows on craft judgement.
โข Rolls out AI workflows, prompts and practices across the design team.





