Rule Builder Engine

Before / After

Before

After

Process

The Problem, and Why It Existed at All

A large client needed their own systems to be accessible, and since they relied on this feature in the product, it had to be accessible too. The feature was old and complex enough that it couldn’t just be patched: it had to be rebuilt completely. (That client didn’t use the other product lines that had their own rule builders yet, but it would eventually, so I planned for that from the start rather than treating this as single-product work.)

Beyond accessibility, the tool itself was in bad shape. Building a rule was hard, and just as hard to test or verify once built. Documentation was thin, with little explanation of common use cases. Even well-meaning parts of the interface added confusion: a “scratch pad” existed with no documentation of what it was for (it let you drag pieces of a formula out of the input to fix them without breaking everything else), and most people had no idea it was there. Rules were so complicated to build that many users just contacted support and had someone build the rule for them.

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. I could make that case with real weight because I could see across silos: I already knew the other product lines relied on the same rule builder, even though most people working on any one of them couldn’t see past their own.

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.

Accessibility, and Who It’s For

Good accessibility isn’t a tax on the general experience, it makes the product better for everyone, not just people using assistive technology. That shaped who I designed for here: people who’d never built a rule before and needed to be walked through it step by step, and power users who wrote rules many times a day and needed to move fast. The same accessible, guided structure that made the tool learnable for the first group also made it faster and more reliable for the second.

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.

Not breaking existing rules during the transition was its own constraint. We audited every function to migrate it over and found an outlier: one function, for no clear reason, allowed nesting up to 99 levels deep. Rather than carry that into the new requirements by default, I asked around to see who actually used that much nesting. One customer did, a dozen levels deep, and it turned out to be a test account. I dropped the 99-level requirement rather than design and build for a case nobody actually had, saving real time and complexity down the line.

Getting this built also meant navigating engineering politics, not just engineering limits: because the rule builder touched multiple teams, whose developer hours would pay for the rebuild became its own negotiation, and I had to get feedback and buy-in from every department that touched it so nothing got missed.

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
• Confirmed requirements with subject matter experts before design and build started, rather than assuming
• Ran in-person usability tests, recording both screen activity and think-aloud narration rather than relying on written surveys
• Designed tests around specific goals and tasks, not open-ended opinions, since “I like it” or “I don’t like it” doesn’t tell you what to fix
• Accounted for the fact that people were used to the old, unintuitive design: any change asks someone to stop and relearn something mid-workday, so testing had to separate real usability problems from simple unfamiliarity

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 for both longtime users and first-time ones: new users understood how to construct a rule on their first attempt, a sharp contrast to the old tool, and every test ran faster and more accurately than the original. One longtime user summed up the before state during preliminary interviews: “I’ve used this daily for the past two years, I didn’t know I could do that!” After testing the new version, participants who’d never touched a rule builder said things like “I’ve never built a rule but I was able to figure it out so quickly,” and people who used the old tool daily said, “I spend so long editing these rules, this will save me so many hours each month.”

The accessibility problem that started this project got solved too: the new design passed accessibility testing outright. Because the component was rebuilt once and shared across the three product lines instead of patched separately in each, rolling it out to the other product lines took minimal extra implementation time, fewer new customers needed to hire outside consultants just to get their rules set up, and people spent far less time building rules in the first place.

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.