Building the Guest Management Platform for the Olympic Games
PRODUCT
Olympic Hospitality Platform, Operational Tool, B2B/Enterprise, Data-Heavy System
TIMELINE
January - September 2025 (8 months)
ROLE
Senior Product Designer
FORMAT
Web
TEAM
Product Designer, Product Manager, Engineers, Quality Assurance, Business Analyst
IMPACT
Centralizing thousands of guest records, reducing manual workflows, and enabled data accuracy across all hospitality systems.
Guest Management Platform
Guest Management is the operational backbone of Milan 2026—a centralized platform that lets Olympic sponsors, partners, and internal teams manage thousands of guests across hundreds of hospitality packages. Previously, guest data lived in fragmented spreadsheets and siloed tools, creating errors that cascaded across the entire hospitality ecosystem. Guest Management became the single source of truth, powering 3 downstream systems: Seat Assignment, Accommodation Assignment, and Onsite services.
As Senior Product Designer, I led 0-1 design, collaborating with another designer to establish the information architecture and data model that 3 other products would be built against. I designed for two audiences: corporate partners & internal teams who needed intuitive bulk workflows despite limited technical expertise, and downstream systems that required strict data validation and real-time accuracy. I partnered with engineering to map complex business logic to the schema, designed the error-handling layer that made bulk imports reliable at scale, and built interaction patterns that now extend across TKO's Olympic hospitality management suite.
Problem
While designing the Hospitality Request Portal (HRP), a B2B e-commerce app in our hospitality management product suite, we discovered a critical gap: users could request packages, but had no way to manage the people behind those requests. These issues were well-documented from Paris 2024, where our PM had
worked directly with corporate partners and sponsors.
Guest data lived everywhere—spreadsheets, shared drives, email threads. This fragmentation created:
Duplicate records — Same guest entered multiple times across different systems, creating data mismatches
Status blindness — No way to know if a package was complete or what information was still missing
Manual coordination — People emailing spreadsheets back and forth to track progress
Last-minute scrambles — Operations teams discovering missing guest information days before events
My Role
Product Design
End-to-end design from discovery through launch. IA, user flows, interaction models, microcopy.
Design System
Extended HRP design system with new patterns. Table structures, status chips, progress indicators, annotations for handoff.
Cross-Functional Partner
Partnered with PM, engineers, QA, business analysts. Mapped UX to data models and technical constraints. Weekly design reviews and daily stand ups.
Strategic Influence
Shaped MVP scope by identifying usability-critical workflows, ensuring we shipped a stable, scalable product under fixed Olympic deadlines
Who I Designed For
Corporate sponsors, agencies, hospitality managers, and internal teams responsible for coordinating Olympic experiences for clients and employees. They have deep Olympic knowledge but limited technical expertise—many still prefer spreadsheets. They're juggling dozens of packages for different internal teams, often under extreme time pressure as the Games approach.
Visibility was critical. Our goal wasn't to build the most feature-rich guest management system, but the clearest one that met the most critical needs of our users and could scale across future Olympic Games.
Design Process
Understanding the Data Model
I worked with the PM and engineers to define how Guest Management would integrate into the broader ecosystem. A major focus: distinguishing between guest-level information (persistent across packages) and package-level information (varies by assignment). This separation prevented data cross-contamination and shaped how the interface would scale. A guest could be assigned to multiple packages, but their core contact information lived in one place.
Users needed to see both "Who is this person?" (contact info) and "What's their accessibility needs and hotel arrival times for THIS package?" (assignment details) without confusion.
DESIGN PROCESS
Homepage
The homepage needed to give users a complete view of all their packages and progress.
Design Decision: Tabbed Structure
Early concepts explored unified views and multi-column dashboards, but user interviews revealed sponsors thought in sequential modes:
The solution: Three tabs that let users focus on one job at a time:
My Packages (primary view) — See all packages and their completion status
My Guests — Review and complete individual guest profiles
My Managers — Delegate access to team members
The final design included:
Status count cards — All, Not Started, In Progress, Complete. Quick filtering without scrolling.
Package table with status chips — Supports easy scanning.
Guest count indicator — "10 of 50 guests assigned" shows progress at a glance.
Action buttons — Assign Guests, Continue, View & Edit. Next steps always visible.
Bulk Import card — High-volume workflow readily accessible for power users.
Exploration 1
Exploration 2
Final Version
DESIGN PROCESS
Guest Details Form
The problem: During Paris 2024, the guest detail form lived in a third-party system with poor information architecture and confusing copy. Completion rates were low and support was flooded with calls. Operations teams were missing critical information.
For Milan 2026, the form would be required and built directly into Guest Management. The design challenge: what information should we collect, and how should we structure it?
The core complexity: distinguishing between information about WHO the guest is (persistent across all packages) versus information that varied package to package (travel details).
I designed a form structure that made the guest-level vs. package-level distinction clear to users:
Personal Info section
Package section
Progress Checklist — Showed completion status for both sections. Users could fill what they knew, return later.
"Invite to Add Guest Details" Option — Let users delegate profile completion to the guest themselves. Honored real workflows for large organizations
DESIGN PROCESS
Bulk Import
Many users managed hundreds of guests in spreadsheets. While Guest Management offered structure, requiring individual entry would slow them down and hurt adoption.
Another designer created the Bulk Import card in the global header. I designed the validation and error handling layer—the dialogs and feedback states that made bulk upload reliable at scale.
Impact
Current Results
Thousands of guest records managed through unified platform
Single source of truth established for Milan 2026
Downstream modules (Seat Assignment, Accommodations, Onsite) pulling from unified data
Note: Full impact metrics will be available after the Milan 2026 Games conclude.
Reflection
What I Learned
"Boring" design is often the hardest design
Guest Management had no flashy features—just solid CRUD patterns, clear hierarchy, and reliable bulk actions. Making complex data management feel obvious required a lot of thoughtful work.
Foundation work is invisible until it's not. The accordion structure that seemed fine in Figma slowed users more than I predicted. I should have run lightweight prototype tests earlier rather than relying entirely on post-launch analytics.
Constraints breed creativity (and pragmatism)
Sometimes constraints push you toward better solutions than unlimited time would. But I also learned the difference between "good enough to ship under deadline pressure" and "optimal for users".
Understanding data = better UX
Working directly with engineers on the data model—distinguishing guest-level from package-level fields, mapping relationships between entities—taught me that understanding the database IS part of good design. You can't design intuitive interfaces for complex systems without understanding what's happening under the hood.
What I'd Do Differently
Shift to a booking-first model from day one
Guest Management was package-first instead of booking-first. In retrospect, a booking-first model would have aligned better with HRP's mental model and the model of other e-commerce experiences.
Run micro-usability sessions during development
Even 3-5 user tests would have helped us make better decisions for “sticky” parts of our flow.
Design for future growth upfront
As Guest Management became the data foundation for other products, evolving downstream requirements forced late-stage adjustments. We were defining the data model before dependent products were scoped, which meant some architectural decisions had to be revisited when integration needs became clear. Earlier cross-product planning would have helped us build the right extension points from the start.