UI / UX Design
SPARKS
Designing a real-time market experience that radically changed how users engaged.
Role:
Lead Product Designer
Industry:
Sports FinTech
Team:
Product, Engineering
Project Duration:
~6-8 weeks
Overview:
SPARKS was a net-new product I designed from scratch within the PredictionStrike ecosystem — a fast-resolution, game-day engagement layer that sat alongside the platform's existing long-term trading model. I was the lead product designer working closely with product and engineering over roughly 6–8 weeks of iterative exploration and rollout.
PredictionStrike had built its reputation around patient, conviction-based investing in athletes. SPARKS was something different: a short-cycle experience where users could engage with live sports moments, see outcomes resolve by end of game, and walk away with clear, immediate feedback — win or lose.
The Problem:
As PredictionStrike matured, a new segment of users started showing up — people shaped by fantasy sports and betting platforms who expected fast feedback and frequent outcomes. They compared the existing experience unfavorably to sports betting: too slow, too passive, no sense of moment-to-moment engagement.
The core product wasn't broken. But it was built entirely for one type of user — the patient, long-term investor — while a growing portion of the audience wanted something fundamentally different. The answer wasn't to change what PredictionStrike was. It was to build something that could coexist alongside it.
Process:
Research confirmed two distinct engagement mindsets: users who viewed PredictionStrike as a sports-flavored stock market, and a newer segment who arrived expecting the immediacy of sports betting. The flagship served the first group well. The second had almost no meaningful path forward.
The first design direction was called ETFs — Exchange Traded Funds. It reused existing scoring logic and bundled athletes into fixed sets. Early testing killed it fast. The name was confusing and felt disconnected from sports. Worse, fixed bundles removed the one thing users actually wanted: the ability to pick their own players and apply their own sports knowledge.
That feedback shaped the next direction entirely. Fixed bundles were replaced with a user-driven builder. The product was renamed SPARKS — a name that tested significantly better and felt native to the platform's energy. What started as a constraint (reuse existing scoring logic) became an advantage: we weren't building new infrastructure, we were reframing what already existed.
Design:
The core mechanic is a 2-player bundle: select two athletes, bet on whether their combined fantasy score will go OVER or UNDER a target, and choose a multiplier that sets your risk and payout. Simple on the surface, but each of those three decisions required careful design.
The biggest tension was between speed and control. Some users wanted to move fast — quick-click a popular combination and play. Others wanted to dig in, compare projections, and build their own. Rather than forcing a single path, the final design supports both: a Popular SPARKS tab for quick entry, and a SPARKS Builder for users who want full control. The Builder defaults to game view rather than athlete list — a small call that dramatically improved discovery, because users naturally think by matchup, not by name.
The other major challenge was learnability. SPARKS was unlike anything else on the platform, and users couldn't understand what "winning" looked like until they could see it mid-game. Progress indicators on open positions — color-coded bars tracking combined fantasy score against the target in real time — became essential to making the product feel understandable without requiring any explanation.
The Solution:
The final SPARKS experience supports two ways to play: Popular SPARKS surfaces curated combinations for users who want speed, while the SPARKS Builder lets users select any eligible athlete and construct custom bundles. Both paths lead to the same checkout flow — choose OVER or UNDER, select a multiplier from 1.5x to 10x, and confirm.
Open positions show a live progress bar tracking combined fantasy score against the target, updating throughout the game and shifting color as users approach or fall short. Win and loss states resolve at the end of the game — no waiting days or weeks for an outcome. The whole loop, from discovery to result, fits within a single game day.
Impact & Reflection
In the first week after launch, new user adoption went from 15% to 90%. Revenue per active user grew from $14 to $70 per month, contributing to 5x growth in platform revenue. SPARKS became the most popular play option for new users on the platform.
The version that shipped looked almost nothing like the initial ETF concept — and that's not a failure, that's what staying close to users actually looks like in practice. The rename from ETF to SPARKS was one of the simplest decisions we made and one of the most impactful; users who'd been confused about the core mechanic suddenly understood it just from the name change. What started as a product experiment became the primary growth driver for the platform.
More Projects
UI / UX Design
SPARKS
Designing a real-time market experience that radically changed how users engaged.
Role:
Lead Product Designer
Industry:
Sports FinTech
Team:
Product, Engineering
Project Duration:
~6-8 weeks
Overview:
SPARKS was a net-new product I designed from scratch within the PredictionStrike ecosystem — a fast-resolution, game-day engagement layer that sat alongside the platform's existing long-term trading model. I was the lead product designer working closely with product and engineering over roughly 6–8 weeks of iterative exploration and rollout.
PredictionStrike had built its reputation around patient, conviction-based investing in athletes. SPARKS was something different: a short-cycle experience where users could engage with live sports moments, see outcomes resolve by end of game, and walk away with clear, immediate feedback — win or lose.
The Problem:
As PredictionStrike matured, a new segment of users started showing up — people shaped by fantasy sports and betting platforms who expected fast feedback and frequent outcomes. They compared the existing experience unfavorably to sports betting: too slow, too passive, no sense of moment-to-moment engagement.
The core product wasn't broken. But it was built entirely for one type of user — the patient, long-term investor — while a growing portion of the audience wanted something fundamentally different. The answer wasn't to change what PredictionStrike was. It was to build something that could coexist alongside it.
Process:
Research confirmed two distinct engagement mindsets: users who viewed PredictionStrike as a sports-flavored stock market, and a newer segment who arrived expecting the immediacy of sports betting. The flagship served the first group well. The second had almost no meaningful path forward.
The first design direction was called ETFs — Exchange Traded Funds. It reused existing scoring logic and bundled athletes into fixed sets. Early testing killed it fast. The name was confusing and felt disconnected from sports. Worse, fixed bundles removed the one thing users actually wanted: the ability to pick their own players and apply their own sports knowledge.
That feedback shaped the next direction entirely. Fixed bundles were replaced with a user-driven builder. The product was renamed SPARKS — a name that tested significantly better and felt native to the platform's energy. What started as a constraint (reuse existing scoring logic) became an advantage: we weren't building new infrastructure, we were reframing what already existed.
Design:
The core mechanic is a 2-player bundle: select two athletes, bet on whether their combined fantasy score will go OVER or UNDER a target, and choose a multiplier that sets your risk and payout. Simple on the surface, but each of those three decisions required careful design.
The biggest tension was between speed and control. Some users wanted to move fast — quick-click a popular combination and play. Others wanted to dig in, compare projections, and build their own. Rather than forcing a single path, the final design supports both: a Popular SPARKS tab for quick entry, and a SPARKS Builder for users who want full control. The Builder defaults to game view rather than athlete list — a small call that dramatically improved discovery, because users naturally think by matchup, not by name.
The other major challenge was learnability. SPARKS was unlike anything else on the platform, and users couldn't understand what "winning" looked like until they could see it mid-game. Progress indicators on open positions — color-coded bars tracking combined fantasy score against the target in real time — became essential to making the product feel understandable without requiring any explanation.
The Solution:
The final SPARKS experience supports two ways to play: Popular SPARKS surfaces curated combinations for users who want speed, while the SPARKS Builder lets users select any eligible athlete and construct custom bundles. Both paths lead to the same checkout flow — choose OVER or UNDER, select a multiplier from 1.5x to 10x, and confirm.
Open positions show a live progress bar tracking combined fantasy score against the target, updating throughout the game and shifting color as users approach or fall short. Win and loss states resolve at the end of the game — no waiting days or weeks for an outcome. The whole loop, from discovery to result, fits within a single game day.
Impact & Reflection
In the first week after launch, new user adoption went from 15% to 90%. Revenue per active user grew from $14 to $70 per month, contributing to 5x growth in platform revenue. SPARKS became the most popular play option for new users on the platform.
The version that shipped looked almost nothing like the initial ETF concept — and that's not a failure, that's what staying close to users actually looks like in practice. The rename from ETF to SPARKS was one of the simplest decisions we made and one of the most impactful; users who'd been confused about the core mechanic suddenly understood it just from the name change. What started as a product experiment became the primary growth driver for the platform.
More Projects
UI / UX Design
SPARKS
Designing a real-time market experience that radically changed how users engaged.
Role:
Lead Product Designer
Industry:
Sports FinTech
Team:
Product, Engineering
Project Duration:
~6-8 weeks
Overview:
SPARKS was a net-new product I designed from scratch within the PredictionStrike ecosystem — a fast-resolution, game-day engagement layer that sat alongside the platform's existing long-term trading model. I was the lead product designer working closely with product and engineering over roughly 6–8 weeks of iterative exploration and rollout.
PredictionStrike had built its reputation around patient, conviction-based investing in athletes. SPARKS was something different: a short-cycle experience where users could engage with live sports moments, see outcomes resolve by end of game, and walk away with clear, immediate feedback — win or lose.
The Problem:
As PredictionStrike matured, a new segment of users started showing up — people shaped by fantasy sports and betting platforms who expected fast feedback and frequent outcomes. They compared the existing experience unfavorably to sports betting: too slow, too passive, no sense of moment-to-moment engagement.
The core product wasn't broken. But it was built entirely for one type of user — the patient, long-term investor — while a growing portion of the audience wanted something fundamentally different. The answer wasn't to change what PredictionStrike was. It was to build something that could coexist alongside it.
Process:
Research confirmed two distinct engagement mindsets: users who viewed PredictionStrike as a sports-flavored stock market, and a newer segment who arrived expecting the immediacy of sports betting. The flagship served the first group well. The second had almost no meaningful path forward.
The first design direction was called ETFs — Exchange Traded Funds. It reused existing scoring logic and bundled athletes into fixed sets. Early testing killed it fast. The name was confusing and felt disconnected from sports. Worse, fixed bundles removed the one thing users actually wanted: the ability to pick their own players and apply their own sports knowledge.
That feedback shaped the next direction entirely. Fixed bundles were replaced with a user-driven builder. The product was renamed SPARKS — a name that tested significantly better and felt native to the platform's energy. What started as a constraint (reuse existing scoring logic) became an advantage: we weren't building new infrastructure, we were reframing what already existed.
Design:
The core mechanic is a 2-player bundle: select two athletes, bet on whether their combined fantasy score will go OVER or UNDER a target, and choose a multiplier that sets your risk and payout. Simple on the surface, but each of those three decisions required careful design.
The biggest tension was between speed and control. Some users wanted to move fast — quick-click a popular combination and play. Others wanted to dig in, compare projections, and build their own. Rather than forcing a single path, the final design supports both: a Popular SPARKS tab for quick entry, and a SPARKS Builder for users who want full control. The Builder defaults to game view rather than athlete list — a small call that dramatically improved discovery, because users naturally think by matchup, not by name.
The other major challenge was learnability. SPARKS was unlike anything else on the platform, and users couldn't understand what "winning" looked like until they could see it mid-game. Progress indicators on open positions — color-coded bars tracking combined fantasy score against the target in real time — became essential to making the product feel understandable without requiring any explanation.
The Solution:
The final SPARKS experience supports two ways to play: Popular SPARKS surfaces curated combinations for users who want speed, while the SPARKS Builder lets users select any eligible athlete and construct custom bundles. Both paths lead to the same checkout flow — choose OVER or UNDER, select a multiplier from 1.5x to 10x, and confirm.
Open positions show a live progress bar tracking combined fantasy score against the target, updating throughout the game and shifting color as users approach or fall short. Win and loss states resolve at the end of the game — no waiting days or weeks for an outcome. The whole loop, from discovery to result, fits within a single game day.
Impact & Reflection
In the first week after launch, new user adoption went from 15% to 90%. Revenue per active user grew from $14 to $70 per month, contributing to 5x growth in platform revenue. SPARKS became the most popular play option for new users on the platform.
The version that shipped looked almost nothing like the initial ETF concept — and that's not a failure, that's what staying close to users actually looks like in practice. The rename from ETF to SPARKS was one of the simplest decisions we made and one of the most impactful; users who'd been confused about the core mechanic suddenly understood it just from the name change. What started as a product experiment became the primary growth driver for the platform.