← Back

Jackpot Operator Dashboard

A multi-tenant control dashboard for slot-game displays running on screens in physical venues.

Project overview

Type: Client · 14-week engagement
Team: with 1 PM, 2 engineers, and operations stakeholders
Project type: B2B Admin Dashboard · Multi-tenant & Roles · Operational Tooling · Trust & Error-Prevention
Role: Lead Product Designer · Information Architecture · Systems Design · Interaction Design
Methods: Contextual inquiry · card sorting & tree testing · usability testing · A/B
Tools: Otter.ai · Optimal Workshop · Figma + Dev Mode · Amplitude · Statsig
Case thesis: Designing an operator dashboard where a change is previewed and confirmed before it reaches a screen on the wall, with controls scoped to each role, because a misconfiguration shows up in front of paying customers within seconds.

The context

Jackpot distributes slot games over the internet to TV screens set up in physical mini-casino venues. Operators manage those displays remotely from a dashboard, while a platform administrator manages client accounts, billing, and how many displays each client controls. A setting changed in the dashboard, like a jackpot amount or whether a display is on, appears on a screen in a room full of patrons almost immediately, so an error is public and on the floor rather than private and undoable.

The problem

Operators did not trust the dashboard to act on live screens. Nearly 47% of configuration changes were routed through the administrator or support rather than made by the operator directly (behavioral, change-log analysis), because operators could not predict what a change would do on the physical screen. When changes did go through, misconfigurations reached the floor at about 9 incidents per 100 changes — a wrong jackpot amount displayed, or a display gone dark during opening hours (operational, incident records).

The goal

Let operators configure live displays themselves, with confidence and within their permissions, and cut the misconfigurations that reached the floor, measured by self-serve change rate, floor-incident rate, and time to set up a new display, rather than by the number of controls exposed.

Empathize — Operators avoided live changes and routed nearly half through support, because a mistake shows up on the wall in seconds

In this section: Research foundation · Key insights

Research foundation (method)

Phase 1 — Operator and admin interviews (n=11, ~40 min, transcribed in Otter.ai): how they configure displays, what they avoid, and when they escalate.
Phase 2 — On-site observation (3 venues): watched operators make changes against the live screens during opening hours.
Phase 3 — Change-log and incident analysis (one quarter): share of changes routed through support, and misconfigurations that reached a live screen.
Phase 4 — Prototype pilot (Amplitude-instrumented, 14 operators across 6 clients, Nov–Dec 2024): behavior on the rebuilt dashboard.

Key insights

1. Operators could not see the live state, so they worked blind and escalated. The dashboard and the screen on the wall were disconnected: an operator could not tell from the dashboard which display was currently on, what game was running, or what jackpot was showing. Triangulation:

Behavioral: 47% of changes were routed through admin or support.
Observational: operators walked to the floor or phoned the venue to confirm a display's state before and after a change.
Verbatim — coded: Fear of the live screen: "I'm not touching the jackpot during open hours; if I get it wrong, it's on the wall and everyone sees it."

2. Misconfigurations are public and costly when they land. A wrong coin or jackpot amount displayed to patrons, or a dark screen during business hours, was a floor incident, running about 9 per 100 changes, and the operator often learned of it from the venue rather than the tool.

Operational: mean time to notice a bad change was long because nothing in the dashboard flagged it.

3. The role model was too coarse, so admins became the bottleneck. On-site operators either had access broad enough to touch billing and other clients, or so narrow that routine setup required the administrator, which routed safe, everyday tasks through one person.

Verbatim — coded: Permission mismatch: "For a simple title change I have to message the admin and wait, even though it's my own screen."

Dashboard — Why operators escalate instead of acting

Why operators escalate instead of acting
Scope: change log + incidents · one quarter · coded
Guiding question: Why don't operators configure their own displays?

  Changes routed through admin / support .... 47%
  Floor misconfigurations per 100 changes ... 9
  Operators confirming state off-dashboard .. observed at all 3 venues
  Routine tasks requiring admin permission .. common

Key Insight: Operators escalate because the dashboard hides the live state
and offers no safe way to change it, so support absorbs the work.

Define — Operators had to preview a change and see every display's live state before it reached the floor

In this section: POV · How Might We · Principles · Insight→decision map

POV statement. On-site operators need to change a live display and see the result with confidence, within the permissions their administrator sets, because a misconfiguration appears on a screen in front of customers within seconds.

How Might We

How might we show every display's live state in the dashboard so it matches the wall?
How might we let an operator preview a high-impact change before it reaches the physical screen, and recover if it is wrong?
How might we scope each role to the controls its job needs without exposing billing or other clients?

Design principles (each traceable to an insight)

The dashboard mirrors the wall. Every display shows its live status, current game, and current jackpot. (Insight 1)
Preview before live. High-impact changes are previewed and confirmed; low-impact ones apply directly. (Insight 2)
Scope controls to the role. Each role sees the controls its job requires and nothing beyond. (Insight 3)
Legible for a venue back-office. A dark theme with blue accents holds up during long shifts without fatiguing the operator. (use-context constraint)

Insight → decision map

