PRODUCT DESIGN CASE STUDY
Designing a Live Elimination Tournament
Making asynchronous skill-gaming feel live, visible, and competitive
I helped turn a rough live-elimination tournament mechanic into a released mobile tournament experience. Players entered during the same window, submitted scores, watched the field resolve in real time, and advanced through repeated rounds until one winner remained. The work defined how live score resolution, cutoff survival, advancement, and elimination would feel clear enough for players to trust as the tournament changed around them.
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 to protect confidential platform details. They represent the design direction and system logic, not production screenshots.
Role
Product Design Owner
Ownership
Experience definition
Platform
Mobile skill-gaming
Scope
Flows, prototypes, state logic, design direction
Status
Released, later adapted
01 — CONTEXT
The challenge was making asynchronous competition feel live
The platform’s contest model was mostly asynchronous: players submitted a score, then waited for results to resolve later. This tournament format needed to feel more active and immediate without making the rules harder to follow.
The core problem was player uncertainty. Players needed to understand when they entered, where they stood, what score they needed to survive, and when advancement or elimination became final.
What changed
Existing contest model
Player submits a score
Result is compared later
Competition feels delayed
Player has limited live feedback
Live elimination model
Players enter during the same window
Field resolves as scores come in
Cutoff becomes the survival threshold
Player status feels active and visible
“Am I still in?”
That became the core player question the experience needed to answer at every stage.
The key decision
I centered the experience around one question: “Am I still in?” That moved the design away from a generic leaderboard and toward a live survival model.
The cutoff line, avatar field, player anchoring, and pass/fail states all supported that decision. The screen had to help players understand not just their rank, but whether they were safe, at risk, advancing, or eliminated.
02 — MY ROLE
My role was turning a rough mechanic into an operational experience model
My role was to make the tournament understandable before it became a build. I worked through early concepts, wireframes, interaction logic, multi-round flows, prototypes, stakeholder presentations, and final design direction.
Once the project moved into game-engine implementation, the creative and technical leads owned the final build. I stayed involved through targeted design adjustments, but the main value of my work was defining the experience model the team could build from.
Ownership boundary
I owned the experience definition before development: flows, interaction logic, prototypes, and final design direction. After implementation began, the creative and technical leads led the final build while I supported targeted design adjustments.
From concept to implementation
My strongest ownership was defining the experience before development: turning the mechanic into flows, prototypes, screen logic, and final design direction.
01
02
03
04
05
06
07
STEP 01
Rough mechanic
Input from product leadership
A live elimination tournament idea with avatar-based competition.
STEP 02
Early concepting
Applied to skill-gaming UI
Explored how the format could appear inside the existing app.
STEP 03
Wireframe logic
Mapped score & round states
Explored sticky score, highlighted placement, round navigation, and multi-entry logic.
STEP 04
Avatar-led model
Shifted from list-first results
Explored avatar movement, pass/fail zones, cutoff behavior, and tap-to-inspect scores.
STEP 05
Platform adaptation
Adapted to platform constraints
Simplified layout, organized avatars, and reduced round-browsing complexity to fit a cleaner, more data-heavy product system.
STEP 06
End-to-end prototype
Built full multi-round prototype
Demonstrated entry, score resolution, advancement, elimination, repeated rounds, and final win.
STEP 07
Development support
game-engine implementation updates
After development began, the creative and technical leads led final implementation. I supported targeted design adjustments.
03 — SYSTEM COMPLEXITY
The prototype had to show the full tournament loop, not just one screen
One screen could explain the basic tournament concept, but it could not prove the experience worked across multiple rounds. The larger question was whether players could stay oriented as the field narrowed, scores resolved, and outcomes changed from round to round.
I built a multi-round prototype to make the full loop visible: entry, gameplay, score submission, result resolution, advancement, elimination, repeated rounds, and final placement.
What the prototype needed to prove
Players could understand where they were in the tournament across repeated rounds
Advancement, elimination, and live uncertainty remained clear as the field resolved
The mechanic worked as a complete loop, not just as a single result screen
Large-field elimination tournament flow
Prototype model showing how a player advances from entry through final round resolution.
View full-size flow
The flow mapped how a player moved through entry, gameplay, score resolution, advancement, elimination, repeated rounds, and the final result.
04 — SCREEN ANATOMY
Anatomy of the live tournament screen
The screen had to anchor the player as the round outcome took shape around them.
The screen was organized around the player’s main question: “Am I still in?” Every major element supported that answer: current score, rank, cutoff, competitor movement, pending players, and final status.
View full-size anatomy
The tournament screen had to answer three questions quickly: what did I score, where do I stand, and what do I need to survive? I used player anchoring, header stats, pending indicators, and the cutoff line to keep status readable while the field was still resolving.
05 — FINAL DESIGN DIRECTION
Final design direction: three tournament states
I separated the tournament experience into three clear states: scores still resolving, advancement confirmed, and elimination confirmed. Each state used the same core structure so players did not have to relearn the screen as the tournament changed.
The visual treatment changed based on status, but the important anchors stayed consistent: player score, rank, cutoff relationship, and outcome.
View full-size states
The tournament screen used the same core structure across three states: live uncertainty, advancement confirmed, and elimination confirmed. The player’s score and rank stayed visible in the header, while the avatar field, survival threshold, and pass/fail colors showed whether the player was currently safe, advancing, or out.
06 — FIELD RESOLUTION
How the tournament field resolved live
The tournament model had to support score resolution while the field was still changing. Depending on the game type, scores could behave differently: some only increased, some could move up or down with penalties, and some updated too frequently to show every change without creating visual noise.
My focus was the player-facing status model: helping players understand where they stood, what the cutoff meant, and whether their result was still resolving or final. The design needed to communicate movement and uncertainty without making the tournament feel chaotic or untrustworthy.
View full-size field resolution
The field resolution model showed how player status, cutoff pressure, and final outcomes could be communicated while tournament results were still resolving. The exact scoring behavior depended on the game type, but the player-facing goal stayed the same: make status understandable without creating unnecessary chaos.
07 — DESIGN DECISIONS
The strongest decisions were about clarity, not decoration
The most important decisions were about reducing uncertainty. The tournament could feel active and competitive only if players could quickly understand their own status, the cutoff, and whether the result was still changing or final.
Player anchoring
I kept the player’s own score, rank, and avatar visually anchored so they could find themselves quickly while the field changed around them.
Cutoff visibility
I made the cutoff line the main survival cue because rank alone did not explain whether a player was safe, at risk, advancing, or eliminated.
State separation
I separated live, advanced, and eliminated states so players could tell the difference between a result that was still resolving and an outcome that was final.
Large-field orientation
I used the avatar field to make a large tournament pool feel active and readable without forcing players to scan a dense leaderboard during a changing live event.
08 — WHAT CHANGED IN DEVELOPMENT
The design model stayed useful as implementation evolved
My strongest ownership was the experience model: the flows, prototype logic, screen architecture, state definitions, and final design direction before implementation.
Once the project moved into the game engine, the creative and technical leads owned the final build. Some details changed, including score presentation, visual treatment, and how the interface handled larger tournament fields. I do not present the final interface as solely my design. The value of my work was defining a tournament model the team could evaluate, build from, release, and later adapt.
09 — OUTCOME
The work helped turn a new tournament format into a released product experience
The tournament concept moved into development and became a released product experience. After the initial release, the same tournament model was later adapted for the company’s primary platform, making it more than a one-off feature exploration.
Because the project involved confidential product details, I do not publish internal metrics, proprietary screens, or performance data. The NDA-safe outcome is that the work helped define a live-elimination model the team could evaluate, build from, release, and adapt across platforms.
What changed
Turned a rough live elimination mechanic into a complete mobile experience model
Proved the tournament loop across a larger multi-round player pool
Defined how score updates, cutoff movement, advancement, and elimination were communicated
Created an end-to-end prototype from entry through final result
Supported implementation as the final product experience evolved
Supported a tournament model that was later adapted beyond the initial release to another company platform.
RELATED WORK
