Draw Operations Console

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. What it couldn't do was run a real draw. Different events required different patron eligibility criteria — tier status, gaming activity, patron type — but the tool had no way to configure that. The backdrop display that showed winners on screen was static, unbranded, untouchable. Operators were working around a product that had stopped growing before the job was done.

Mapping the territory — Analysis

I started by pulling apart what the existing system actually did — not just execute it straight away. Working with the BA team, I documented the operator workflow from event creation to post-draw reporting, including the workarounds that had quietly become standard practice. What surfaced wasn't a list of missing features. It was 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 remaining usable by an operator at a casino floor console on event, was the part of this project that required 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 and adjust rather than rebuild from scratch. 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.