← Back

Mobile-First Casino Platform

Redesigning the session-critical money flows of a desktop casino platform for mobile.

Project overview

Type: Client · 16-week redesign · mobile web
Team: with 1 PM, 3 engineers, and a compliance stakeholder
Project type: Mobile-First Redesign · Responsive Systems Design · iGaming · Activation & Cash-out
Role: Lead Product Designer · Information Architecture · Interaction Design · UX Writing
Methods: Usability testing (SUS/SEQ) · funnel analysis · competitor benchmark · A/B with guardrail metrics
Tools: Maze · Figma + Dev Mode · Amplitude · Statsig
Case thesis: Designing a mobile casino interface where players manage their balance and cash out without leaving the game they are in, because the money moments are where small-screen sessions and player trust break.

The context

The platform began as a desktop product, and by the redesign mobile had grown to 68% of sessions. The mobile experience was a compressed port of the desktop site: a full feature set crammed into a small viewport, with the actual slot games running as embedded third-party screens that take the whole display. Everything the platform owns (navigation, balance, top-up, cash-out, notifications) competes with the game for space.

The problem

The session broke at the moments money had to move. When a player ran out of coins mid-game, topping up opened a full-screen wallet that unloaded the game, and 38% of sessions that hit a zero balance ended without a top-up (behavioral, Amplitude). Cashing out winnings was the biggest source of support contact: 34% of mobile support tickets were cash-out status and timing questions (operational, ticket analysis). The four actions players took most often sat three or more taps deep under a desktop-style menu.

The goal

Raise completion of the session-critical money flows (mid-game top-up and cash-out) and reduce the support and abandonment they caused, measured by flow completion, task success, and ticket volume, rather than by how many desktop features were ported.

Empathize — The session broke at the money moments: running out mid-game ejected players, and 38% never topped up

In this section: Research foundation · Key insights

Research foundation (method)

Phase 1 — Device funnel analysis (Amplitude, mobile web vs desktop): where mobile sessions ended and which actions dominated taps.
Phase 2 — Unmoderated mobile usability test (Maze, n=32, task-based): start a game, top up mid-session, and cash out winnings, with success and time-on-task recorded.
Phase 3 — Support ticket analysis (n=2,400 mobile tickets, one quarter): coded by reason against a written scheme.
Phase 4 — Competitor benchmark (5 mobile casino apps): how leading apps handled mid-game top-up and cash-out, which confirmed that the strongest performers kept the balance action over the game rather than on a separate screen.
Phase 5 — Prototype pilot (Amplitude-instrumented, ~140 players, mobile web, May–Jun 2024): behavior on the rebuilt flows, including the top-up A/B (~70 players per arm).

Key insights

1. Mobile players use a narrow slice of the platform per session. Four actions (open a game, check balance, top up, cash out) made up 82% of mobile taps, yet each sat three or more taps deep behind a ported desktop menu. The breadth that suited desktop buried the loop a mobile session runs on.

Behavioral: top four actions = 82% of taps; median 5 taps from open to a playing game.

2. The highest-value drop is running out of coins mid-game. Topping up loaded a full-screen wallet that unloaded the running game, so even players who finished the top-up lost their session. Triangulation across three measures of the same break:

Behavioral — session outcome: 38% of zero-balance moments ended the session with no top-up at all.
Behavioral — flow completion: of players who did start a mid-game top-up, only 41% completed it and returned to play, and of those who reached the full-screen wallet, only 23% returned to the same game.
Usability — task success: in the Maze test, 52% completed the mid-game top-up task, with several testers saying the game "disappeared" when they tried.
Verbatim (P7, weekday mobile player) — coded: Lost session: "I just wanted to add coins and keep playing, and it threw me out to a different screen and my game was gone."

3. Cash-out is the trust moment, and opacity drove support. Redeeming winnings had no clear status, timeframe, or fee shown, so players contacted support to ask where their money was.

Operational: 34% of mobile tickets were cash-out status and timing.
Verbatim (P19, occasional high-stakes player) — coded: Cash-out opacity: "I hit cash out and then nothing — no date, no amount confirmed. So I message support every time, just to know it's coming."

Dashboard — Where mobile sessions and support break

Where mobile sessions and support break
Scope: Mobile web · one quarter · Amplitude + ticket coding
Guiding question: At which money moment do sessions and trust break?

  Zero-balance moments ending with no top-up ...... 38%
  Mid-game top-up flow completion (behavioral) .... 41%
  Return to same game after reaching wallet ....... 23%
  Mid-game top-up task success (usability) ........ 52%
  Mobile tickets that are cash-out status/timing .. 34%

