A rule engine that stays legible at any depth
The operator needed to build casino bonuses with targeting logic that could combine any number of behavioral, temporal, financial, and account-state conditions, nested to any depth. Most rule engines break down past three levels. This one had to stay scannable at five.
ROLE
Sole designer, requirements → handoff
SURFACE
Operator Backoffice · 3-step wizard
OUTCOME
In production · targeting logic unmatched in the industry
The problem
A casino bonus isn't a coupon code. It's a business rule with real economic stakes: who qualifies, under what conditions, which games count toward the wagering requirement, at what rollover multiplier, within which time window, up to what maximum payout. Configured wrong, the operator loses money to bonus abuse. Configured too narrowly, the promotion doesn't reach the players it's meant for.
The existing tooling let operators configure basic bonuses: flat amounts, simple time windows, single conditions. Anything more complex meant a rigid template or an engineering ticket. Every promotional campaign was a negotiation between what the business team imagined and what the system could express.
The ask was to close that gap: a configuration UI where the operator could express the full range of business rules in the product itself — without engineering involvement, without rigid templates, and without drawing the rule tree on a whiteboard first.
Constraints & role
I was the sole designer on the operator's Backoffice, which made this project solo-owned from requirements through final handoff. The PM defined the business-logic scope — which rule primitives to support, which variable types to expose. Engineering had to build a backend capable of evaluating arbitrarily nested rule trees. My job sat in the middle: translating a rule language into a UI a non-technical operator could actually use.
"Non-technical operator" is the critical framing. The primary user isn't a developer or an analyst — it's a promotions manager. Someone who thinks in business outcomes ("a weekend bonus for players who deposited this week and haven't withdrawn in 48 hours"), not in boolean logic. The UI had to close the gap between business language and rule trees without asking the user to learn rule-tree syntax.
The approach
The feature is a three-step wizard that decomposes bonus configuration into three independent concerns. Step 1, bonus template: the metadata — name, dates, risk group, KYC requirements, usability caps, timezone handling, per-language content, asset uploads. Everything set once and rarely revisited. Step 2, activation rules: the rule engine itself. Step 3, eligible games: which games the bonus applies to, and how each weights toward the wagering rollover — slots at 1×, premium branded games at 3×.
The separation matters: metadata, logic, and game eligibility are three different cognitive tasks. Forcing them into a single form would have produced exactly the overwhelm I was designing against.
Key decisions
DECISION 4.1
Chip tree over nested forms
Nested forms break at depth three. This engine had to stay readable at five-plus. So the UI is a horizontal chip tree: each nesting level is its own labeled row, "R" badges mark chips with rules attached, dashed outlines mark empty slots, and selecting a chip opens a master-detail configuration panel on the right.
The reasoning +
The default pattern for rule builders is a nested form: indented conditions, expandable groups, AND/OR combinators. It works at two or three levels and breaks at five, because the eye loses track of which sibling group it's in and the scroll distance between related rules grows faster than the UI can absorb.
The chip tree flattens the depth dimension into rows. The tradeoff is deliberate: configuration details hide behind a click, but the shape of the tree is visible at a glance — and for a non-technical user, the shape matters more at the scanning level. Details are one click away in the side panel: variable type, thresholds, timing, modifiers. Configure, save, next chip.
DECISION 4.2
Separating "Activator" from "Rule"
An Activator answers "when does this fire?" A Rule answers "under what conditions?" Separating them lets the operator reason about triggering and qualification as two distinct layers instead of one tangled boolean.
The reasoning +
The obvious design collapses both into "every node is a condition." Technically correct — any rule tree can be expressed that way — but it asks the operator to think like a developer: "does the deposit trigger this, or is it a requirement? Both?"
Splitting the concepts resolves the ambiguity before it happens. Activators live in the tree, forming the outline of "when." Rules attach to activators in the side panel, describing "who qualifies." Operators took to it quickly because it mirrors how they already talk about promotions: every Saturday and Sunday (trigger), for players who've deposited $125+ (rule), who haven't withdrawn in 48 hours (rule).
DECISION 4.3
Eligible games as a step, not a rule primitive
Game eligibility isn't a condition — it's a scope. Treating it as its own wizard step keeps the rule engine focused on player-state logic and lets the operator configure game-level economics independently.
The reasoning +
Game eligibility could have been rules inside the engine — "if game.type == 'slot'" — elegant from a technical standpoint, terrible for the operator. It's a list-based operation, not a conditional one. Operators think "which games count, and for how much," not if-then.
So Step 3 is a filterable picker with a results table: add by game type, vendor, or title; set the rollover multiplier per entry. No nesting, no combinators. Pulling it out also keeps the chip tree clean — Step 2 only expresses player-state and temporal logic, which is what it's good at.
Outcome
The bonus configuration system shipped and is in production across the operator's portfolio of casino brands. Non-technical promotions managers configure bonuses directly in the tool, without engineering tickets. Campaigns that previously needed a rigid template or a developer get built by the business team in an hour — with targeting logic the industry's off-the-shelf tools don't match.
I don't have quantified adoption metrics: a single-operator platform makes "adoption" look different than multi-tenant SaaS. What I can say is that the tool has been the primary way new bonuses are built since launch, and the three-step decomposition has held up across every campaign the operator has run through it.
What I'd do differently
Operators don't build the deep trees the system supports. Most bonuses use two or three levels of nesting; the unbounded-depth capability is rarely exercised. That's not a failure — a flexible tool doesn't become wrong when users don't use its full range — but it tells me the operator's real mental model lives closer to templates than to arbitrary logic trees. Five or six common patterns account for most of what they build.
Scoping it today, I'd pair the engine with a template layer: start from a named pattern — "Weekend bonus," "First deposit match," "Reactivation" — and adjust parameters, with the full engine underneath for the edge cases. A cheaper, faster path to the same outcomes for 80% of promotions, designed for the workflow operators actually have instead of the ceiling they don't touch.