A roulette table you can bet on the edges of
A live dealer is streamed to a phone. Over that video sits an interface where every tap moves real money, the betting window closes on a countdown, and a bet is often placed not on a number but on the boundary between two of them.
- Role
- Design system owner
- Scope
- System and product surface
- Platforms
- Mobile and desktop
- Status
- Frozen before release
The constraint that shaped everything
In roulette you can bet on a single number. You can also bet on the line between two numbers, the corner where four meet, the end of a row of three, or a whole column. Those are not different screens or different modes. They are different targets on the same table, and the user selects them by aiming at a boundary.
A grid of cells cannot express that. A cell has an inside; a bet needs an edge. So the table is not built as a grid of numbers. It is built out of directional half-cells, so that the edge between two numbers is itself an addressable, hoverable, chip-holding component.
| Component | Variants | What it carries |
|---|---|---|
| Number cell | 20 | Red, black, zero, win, hover, pressed, chip placed |
| Corner target | 10 | The four-number intersection |
| Combination target | 10 | Splits and streets |
| Diamond target | 10 | Outside bets on the table front |
| Racetrack half-cells | 110 | Top, left, bottom and right edge variants |
| Racetrack cells | 10 | Interior positions |
| Poker chip | 78 | Six denominations, four states, two surfaces |
Hover has to travel
If a user hovers the boundary between 20 and 23, the interface has to tell them what they are about to bet on — and the answer is two numbers, not the sliver of space under the cursor. Hover a column and it is twelve numbers. Hover a street and it is three.
So the hover state propagates. Pointing at any target lights every number that target covers, and it lights them on both the table and the racetrack at once, because the same bet exists in two representations and the user needs to see that they are the same bet.
This is the whole reason the token layer is component-scoped rather than global. A number cell needs a defined appearance for “covered by the bet currently being considered”, separately from hovered, chip placed, and won. A generic hover token cannot express that.
Two decisions I would defend anywhere
Separate typefaces for words and for money
Text is set in a proportional sans. Every number that represents money — balance, stake, winnings, the countdown — is set in a monospaced face with tabular figures. These values update constantly, and in a proportional face a balance ticking from 1,111 to 8,888 physically changes width and jitters on screen. Locking the digit width costs nothing and makes the one number the user actually cares about hold still.
Inline padding compensated for the border
The spacing scale runs 4, 8, 12, 16, 24, 28. The inline padding scale runs 3, 7, 11, 15, 23, 27 — each step one pixel short. Components with a one-pixel border and components without one then optically align, instead of sitting a pixel apart in a row.
Reading an interface over a moving picture
Every surface in the system is semi-transparent over live video. That is a constraint most interfaces never face: the background is not a colour you chose, it is a dealer’s hands moving under studio lighting.
- Every surface token is a two-stop gradient rather than a flat fill, so panels read as glass against motion instead of flickering between legible and not.
- A gradient scrim sits between video and controls, weighted toward the bottom where the primary controls live.
- Win states use a warm yellow border that appears nowhere else in the system, so the winning number is identifiable at a glance without reading it.
- Three visual themes — two contemporary, one classic — sit on the same component layer, changing only token values.
What I would measure
Nothing here reached users, so there is nothing to report. If it had:
- Mis-taps on boundary bets. A chip placed and immediately removed is the signal that an edge target is too small or unclear. This is the number the whole architecture lives or dies on.
- Bets placed against time remaining in the round. If placements cluster in the last two seconds, the betting window is being communicated too late.
- Racetrack versus table usage. Two representations of the same bets is a significant build cost. Either users move between them or one of them should go.
- Legibility correlated with table theme. Three themes over live video is three different contrast situations, and only real sessions would show which one fails.