Regulation Manager: Shared Compliance Infrastructure
Centralizing compliance work so product teams could ship regulation requirements without starting from scratch.
01 — Overview & Problem
What we were trying to solve
Consumer-protection legislation in secondary ticketing was accelerating, and Vivid Seats had a scaling problem: every new regulation meant each affected product team independently designed, built, and validated its own UI from scratch, with no shared foundation and no central place to manage requirements.
The goal: a purpose-built tool where legal could manage regulations directly, with outcomes reliably surfaced across products without every team starting at zero.
02 — My Role & Team
Where I fit in
As Senior Product Designer, I owned research, UX, and UI from problem definition through shipped product. With no dedicated PM, I also took on product definition: scoping the problem and defining the architecture before design. A core part of the work was translating legal and compliance concepts into a model engineering could build and legal could operate without technical help.
03 — Process
How I approached it
I started with stakeholder interviews across legal, product, and engineering before proposing a solution. Legal needed to configure requirements; product needed to trust what surfaced in their UI; engineering needed a stable, reusable layer without custom work per regulation.
Those conversations surfaced the core insight: a regulation wasn't one thing, but two layers that needed separate ownership. That became the Outcomes and Rules model. A Regulation Outcome is the customer-facing component, composed of Rules that legal configures and controls. Legal owns the rules without touching code; engineering consumes outcomes as stable components.
From there I built low-fidelity wireframes for rule creation, the most complex flow, prototyping and testing with legal before 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 shipped faster, but it would have recreated the same problem: legal writing freeform requirements engineering had to interpret from scratch each time. Structured Outcomes and Rules gave legal ownership of compliance logic without engineering involvement every time something changed.
Designing the rule creation flow for non-technical users
Legal users weren't technical, but the rules they configured had real product implications. The flow needed to prevent errors without feeling built for engineers. Usability testing directly shaped how triggers were selected and state communicated. Interactions that read clearly in wireframes needed more explicit confirmation once real legal users tried them.
Taking on product definition without a PM
With no PM, scope and architecture fell to me: front-loading stakeholder interviews, 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 I would have missed it entirely if I'd gone straight to wireframes.
05 — Outcomes & Results
What actually shipped
Outcomes management
A structured view of all regulation outcomes, each a customer-facing component composed of configured rules, with a single view showing the rules that comprise it and their current state.
Rule creation flow
A step-by-step flow letting legal configure rules without engineering involvement, 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 speed: after a new regulation passed, teams had a stable, configured output to build from instead of scoping and building independently.
06 — Lessons Learned
What I'd do differently
The most valuable investment was time spent with legal, product, and engineering before touching UI. The Outcomes/Rules model came out of those conversations, not the brief. On tools built for non-design stakeholders, the domain model deserves the same rigor as the interface.
I'd also think earlier about ongoing management, editing rules, deprecating outcomes, not just initial creation. That would have made the tool more durable from day one.