Key Insight: The three top-up numbers measure the same break from different
angles — sessions abandoned, flows completed, and lab task success — and all
point at a wallet that unloads the game. Cash-out opacity drives the rest.

Define — Players had to manage their balance without leaving the game they were in

In this section: POV · How Might We · Principles · Insight→decision map

POV statement. Mobile players need to top up and cash out without leaving the game they are in, because the money moments are where small-screen sessions end and where trust in the platform is won or lost.

How Might We

How might we let a player top up coins mid-game without unloading the game or losing its state?
How might we make cash-out status, timing, and fees clear enough that a player never has to ask support?
How might we cut the path from opening the app to a playing game down to the fewest taps?

Design principles (each traceable to an insight)

Protect game state. Money flows run on top of the game without unloading it. (Insight 2)
Session-critical actions first. The four most-used actions are always within one tap; the rest of the feature set lives behind a single "More." (Insight 1)
Money moments are transparent. Cash-out shows status, timeframe, and any fee up front. (Insight 3)
Responsible-gaming controls at the money moment. Deposit and time limits sit inside the same balance surface, so the control is present exactly when money is in play. (player wellbeing + regulatory requirement)

Insight → decision map

Insight (from Empathize)	Concrete design decision
82% of taps are four actions, buried 3+ taps deep	A condensed bottom bar holds play, balance, top-up, and cash-out; the full desktop menu collapses behind one "More"
Top-up unloaded the game; 38% dropped at zero balance, 41% flow completion	Top-up opens as a sheet over the live game, so coins are added without unloading the game iframe
Cash-out opacity drove 34% of tickets	A cash-out flow states status, timeframe, and fee before confirmation, with a tracked progress state afterward

Ideate & Craft — The session-critical loop moved on top of the game; the rest of the desktop menu went behind one More

In this section: Design execution · Before → after · Other deliverables

Design execution

Persistent balance chip + in-game top-up sheet — the balance stays visible during play; tapping it raises a top-up sheet over the running game, so the player adds coins and resumes the same spin.
Condensed bottom navigation — play, balance, top-up, and cash-out as primary; refer-a-friend, support, settings, and the rest collapse under "More."
Transparent cash-out — winnings redemption shows the amount, timeframe, and any fee before confirmation, then a tracked status so players stop asking support.
Responsible-gaming controls — deposit and time limits live inside the same balance sheet, present at the moment money moves.
Global search and real-time notifications — finding a specific game and surfacing account events without leaving the current screen.
UX writing — money and status copy rewritten to plain, unambiguous terms (what will happen, when, and for how much).

Before → after

	Before (desktop port)	After (mobile-first)
Open to playing a game	~5 taps through a mega-menu	~2 taps from the bottom bar
Mid-game top-up	Full-screen wallet, game unloaded	Sheet over the live game, state preserved
Cash-out	Confirm with no status or timing	Amount, timeframe, fee, then tracked status
Limits / responsible gaming	Buried in settings	In the balance sheet, at the money moment

Other deliverables

The interface was built as a responsive design system in Figma using variables and tokens, which became the shared foundation the Partner Portal later inherited. A set of AI-generated casino-environment backdrops set atmosphere on lobby and landing surfaces, kept low-contrast and out of the gameplay area so they never compete with game content. Handed off via Dev Mode.

Dashboard — In-game top-up keeps the session alive

In-game top-up keeps the session alive
Scope: Last 30 days · mobile web · platform pilot (~140 players)
Guiding question: Did topping up over the game keep players in their session?

  Mid-game top-up flow completion ... 41% → 67%
  Return to same game after top-up .. 23% → 88%
  Open-to-playing-game path ......... 5 taps → 2 taps

Key Insight: Running the top-up over the live game removed the lost-session
break, so players who hit zero balance stayed in the game they had open.

Prototype / Test — An aggressive auto-prompt to top up raised complaints and limit-setting without improving net completion; a player-initiated control performed better

In this section: The experiment · What it taught

To solve the zero-balance drop, the first idea was an automatic full-screen prompt that fired the instant a balance hit zero, pushing the player to top up immediately. It was A/B tested against the player-initiated balance chip in Statsig across the pilot, with limit-setting and complaint rates carried as guardrail metrics so a win on completion could not hide a cost to player trust or wellbeing.

The failed variant. The auto-prompt produced a higher immediate top-up rate, but net session-survival completion landed flat against the player-initiated control, and the guardrails caught the cost: complaints rose, and players who saw the prompt set deposit or time limits at 2.1× the rate of the other group, a signal they felt pressured. Optimizing for an immediate deposit traded against the trust that keeps a player coming back, and it pushed against responsible-gaming expectations.

