Rule Builder Engine

Before / After

Before

After

Process

The Problem, and Why It Existed at All

This project didn’t start with a brief. It started with me pushing for one.

The product had a rule-builder feature, letting users construct if/then logic without writing code, but it was inaccessible, had poor onboarding, and was inefficient to build on. The clearest evidence of how broken it was: it had already been redeveloped multiple times across different areas of the platform, and none of those rebuilds had actually fixed the underlying problem.

I gathered customer feedback pointing to this, and advocated for a proper fix, building support from other developers and product managers to get it prioritized, rather than waiting for it to land on someone else’s roadmap.

The Business Case

Getting this prioritized meant making a business case, not just a design case: three siloed product lines had diverged from a common ancestor, so every previous rebuild only patched one branch at a time without ever fixing the divergence itself. Three attempts, three product lines, still broken: that pattern is what I used to argue the fix belonged on the roadmap now, not after a fourth patch that wouldn’t hold either.

The Design Challenge

The core tension: this tool needed to support genuinely complex logic (nested if/then conditions), for an audience that mostly didn’t think in those terms. Most rule-builder or logic-building precedent comes from technical/developer tools, not a great match for non-technical B2B users trying to automate a workflow.

Constraints

Accessibility wasn’t optional: anything shipped needed to clear Vertex’s WCAG bar, which ruled out the fastest paths to a typical logic-builder pattern (drag-and-drop tree nesting, keyboard-inaccessible visual condition trees). The design also had to unify three product lines that had drifted apart, without breaking the rule logic each team had already built for itself.

Process

• Brainstormed several directions, then converged on the strongest candidate to test rather than trying to perfect one idea in isolation
• Synchronous user studies surfaced specific points of pain in the existing tool and in early concepts
• Competitive research deliberately looked beyond direct competitors, pulling patterns from logic-building and coding tools outside our category
• Fidelity progression: pencil sketches → Whimsical → Figma, moving from rough internal alignment to testable, high-fidelity prototypes
• Heavy collaboration and validation throughout: this wasn’t designed in isolation and thrown over the wall

The Solution

The final design let non-technical users build nested if/then logic through a guided, accessible interface, without needing to think in code. Along the way, I created new custom components for this, built to be accessible and reusable well beyond this one tool, which fed directly into the broader design system.

Outcome

User testing produced conclusive, strong results, validating the design and making it ready to be componentized: a solid testament to designing for clarity and accessibility from the ground up, rather than retrofitting it later.

Reflection

This project reinforced the value of trying out many low-fidelity options before committing to one direction, checking in with other teams along the way, and testing frequently rather than waiting for a polished version to validate. Those habits carried forward directly into how I approached later complex-logic work, like the transaction reconciliation project.