Case Studies > Rules

Rules: One Engine, Three Teams Who Don't Think Alike

A fraud and compliance rule engine that used to be code-only. Now it works two ways, so a risk analyst can write logic by hand and a compliance manager can build the same rule visually, without either one waiting on the other. The problem was never that people needed training: it's that two different kinds of people were being asked to use the tool the exact same way.

Editor Modes (Code + Visual)

Trigger Events Covered

Attribute Categories (Fraud, Bonus, Compliance)

Action Types (Block / Account / Notify)

Role: Sole UX Designer · Status: Shipped

Methodology

// Reviewing the old tool, spotting two kinds of users, borrowing what works, building both modes together

01 / REVIEWING THE OLD TOOL

Reviewed the existing Rules tool across Fraud, IP, Game, Country, and Serial restriction tabs. A single free-text condition block per rule, written in a Drools-style expression language.

02 / SPOTTING TWO DIFFERENT USERS

Identified that rule authorship splits along technical comfort: risk/fraud analysts who think in expressions, and compliance/bonus-ops staff who think in conditions and outcomes.

03 / BORROWING WHAT ALREADY WORKS

Looked at how modern rule builders solve this (visual condition trees, plain-language previews, organized attribute lists) and brought the good parts into both editor modes, without losing any power for people who prefer code.

04 / BUILDING BOTH MODES TOGETHER

Designed the code editor and visual builder side by side so neither reads as the "real" tool with the other bolted on. Same attributes, same actions, same live preview.

Cohort Profile// Three roles, one engine

Who uses this

Same rule engine, two different relationships to the logic.

Risk & Fraud Analyst

Technical. Thinks in expressions, moves fast in code

“I already know what I want to write. I just want the field names at my fingertips instead of memorized.”

Comes Here To

Write precise condition expressions quickly, using autocomplete instead of memorizing field names
Reference suggested attributes for a given trigger before writing from scratch

Fights With

Old tool's fact tree was a separate, disconnected reference panel with no autocomplete or click-to-insert
No plain-language readback meant re-reading raw expressions to sanity-check logic

Compliance / Bonus Ops Specialist

Less code-comfortable. Thinks in conditions and outcomes

“I know exactly what should happen. I just don't want to be the one who has to write it in a language I don't speak.”

Comes Here To

Assemble a rule from a category-organized attribute list without writing any expression
Check the live rule preview to confirm the logic reads the way they intended

Fights With

Old tool offered no non-code path at all. Any rule change meant asking someone else to write it
No visibility into whether a rule change was "ready" before submitting it

Compliance Manager / Auditor

Read-focused. Reviews rule history, not just rule logic

“A version number tells me something changed. It doesn't tell me why, or whether I'd have approved it.”

Comes Here To

Open a rule's version history and read why a threshold or condition changed, in plain language
Confirm who last edited a rule and when, without cross-referencing tickets

Fights With

Old tool's versioning was just a confirm dialog with no diff, no author, no reason captured
No structured place for the "why" behind a threshold change to live

What The Legacy Tool Got Wrong// 6 issues found

Where the old tool ran out of road

Critical · 2

High · 2

Medium · 2

One Way of Working, Forced on Everyone

critical

Conditions were a raw Drools-style expression, full stop. No non-code path. Every change required writing executable-looking rule syntax.

Shallow Audit Trail

critical

Versioning was a confirm dialog, not a record. No diff, no author attribution, no field for why the change was made.

Nothing Translated the Logic Into Plain English

high

Nothing translated the expression back into a sentence a reviewer could sanity-check. Re-reading raw syntax every time, for every reviewer.

You Couldn't Pull a Field Into Your Rule Without Retyping It

high

The fact-tree browser was look-only, not click-to-insert. Field names had to be manually retyped with no autocomplete.

One Condition Block Per Rule

medium

No branching. A rule could express one IF/THEN path. Rules needing different logic for VIP vs new accounts had to be split into separate rules.

Flat, Unlabeled Action List

medium

THEN actions were a single dropdown with no grouping. Block-type, account-type, and notify-type all in one undifferentiated list.

Redesign Direction

Six decisions, each answering a specific gap

01 / DUAL EDITOR MODE

Code editor and Visual builder are peers. A toggle switches between them per rule, and both produce identical underlying logic.

02 / ATTRIBUTE BROWSER WITH CONTEXTUAL SUGGESTIONS

Attributes organized by category, tagged by type (NUM, ENU, BOOL, TXT), with "Suggested for this trigger" surfacing relevant fields first.

03 / BRANCH-BASED VISUAL BUILDER

A rule can now hold multiple branches, each with its own AND/OR condition set and THEN actions. No more splitting logic into disconnected rules.

04 / LIVE RULE PREVIEW

A running plain-language readback of the rule appears in both modes as it's built. The comprehension check the old tool never had.

05 / GROUPED, COLOR-CODED ACTIONS

THEN actions organized into Block (red), Account (orange), and Notify (green) groups, so severity is visible at a glance.

06 / ATTRIBUTABLE VERSION HISTORY

Every saved change produces a version with human-written description, author, and timestamp. Reviewable without leaving the tool.

Rules · Selected Screens

The shipped redesign, across both editor modes

Rules Library

Filterable list of all configured rules.

Visual Builder

Conditions & Actions

Code Editor

Attribute-Aware

Rule Detail

& Version History

Related Case Studies →

Player Profile: Six Teams, One Overloaded Screen Payments: Where Money Meets Usability Risk

← Back to Top