Casino lucky draws look simple from the outside. From the inside, they're a web of eligibility rules, real-time decisions, and live-event pressure that the original system was never designed to handle.
Operator-Facing · Casino & Gaming
The system existed but couldn't handle a real draw. Different events required varied patron eligibility criteria (tier status, gaming activity, and patron type), but the tool lacked configuration options for these.
The winners displayed on the screen were static, unbranded, and unchangeable. To improve operator control over the drawing system, the dashboard should be adaptable to different criteria, responsive across various screens, and simple to operate. This will ensure the operator can run the draw smoothly, maintaining an engaging experience for patrons at the casino event.
Mapping the territory — Analysis
I started by pulling apart what the existing system actually did, instead of jumping straight into a rebuild. Working with the BA team, I walked through the operator workflow end to end: event creation, session setup, post-draw reporting, including the workarounds that had quietly become "the way it's done." That surfaced a clearer picture of what operators were actually trying to control.
The hardest problem
Patron list configuration was where the complexity lived. A lucky draw isn't a single list of eligible guests. Different draws have different criteria, and a single event can run across multiple sessions: each with its own winner count, countdown timer, claim window, and display configuration.
Designing a setup form flexible enough to handle all of that, while staying usable by an operator at a casino floor console during a live event, was the part of this project that took the most iteration.
Resolving it
The answer was a session-based structure: operators configure each session independently within a single draw, with the option to duplicate an existing session and adjust it. Patron list upload via CSV, with validation to catch duplicates and eligibility conflicts before the event starts, handled the data complexity upstream. The background display moved from a fixed asset to a configurable layer: video upload, theme selection, layout control, all editable in advance and previewable before going live.
Decisions, design, and collaboration
The live draw control panel had to work under pressure: start, pause, resume, trigger winners, all in real time. Every state change needed to feel unambiguous. Every confirmation had to be fast without being skippable.
None of it got resolved in the design tool. The real decisions came out of conversations, with BAs who knew the eligibility rules, developers who knew what the system could carry, and the operations team who'd be running the draw on the night. Each review surfaced something the brief hadn't captured.
