How I turned one-off ticket launches at Netflix House into reusable frameworks, a shared taxonomy and investigation checklist adopted by Ops and Engineering.

From one-off launches to a repeatable playbook: designing the system behind the ticket.

ROLE
Product Design Lead, House XD, Project Lead, self-initiated

CATEGORY
Information Architecture & Taxonomy, Service Design, Design Operations

SCOPE
Ticket concept taxonomy, product setup archetypes and data mapping, workstream investigation framework

THE CHALLENGE

Every new ticket idea was approached as a one-off, so each launch re-discovered the same gaps across teams and systems. I created a shared language for what makes a ticket concept different, and a per-workstream checklist for what must be investigated before it ships. Ops now uses it to spin up new ticket types faster, and Engineering is using it to shape Offerings management.

Concepts kept multiplying: fan packs, multi-attraction bundles, child units, VIP packages, arcade credits. Each combined date logic, product structure, pricing and perks in new ways.
The ecosystem is hybrid: owned UI (offers, cart, checkout) hands off to a 3rd-party platform (3P) and back, then out to email and SMS. A change in setup ripples everywhere.
No shared vocabulary: Ops, Product, Engineering, Finance & Strategy, and Marketing each described the same ticket differently, so requirements were hard to articulate across partners.
Late surprises: issues like missing durations on bundles, reminder emails only covering the first included product, or product order breaking the date-picker surfaced late.
Key tension: speed of launching business-driven concepts vs. the hidden cost of each one touching 5+ surfaces.

FRAMEWORK 01

A taxonomy for ticket concepts

The Ticket Details Card (Concept Attributes)
Any ticket concept can be described by six attributes, and that description predicts what has to be built.

Date & Time Functionality: Pick Your Date, Pick Your Time, Any Time
Attraction Count: Single Attraction, Multi-Attraction
Included Products: Single Product, Packaged Product (Hide Extras), Bundled Product (Show All)
Usage / Redemption: Single Use, Mixed Use (Single + Multi-Use), Attraction + Lounge Access
Pricing Structure: Dynamic, Variable, Multi-Unit, Fixed
Perks: Priority Entry, Merchandise, Food & Beverage, Lounge Access

Product Setup Archetypes (Implementation Details)
Each archetype is paired with annotated UI and data mapping (mobile and desktop) showing exactly which field maps where.

Integrations with 3P platforms meant that certain implementation rules had to be followed, such as when I discovered the most-restricted product must be first in the platform to ensure a clean bundle flow, with selections not impeding one another.

Areas to investigate
Each new attribute points to a likely risk area. Three examples:

Single → Multi-Attraction: one booking now held several products, each with its own date and time, so the existing data pattern no longer fit.
Any Time: no time is returned, so every surface that normally shows a time needed a fallback.
Mixed-use Redemption: transactional messages had to explain clearly how each part of the ticket is redeemed, so guests could actually use what they bought.

Tags in pink flag what is new or non-standard, so anyone can see at a glance where the risk is.

Example of annotated UI and data mapping (mobile and desktop).

Example of an investigation into how a user's entry point to the flow impacted the data returned to the cart.

FRAMEWORK 02

What to investigate for every new ticket concept

Five workstreams, each with one guiding question and a visible status, turn "is this ready?" into something every partner can answer.

Offer Merchandising
Can the new ticket product be merchandised effectively on web?

Content & Data Mapping
Does all content and data map as expected through each of the consumer-facing flows?

3P Product Setup
Is the ticketing setup clear and working as intended?

3P Transactional Messaging Setup
Do email and SMS work as intended?

Assets & Creative Copy
Do existing visual assets and copy placements meet all needs?

Each workstream carries a simple status: Investigation Complete, Under Investigation, Changes Required, or Blocking Issue. I deliberately scoped each of these to the XD investigation, not design readiness for Engineering, which kept expectations honest across teams and allowed for design time to continue after the investigation wrapped up.

The framework lives in two formats: a Figma status board for at-a-glance tracking, and the specific Figma pages per concept for deeper dives into each workstream and its enablement considerations. Because each workstream asks one clear question, partners know exactly what is needed from them, and other designers have a broad checklist for what to look at when a new concept lands.

Proof in practice: multi-attraction bundles

Multi-Attraction Bundles put every workstream to the test. Running the concept through the framework showed early what was ready and what would block launch.

Ready: Bundles fit into existing Realtor offer placements with no new design work. Existing assets covered the creative needs.
Needed changes: The booking item couldn't show several products, each with its own date and time, so I defined a new data pattern for Engineering to ensure user clarity. Reminder emails covered only the first product in a bundle and also had to be fixed before launch.
Open questions: The 3P platform flow worked for web (quantity first, then a date and time for each included product), but setup details still needed confirming with other partners.

The same framework successfully guided the launch of multiple other ticket concepts in a short timeframe (Fan Packs, Child Ticket Support, and time-based arcade credits). It also helped the team decide what not to ship: (redacted) and (redacted) Offers were held after investigation.

Impact & Adoption

The frameworks outgrew design: multiple groups now use them for their own work.

Operations: Uses the taxonomy to spin up new ticket types faster. The shared language gives non-technical teams a clear view of each attribute and archetype, so they can adjust or drop nice-to-have details when the technical cost is too high.
Engineering: Adopted the concept attributes and setup archetypes into new Offerings management. They now shape the data model and field names, and will be surfaced in internal tools.
Marketing and Experiences partners: Enabled to work from clearer, per-workstream asks. They can frame a new concept so its technical complexity and its marketing positioning are both clear from the start.
Other designers: Have a broad checklist for what to investigate when a new concept lands.

Launched concepts are organized into "Previously Launched, Limited Testing Needed for Reuse," and "Business as Usual" creating clear reuse patterns instead of one-offs.

Reflections

I started these frameworks on my own initiative. I saw the same gaps slowing down every team, and an opportunity for us to work together more effectively. A few things made them stick:

Make the invisible visible: The most valuable artifact wasn't a screen. It was a shared description of the product that gave every team the same language.
Separate investigation from readiness: Labeling status as an XD investigation avoided false confidence between teams and protected design time to respond to what we found.
Design for reuse: Each launch added to the archetype library, so the next similar concept cost less. Knowing what had already shipped also let us choose deliberately when to stay consistent and when to diverge.