03 · Responsible-play concept · 2026
Play Check-in
A pre-wager check-in for a sportsbook and casino concept: it interrupts the bet slip when play changes from a player's own pattern, names what changed, and hands over real controls instead of a settings-page warning.
- Role
- Product Designer: concept to prototype
- Timeline
- 2026
- Scope
- 17 screens, 4 prototype paths, UI system
- Platform
- iOS + Android: 390 × 844 prototype
Responsible-play controls today are generic and live in account settings: the same warning for everyone, far from the moment behaviour changes.
This concept moves the control to the moment: a check-in that appears before a wager is confirmed, only when play changes from the player's own recent pattern, explained in plain language, with nine real controls attached to it, never a silent restriction.
One session, both products, one check-in
The concept follows one session used throughout the write-up. It starts at 20:26 with a €120 balance on the sportsbook. By 20:52 two losses bring the net position to −€38 (the first signal). At 21:01 a second deposit lands, €80 in total (the second). At 21:08 the player moves from sportsbook to casino (the third). By 21:12 the average stake has risen from €4.50 to €9.00 (the fourth). At 21:14, with a €13.50 stake prepared, roughly three times typical, the check-in appears.
Four named signals, compared with the player's own last four weeks, not a fixed threshold applied to everyone. The check-in explains what changed, shows the whole session across both products, and hands over nine real controls. Nothing is restricted by default.
- Type
- Concept: conceptual regulated market
- Platform
- iOS + Android: 390 × 844
- Screens
- 17, 4 prototype paths
- Role
- Product Designer: concept to prototype
What decided the shape of it
- 01
Transparent, not mysterious
Every check-in names the signals behind it and says plainly what is, and isn't, being looked at.
- 02
Protective, not obstructive
Withdrawal, support and limits stay reachable on every screen, including under an active restriction.
- 03
Describe activity, never label the person
The copy says what changed in the account, never what kind of player someone is.
- 04
One session spans both products
Sportsbook and casino share one balance and one session view, because a player's night doesn't split by product.
- 05
Quiet in the money
Net position leads over turnover, and colour never marks a loss. Only restriction, confirmation and attention states carry colour.
- 06
No commercial pressure
Offers and promotions are suppressed for the rest of the session once a check-in has shown.
Live prototype captures
From an ordinary bet slip to a chosen control
- 01 / 05
Play context
An ordinary casino bet slip: no warning, no nudge, before the trigger. Pre-warning every session would just train players to dismiss it, so the interruption has to be earned.
Screen 01 · Play context - 02 / 05
Pre-wager check-in
One sentence, three of the player's own figures, one recommended action. A bottom sheet, not a full-screen block. It interrupts the tap without taking the session away, and it can be reached back out of.
Screen 02 · Pre-wager check-in - 03 / 05
Why you're seeing this
What was looked at, what was not, and how the data is used: three collapsible sections. Naming what was not considered does more for trust than any reassurance sentence.
Screen 03 · Why you're seeing this - 04 / 05
Unified session review
Net position at 42px, then four supporting figures and a three-bar stake comparison against the player's own baseline. Turnover, €412, is the number the industry shows and the one that misleads. Net position leads instead.
Screen 04 · Unified session review - 05 / 05
Control selection
One recommended option carries the full consequence detail. Nine equal cards was the first version and it read as a menu of punishments. Ranking one and demoting the rest to rows made the page decidable.
Screen 05 · Control selection
The states around the intervention
The screens that took the most thought weren't the busy ones: they were the pause running, and the money staying reachable underneath it.
Deposit limit: nothing pre-filled, a suggestion the player has to accept. 
Pause: a countdown with what's still open beside it. 
Withdrawal: reachable from the check-in, the session view and mid-pause.
Trade-offs I had to argue
- Decision 01
- Constraint
- A full-screen block reads as punishment and destroys the context the explanation depends on.
- Decision
- A bottom sheet over a full-screen block.
- Result
- The sheet interrupts the tap, not the session. It can be reached back out of.
- Decision 02
- Constraint
- €412 staked sounds like activity, but it's the number that misleads.
- Decision
- Net position, not turnover, leads.
- Result
- −€72 is what the player actually needs to see. Turnover stays as context, one size down.
- Decision 03
- Constraint
- If a pause makes cash harder to reach, the pause becomes a trap.
- Decision
- Withdrawal stays on every screen: the check-in, the session view, mid-pause, mid-restriction.
- Result
- Commercially uncomfortable, ethically non-negotiable.
- Decision 04
- Constraint
- Removing the continue option entirely would make the check-in a covert block.
- Decision
- "Place the bet anyway" stays visible but demoted, never removed.
- Result
- At the escalated tier it's replaced by a restriction instead of quietly disappearing.
- Decision 05
- Constraint
- A number invites argument about the number.
- Decision
- No risk score is shown, only the four observed signals, named.
- Result
- The conversation becomes about behaviour, not about disputing a score.
- Decision 06
- Constraint
- Automated decisions will be wrong sometimes.
- Decision
- Human review is always available for an automated restriction.
- Result
- The cost of a review queue is lower than the cost of an unappealable restriction.
Compliance assumptions
- 01
DESIGN CHOICE
Withdrawals, support and self-exclusion stay reachable during every pause and restriction.
- 02
BEST PRACTICE
Promotions are suppressed for the session, not queued for delivery afterwards.
- 03
ASSUMPTION: needs operator data
Four weeks as the baseline window, and four correlated signals as the threshold.
- 04
NEEDS LEGAL
Whether a continue path may be offered, the cooling-off period on a limit increase, and the retention period for the signals used.
- 05
VARIES BY MARKET
Reality-check intervals, mandatory limit types, minimum and maximum limit values, review SLA, whether the intervention must be reportable.
- 06
OUT OF SCOPE
Any clinical claim. The product does not screen for, detect or diagnose gambling harm, and the copy never implies it does.
Try it
The real prototype on sample data: the original build, served as-is. Place a bet above €9, work through the check-in, and choose a control. There's no account and nothing is sent anywhere. Everything resets on reload. The balance, card suffix and reference number are placeholder concept data.
Loads on request. Nothing is embedded until you start it.
Tokens with one job each
Instrument Sans carries the interface. IBM Plex Mono carries every money value and timestamp, so columns align. Radius scale 4 / 8 / 12 / 14, a 4px spacing base, two elevations. Losses are never shown in red: a −€72 in red on every screen would make the number decorative and the restriction colour meaningless.
- Action & active protection#3E9C8F
- System interpretation#7392C7
- Attention, worth knowing#C9903F
- Restriction & error only#BE5B54
- Confirmed#55976F
- Interface: Instrument Sans400–700 · 13–20px
- Money & timestamps: IBM Plex Mono500–600 · 12–42px
What it is, and what it isn't
Play Check-in is a portfolio concept: a working prototype of 17 screens across 4 paths, on a token-based system. There's no operator, no licence and no players behind it, so there are no results to report. Only the product decisions, which the prototype above lets you check. Revenue, session length and wager frequency were deliberately left off the success measures: if they counted, the design would drift back toward the thing it's trying to replace.
- 17 screens, 4 prototype paths: Pause, Limit, Withdraw, Escalation
- A working prototype, embedded above
- A compliance-assumptions table that names what still needs legal and operator confirmation
Reflection
The hardest part wasn’t designing the check-in. It was designing what happens after it: a pause in progress, a failed limit save, a restriction that can be reviewed, and withdrawals that stay accessible. Those edge states turned the idea from a single intervention into a complete product flow.
This remains a concept, not a shipped product. The behavioural signals and thresholds would need real operator data, bias and false-positive testing, and market-specific legal review before they could be used in production.
