Regulation Manager: Shared Compliance Infrastructure

01 — Overview & Problem

What we were trying to solve

Consumer-protection legislation in the secondary ticketing market was accelerating, and Vivid Seats had a scaling problem. Every time a new regulation passed, each affected product team independently designed, built, and validated the required UI components. No shared foundation, no central place to manage requirements, no way to reuse work across products. Every new law triggered the same scramble.

Legal had no centralized way to track or manage the growing list of regulations. Engineering had no reusable layer to build from. Product teams were absorbing compliance work that should have been solved once.

The goal: a purpose-built internal tool where legal could manage regulations in a structured way, with outcomes that could be reliably surfaced across products without each team starting from zero.

02 — My Role & Team

Where I fit in

As Senior Product Designer, I owned user research, UX, and UI design from initial problem definition through to final shipped UI. There was no dedicated PM, so I also took on much of the product definition work: scoping the problem, synthesizing stakeholder needs, and defining the architecture before moving into design.

I worked across legal, engineering, and product — three teams with meaningfully different needs and vocabularies. A core part of the work was translating legal and compliance concepts into a product model that engineering could build and legal could actually operate without technical help.

03 — Process

How I approached it

I started with stakeholder interviews across legal, product, and engineering before proposing any solution. Each group had a different relationship to the problem: legal needed to configure and manage compliance requirements; product needed to trust that what surfaced in their UI was accurate and up to date; engineering needed a stable, reusable layer they could consume without custom work for every regulation.

Those interviews led directly to the architecture. The key insight was that "a regulation" wasn't a single thing — it had two distinct layers that needed to be owned separately. That led to the Outcomes and Rules model: a Regulation Outcome is the customer-facing UI component, composed of Rules that the legal team configures and controls. Legal owns the rules without touching product code. Engineering consumes outcomes as stable, predictable components without needing to understand the compliance logic behind them.

With the architecture defined, I moved into low-fidelity wireframes focused on the rule creation flow — the most complex part of the experience for legal users. I built prototypes and ran usability tests with the legal team to surface unclear interactions and edge cases before moving to final UI.

04 — Key Decisions & Tradeoffs

The calls that mattered

Structured Outcomes/Rules model over a flat regulation list

A flat list with freeform fields would have been faster to design and build, but it would have recreated the same problem in a different form: legal would still be writing freeform requirements that engineering had to interpret and implement from scratch each time. Defining Outcomes and Rules as distinct, structured concepts gave legal ownership of compliance logic without requiring engineering involvement every time something changed.

Designing the rule creation flow for non-technical users

Legal users weren't technical, but the rules they were configuring had real product implications. The flow had to be structured enough to prevent errors and guide users through consequential decisions, without feeling like a form built for engineers. Usability testing directly shaped how triggers were selected and how state was communicated — several interactions that seemed clear in wireframes needed more explicit confirmation and feedback once real legal users tried them.

Taking on product definition without a PM

With no dedicated PM, scope and architecture decisions fell to me. That meant being deliberate about separating problem definition from solution design — spending more time in stakeholder interviews before touching any UI, and treating the data model as a design artifact with the same rigor as the interface. The Outcomes/Rules model wasn't in the brief; it came out of those early conversations and would have been missed if I'd moved straight to wireframes.

05 — Outcomes & Results

What actually shipped

Outcomes management — A structured view of all regulation outcomes, each representing a customer-facing UI component composed of configured rules, with a single outcome view showing the rules that comprise it and their current state.

Rule creation flow — A step-by-step flow that let legal teams configure rules without engineering involvement, covering the full creation lifecycle from initial state through trigger selection, configuration, and confirmation.

A shared compliance layer — A single source of truth for regulation requirements that product teams could consume reliably, replacing the per-product, from-scratch approach.

Anecdotally, the biggest shift was in how quickly product teams could implement compliance requirements after a new regulation passed. Rather than each team independently scoping and building, they had a stable, configured output to work from.

06 — Lessons Learned

What I'd do differently

The most valuable investment on this project was the time spent with legal, product, and engineering before touching the UI. The Outcomes/Rules model only emerged from those conversations — it wasn't in the original brief. On any tool built for non-design stakeholders, the domain model is a design artifact as much as the interface, and it deserves the same rigor upfront.

With hindsight, I'd also think earlier about how the tool would need to evolve as the regulatory landscape changed — not just how it handled the regulations that existed at launch. Designing for ongoing management (editing rules, deprecating outcomes, handling regulatory updates) rather than just initial creation would have made the tool more durable from day one.

Taking on product definition without a PM also reinforced how important it is to make that role explicit when there's no one formally filling it. On this project it worked, but only because I was deliberate about it.