TableView — Bally
Thirty pits, six hundred tables, one shift clock. A floor-management product for casino operators — designed for the tablet in a pit boss's hands, and specified sprint by sprint for the team building it.
The two ends of the same product. Left: the whole floor as pit cards — open, previous shift, closed, locked, win/loss. Right: one table, its seats, its rack, and every action a pit boss can take on it without leaving the floor. Between them sit pit and section views at the same grain.
tables across 30 pits and 30 sections, readable in a single view.
table shapes × states — open this shift, open previous, closed, locked — before colour is applied.
configurable colours, carrying drop, hold %, win/loss, club state and junket.
sprints of interaction specification delivered to engineering.
-
The unit of work is a shift
Gaming date, shift number and a countdown to end-of-shift sit in the chrome of every screen. Nothing on a casino floor means anything until you know which shift it belongs to — so the product had to carry that context everywhere, including into the alert that tells you you're five minutes behind.
-
Four altitudes, one model
Floor → pit → section → seated. Each level answers the same set of questions — win/loss, headcount, cash drop and hold, fills and credits, dealers, VIP and whale — at a different grain. A floor manager and a pit boss read the same product without learning two of them.
-
A table taxonomy, not table screens
Six shapes — blackjack, baccarat, craps and three roulette layouts — each with four states, drawn once as SVG and specified once. A new casino's floor becomes configuration, not design work.
-
Colour as the readable layer
In a dark room, on a tablet held at arm's length, colour does the reading before type does. Drop, hold %, win/loss, club states and junkets each get their own scale — with a legend that changes by context, because no one memorises twenty-four colours.
-
Designed for the floor, not the desk
Replace lid, cash drop, min/max bet, secondary authorisation, quick alerts to host, surveillance and housekeeping, end shift. Every action was designed as a task a supervisor can finish standing at a live table, one-handed, without a keyboard.
-
Specified sprint by sprint
Pre-login and casino/role selection, seated view, assign player, ratings, markers, floor view and dashboards, player tab, legend and seat indications — each handed over as a complete interaction document. I directed the account across the programme.
Every flow reached engineering as a complete interaction document — states, errors, edge cases, and the rules underneath them. Not "here is the language picker," but: eight options fit one column, nine split into two, seventeen into three, twenty-five start scrolling. The design system absorbed the variation so the build didn't have to.
Specify the rule, not the screen
Behaviour was written as rules with thresholds, not as a screen per case. Engineering built one thing that covers every casino, and the spec stayed shorter than the alternative.
Configuration is a design problem
Casinos differ by domain, roles, languages, card readers and table colours. Rather than design for one operator and patch the rest, we designed the axes of variation and let each floor configure itself.
The legend is a first-class screen
Two dozen colours and dozens of icons only work if the key is one tap away and scoped to what's on screen. The legend changes with the page — seated, floor, generic — instead of being one long chart nobody opens.