PRODUCT DESIGN CASE STUDY
Designing a Customizable Live-Event Game Experience
Turning a brick-breaker mobile game into a sponsor-friendly fan engagement system for live events.
BRIXSmasher was a configurable brick-breaker game experience for live events. Fans played on mobile, audiences followed along on venue displays, and teams could customize the experience for sponsors, campaigns, and event settings. My work focused on turning the game into a flexible system that could be branded, operated, and handed off without breaking the player experience.
Role
Product Design Owner
Ownership
UI, customization, handoff
Platform
Mobile live-event game
Status
Handoff-ready; development paused
Scope
74 screens · 22 images · 121 layers
View full-size mobile UI
Final mobile UI direction for BRIXSmasher, showing the player-facing game experience across menu, gameplay, boss mode, leaderboard, and powerup states.
01 — OVERVIEW
The game had to entertain fans and create sponsor value
Sports teams needed more interactive ways to engage fans during live events while giving sponsors a visible branded moment. The challenge was making the game flexible enough for different teams, venues, and campaigns without turning every event into a custom rebuild.
I treated the product as a live-event system: mobile play for fans, large-format visuals for audiences, operator controls for staff, and customization rules for sponsors and teams.
Business challenge
Turn a familiar arcade mechanic into a sponsor-friendly live-event experience that could work across different teams, venues, and branded campaigns.
My role
After the initial concept direction, I owned the mobile UI, gameplay states, default visual system, customization logic, admin concepts, asset specifications, sprite sheets, and developer handoff. I collaborated with the games producer while preparing the system for implementation.
The key decision
I treated BRIXSmasher as a configurable event system, not just a branded mobile game. The experience had to work for fans playing on mobile, audiences watching on venue displays, operators running the event, and sponsors needing visible brand placement.
That decision shaped the mobile UI, mainboard direction, customization model, asset rules, and developer handoff. The system needed enough flexibility for different events while still protecting gameplay clarity and implementation quality.
02 — EXPERIENCE SYSTEM
The product was more than a mobile game
The experience had to work across three connected surfaces: the player-facing mobile game, the venue-facing mainboard experience, and the operator-facing customization tools.
Each surface had a different audience, but they had to feel like one system. Fans needed simple gameplay, audiences needed readable event feedback, operators needed control, and teams needed sponsor branding to stay visible without disrupting the game.
View full-size experience system
The system connected three surfaces: mobile gameplay for fans, large-format event visuals for audiences, and operator tools for team, sponsor, and venue customization.
03 — GAMEPLAY STAGE ARCHITECTURE
The experience had to work across the full event loop
The game experience had to support more than the moment of play. Fans needed a clear way into the game, simple instructions before starting, readable feedback during play, and a result state that made replay or event continuation feel natural.
I mapped the experience across pregame, gameplay, and postgame so mobile play, audience display, scoring, and event flow could work together as one connected system.
The stage map shows how the experience moved from entry and instruction, into active play, then into score feedback and replay.
View full-size gameplay stage architecture
04 — KEY DECISIONS
The depth was in the system decisions, not just the game screens
The important decision was defining what could change without breaking the experience. Teams and sponsors needed flexibility, but players still needed a readable game and developers needed clear implementation rules.
I treated customization as a controlled system: flexible enough for different events and brands, constrained enough to protect gameplay clarity, visual consistency, and handoff quality.
Default game identity
I defined the logo, color direction, UI style, and base visual language so the game had a strong default presentation before client customization.
White-label boundaries
I decided which assets could be uploaded or color-customized, while keeping constraints that protected readability, layout, and gameplay clarity.
Familiar power-ups
I chose recognizable brick-breaker power-ups so the game stayed easy to understand across different client skins and markets.
Implementation-ready assets
I structured sprite sheets, layer separation, dimensions, and assembly guidance so the design could be rebuilt accurately in-engine.
05 — CUSTOMIZATION MODEL
The design had to stay flexible without breaking
The customization model needed clear boundaries. Teams and sponsors could change imagery, colors, event settings, and branded assets, but the core game still had to stay readable and consistent.
I defined which assets could be uploaded, which colors could be customized, what dimensions had to stay fixed, and how the system should be prepared so different events could feel branded without creating one-off design or development work each time.
View full-size customization model
06 — DEVELOPMENT-READY HANDOFF
The handoff reduced implementation risk
The handoff needed to do more than show final screens. Developers had to understand how the logo, UI layers, customizable assets, colors, and gameplay elements should be assembled in-engine.
I organized the work into sprite sheets, separated asset layers, default color specs, and assembly diagrams so the team had clear implementation guidance. The goal was to preserve the visual system while keeping the game customizable and memory-conscious.
View full-size handoff details
07 — OUTCOME
The result was an implementation-ready game package
The final package defined how BRIXSmasher could work across mobile play, venue display, sponsor customization, operator setup, and developer implementation. It included mobile UI, gameplay stages, mainboard direction, admin concepts, customizable asset specs, sprite sheets, and assembly documentation.
The project was fully designed and handed off, then paused before implementation when roadmap priorities and development capacity shifted. The outcome was a complete system that reduced ambiguity for the team that would build, customize, and operate it.
3
Months
Design timeline
2
Game modes
Freeplay + Event Mode
74
Screen designs
Mobile, mainboard, admin, handoff
22
Customizable images
Client-uploadable assets
121
Asset layers
Implementation handoff
RELATED WORK
