Designing a Scalable Decision Engine for Enterprise Policy

Overview

Policy analysts at Capital One were building complex decision logic in spreadsheets — copy-pasting rules between tabs, manually cross-referencing compliance constraints, hoping nothing broke downstream. I led design systems strategy to replace that fragile workflow with a modular, system-aligned interface for high-stakes, compliance-sensitive environments.

Try the live prototype: full onboarding flow or skip straight to the table.

The Problem

Analysts relied on a patchwork of spreadsheets and inconsistent UI patterns to define and manage complex decision logic. The cost was real:

• High cognitive load during rule creation
• Increased risk of error in critical workflows
• Inconsistent accessibility support
• Slow onboarding and poor pattern reuse across teams

The core issue wasn't missing features. It was structural ambiguity.

Constraints

• Compliance-sensitive domain with low tolerance for error
• Legacy interaction patterns deeply embedded in daily workflows
• Code base was using open-source Ant Design System instead of Capital One's Gravity Design System
• Need for incremental migration rather than a full rebuild

Strategy

Instead of redesigning screens, I focused on establishing a clear system hierarchy that could scale across use cases and teams.

The approach:

• Define a progression from tokens → core components → reusable patterns
• Encapsulate complexity rather than exposing it
• Treat adoption and governance as design problems, not enforcement problems

Teams could reason about complex logic consistently — without sacrificing flexibility.

From Fragmentation to Modular Workflows

We replaced spreadsheet-style interfaces with modular workflows that made logic explicit and predictable.

• Centralized a shared component library (Figma and Storybook) as the single source of truth
• Defined repeatable interaction patterns for common analyst tasks
• Created a migration roadmap aligned to system maturity

The onboarding flow walked analysts through a three-step setup on a single page: choosing an outcome type, naming the model, and selecting the data elements it could evaluate. Each step was scoped to a single decision, reducing cognitive load before reaching the main interface.

Design goals

• Surface upstream dependencies and validation states
• Reduce interaction cost for defining logic
• Support both novice and expert analyst behaviors

Each rule row maps a data attribute to an operator, a threshold value, and a decision outcome. The inline edit model (badge tap to swap attribute, dropdown for operator, direct input for value) eliminated the modal-heavy workflows analysts had been tolerating, cutting the path to a saved rule from eight clicks down to three (a 63% reduction).

Impact

In discovery testing, analysts completed 12 of 13 tasks against the new model, with markedly lower error rates during rule creation than the spreadsheet baseline.

Live Prototype

A public-safe, runnable version of the prototype is live: try the full onboarding flow or skip straight to the table. It's an open-source extraction of the rule-row pattern, rebuilt in React, TypeScript, and Vite. It strips out the proprietary domain logic, keeps the interaction model intact, and ships the result as a reference implementation for the same class of decisioning interface.

Onboarding: three decisions, one page

Rather than dropping users into an empty editor, the prototype opens with a guided three-step setup: pick an outcome type, name the model, then choose the data the model is allowed to evaluate. Each step is scoped to a single decision, and the whole flow lives on a single scrollable page so the model's shape stays visible while you build it.

The rule table

Once setup is done, the model opens into the main editor: a five-row example ruleset showing each rule as a single line with name, data attribute, operator, value, optional companion attributes, and the outcome.

Segmented Approve / Deny outcome

Each row's outcome is a segmented two-state control: green Approve on the left, red Deny on the right, with the unselected side rendered as a muted ghost. It's faster than a dropdown for binary outcomes and reads at a glance when scanning a ruleset.

Split-button progressive disclosure

The primary CTA is a split button: the main face is + Add rule (the common path), and a chevron beside it opens a small menu with the secondary action, Add existing rule. The split keeps the default action one click away while making the alternative discoverable rather than buried in a kebab menu.

Accessibility as a System Lever

Accessibility improvements were embedded at the system level rather than treated as retrofits.

The results:

• ~30% improvement in accessibility compliance
• Clearer focus states and keyboard navigation
• More predictable interaction behavior across components

Accessibility became a forcing function for better structure and clarity.

Outcomes & Impact

• Unified interaction patterns across a critical enterprise workflow
• Faster analyst task completion in usability testing
• Reduced design and QA overhead through shared tokens and components
• Established a scalable foundation for future platform growth

Next Iterations

• Expand the component library to support new data interaction models
• Refine token architecture for faster theming and dark mode support
• Deepen async contribution rituals to scale governance sustainably

Reflection

In complex enterprise systems, clarity is a performance feature. This work reinforced that scalable UX isn't about simplifying problems. It's about making complexity legible.