The aggressive prompt costs trust without winning completion
Scope: Statsig A/B · mobile web · platform pilot · ~70 players / arm
Guiding question: Which approach recovers the zero-balance moment without pressuring players?

  Variant A — Auto full-screen top-up prompt
    Immediate top-up rate ........... 58%
    Net session-survival completion . ~flat vs B
    Limit-setting actions ........... 2.1× Variant B   (guardrail)
    Complaint rate .................. higher           (guardrail)

  Variant B — Player-initiated balance chip + sheet
    Immediate top-up rate ........... 49%
    Net session-survival completion . 67%
    Limit-setting actions ........... baseline
    Complaint rate .................. lower

Read with care: ~70 players per arm; directional, not heavily powered. The
decision rested on the guardrails — Variant A moved an immediate number while
tripping the trust and wellbeing signals the guardrails exist to protect.

Key Insight: The pressure tactic moved an immediate number and lost the
relationship; letting the player initiate the top-up recovered the moment
without the cost. Variant B shipped.

What it taught. In a money product, an interaction that boosts a short-term metric by pressuring the user erodes the retention and trust that compound; the durable design lets the player stay in control of when money moves. Carrying limit-setting and complaints as guardrails is what made that trade-off visible instead of hidden behind a completion win.

Outcomes & reflections

In this section: Causal chain · Limitations · Responsible-gaming stance · Reflections

Causal chain (pilot, ~140 players, mobile web)

The open-to-game path shortened (5 → 2 taps), so more sessions started; the in-game top-up sheet preserved game state, so mid-game top-up flow completion rose from 41% (pre-redesign baseline) to 67% (shipped Variant B) and return-to-the-same-game rose 23% → 88%, which kept zero-balance moments from ending the session; the transparent cash-out flow cut cash-out support tickets from 34% → 13% of mobile volume; and clearer money moments lifted 30-day player retention from 51% → 63% (the 51% baseline measured from the pre-redesign mobile cohort). Responsible-gaming engagement also rose, with limit-setting completion up because the controls sat in the balance sheet.

Metric	Before	After	Δ
Open-to-playing-game path	~5 taps	~2 taps	−60%
Mid-game top-up flow completion	41%	67%	+26 pts
Return to same game after top-up	23%	88%	+65 pts
Cash-out share of mobile tickets	34%	13%	−21 pts
Mid-game top-up task success (usability)	52%	89%	+37 pts
30-day player retention	51%	63%	+12 pts

Note on the top-up numbers: the 41% is the in-product behavioral completion of a started top-up flow; the 52% is lab task success in Maze; the 38% is the share of zero-balance moments that ended the session entirely. They are three views of one break, not one metric repeated.

Scale note: at a mobile share of 68% of sessions, recovering the zero-balance moment and clearing cash-out confusion moves the experience for the majority of the platform's traffic.

Limitations (stated, because a portfolio claim is only as strong as what it concedes)

Small pilot. ~140 players, ~70 per A/B arm. The flow-completion and ticket effects are clear and consistent; the A/B is directional, and the decision leaned on the guardrail signals rather than statistical power.
Single-cohort baselines. The before figures come from the pre-redesign mobile cohort, not a held-out control, so they describe the status quo the redesign improved on.
Embedded-game dependency. The whole approach assumes the third-party game iframe tolerates an overlay without reloading; a game provider that forces a reload on focus change would break the central interaction and require a fallback.

Responsible-gaming stance (made explicit, because the domain demands it)

Recovering the zero-balance moment means designing at the exact point a player has run out of money, so player wellbeing was a first-order constraint, not an afterthought. Three choices encode that: the top-up is player-initiated, never an auto-prompt that pressures a deposit; deposit and time limits live in the same balance surface, present precisely when money is in play; and the A/B rejected the higher-converting aggressive variant because its guardrails showed players felt pressured. The design recovers lost sessions by removing friction the player chose to cross, not by pushing a player who stopped.

Reflections (transferable principles)

On mobile, a complex platform should be designed around the few actions a single session runs on, with the rest of the feature set demoted rather than crammed into the same viewport.
Embedded third-party content sets the real constraint: when the game owns the screen, the platform's own flows have to run beside it without unloading it, which makes overlay and state-preservation the central interaction problem.
In a money product, a short-term metric won by pressuring the user is a loss disguised as a gain; carrying wellbeing guardrails in the experiment is what lets a team see that and choose the durable design.