Insight (from Empathize)	Concrete design decision
47% of changes escalated; the live state was hidden	A live display grid shows each screen's on/off state, running game, and current jackpot, so the dashboard and the wall agree
9 floor incidents per 100 changes, noticed late	High-impact changes (jackpot, coin amount, on/off) open a preview and require confirmation, with bounded inputs that block impossible values
Role model too coarse; admin is the bottleneck	A scoped permission model: admins manage accounts, billing, and display caps; operators control only their own displays and safe settings

Ideate & Craft — The dashboard mirrors the wall: a live display grid with preview-and-confirm on the changes patrons see

In this section: Design execution · Before → after · Other deliverables

Design execution

Live display grid — every display is a card showing on/off state, the running game, and the current jackpot, so an operator reads the room's screens from the dashboard.
Preview-and-confirm for high-impact changes — adjusting a jackpot or coin amount, or switching a display off, shows a preview of the result and asks for confirmation before it goes live; low-impact edits like a custom title apply directly.
Bounded controls — sliders for time and jackpot amounts and dropdowns for roles and games carry validation, so an operator cannot set an out-of-range or invalid value.
Role-scoped views — administrators manage client accounts, payment dates, and display allotments; operators see only their displays with the safe daily controls, including copy-link and on/off.
Inline feedback — clear save, success, and error states tell the operator what happened to the live screen and how to recover.

Before → after

	Before	After
Knowing a display's state	Phone the venue or walk the floor	Live grid shows state, game, and jackpot
Changing a jackpot during hours	Avoided, or routed to admin	Preview, confirm, applied with feedback
Routine title or link change	Required admin permission	Operator does it within their own scope
Invalid value	Possible, surfaced as a floor error	Blocked at input by bounded controls

Other deliverables

Built in Figma with Dev Mode handoff: a role-scoped component library so admin and operator views share one system while exposing different controls, the live-grid and preview-confirm states, and the dark, blue-accented theme tuned for long back-office shifts.

Dashboard — Self-serve changes rise as floor incidents fall

Self-serve changes rise as floor incidents fall
Scope: Last 30 days · pilot (14 operators, 6 clients)
Guiding question: Did operators configure their own displays without errors?

  Changes made by the operator directly .... 53% → 88%
  Floor misconfigurations per 100 changes .. 9 → 1.5
  Time to set up a new display ............. 18 min → 6 min

Key Insight: The live grid and preview step moved configuration from a
support task to a confident self-serve one, with far fewer floor errors.

Prototype / Test — Applying changes instantly felt faster and raised floor incidents; confirming high-impact changes cut them and got operators to self-serve

In this section: The experiment · What it taught

The first build applied every change instantly to feel responsive, with no confirmation step. It was A/B tested against preview-and-confirm on high-impact changes in Statsig across the pilot.

The failed variant. Instant-apply was the fastest path per change and tested as more responsive in first impressions, but floor misconfigurations rose to 11 per 100 changes, and operators kept routing high-impact changes through support because they did not trust an instant live edit. The confirmation step that looked like friction was the thing that let operators act on their own.

Instant-apply is fast and lands errors on the floor
Scope: Statsig A/B · pilot · n=2 variants
Guiding question: Which model lets operators self-serve without floor errors?

  Variant A — Instant apply, no confirm
    Median time per change .......... fastest
    Floor incidents per 100 changes . 11
    Operator self-serve rate ........ 58%

  Variant B — Preview + confirm (high-impact)
    Median time per change .......... +1 step
    Floor incidents per 100 changes . 2
    Operator self-serve rate ........ 84%

Key Insight: With a public, physical screen at the other end, a confirm
step builds the confidence that gets operators to act, so self-serve rose
and floor errors fell. Variant B shipped for high-impact changes.

What it taught. When a control has an immediate, public consequence, confidence matters more than speed per action; a confirmation that would be needless friction in a private SaaS tool is protection when the output is a screen in front of customers.

Outcomes & reflections

In this section: Causal chain · Reflections

Causal chain (pilot, 14 operators across 6 clients)

The live display grid made each screen's state visible and preview-and-confirm let operators change high-impact settings with confidence, which moved configuration from a support task to self-serve (operator-made changes 53% → 88%), which cut floor misconfigurations from 9 → 1.5 per 100 changes and freed administrators from the change queue, while role-scoped controls let operators handle routine setup without exposing billing or other clients, dropping time to set up a new display from 18 → 6 minutes.

Metric	Before	After	Δ
Operator-made (self-serve) changes	53%	88%	+35 pts
Floor misconfigurations per 100 changes	9	1.5	~−83%
Time to set up a new display	18 min	6 min	−67%
Changes routed through admin / support	47%	12%	−35 pts

Scale note: at a fleet of many displays across many venues, cutting escalations from 47% to 12% removes the administrator as a daily bottleneck, so adding clients no longer scales support load one-to-one.

Reflections (transferable principles)

When a control acts on something public and physical, the design's job is operator confidence, so a preview-and-confirm step earns its cost where instant action would not.
In a multi-tenant tool, the permission model is the core information architecture: scoping each role to the controls its job needs is what keeps a junior operator productive and a shared platform safe.
A dashboard that mirrors the real-world state it controls turns escalations into self-serve work, because operators act when they can see the consequence before committing to it.