Redesigning the Hospitality Request Portal for the Olympic Games
PRODUCT
Olympic Hospitality Platform, E-Commerce, B2B/Enterprise
TIMELINE
June 2024 - March 2025 (9 months)
ROLE
Senior Product Designer
FORMAT
Responsive Web
TEAM
Product Designer, Product Manager, Engineers, Quality Assurance, Business Analyst, User Researcher
IMPACT
Absorbed 2 major business pivots to deliver 14.7% conversion and establish the design system foundation for 3 Olympic products—creating patterns that scaled from Milan 2026 to LA 2028 planning.
Hospitality Request Portal
The Hospitality Request Portal (HRP) is a B2B e-commerce platform where corporate sponsors and partners browse and request Olympic hospitality packages. Originally built for previous Games, the legacy system couldn't support Milan 2026's expanded package offerings and complex business rules without a fundamental redesign.
As Senior Product Designer, I co-led a complete UX overhaul alongside another designer, transforming what began as a visual refresh into a full platform redesign. We streamlined package selection flows, rebuilt the information architecture to handle constant business pivots, and established interaction patterns that achieved 14.7% conversion. The design system we created became the foundation for 3 interconnected products: Guest Management, Seat Assignment, and Accommodation Assignment—providing consistency across TKO's Olympic hospitality ecosystem.
Problem
HRP was a legacy B2B e-commerce platform that had worked for past Olympic Games, but Milan 2026 introduced new package types and business rules the system couldn't support. Without a structural overhaul, corporate sponsors couldn't accurately request or track hospitality packages—creating delays, data mismatches, and potential revenue loss.
The original scope: A light visual refresh with minimal UX changes to align with new brand guidelines.
But once we analyzed the system, the reality became clear: the platform couldn't handle the complexity we were introducing. Users already faced confusing navigation, unclear system feedback, and inconsistent terminology. Adding complex new packages to broken flows would make the platform unusable.
The legacy platform had critical usability issues:
No clear user flow — Redundant steps and multiple entry points that led to the same destination, creating confusion about the "right" way to complete tasks
No visibility into system status — Users had limited requests but no indicator showing when they'd hit their quota, leading to blocked actions with no context
Inconsistent language — "Edit" and "Draft" buttons placed together, both leading to the same place but using different terminology
Layout issues — Floating action buttons disconnected from their context, creating friction especially for non-technical users
Poor sorting and filtering — Approved, draft, pending, and locked requests mixed together with no way to prioritize or find specific items
Without fixing these foundational issues, sponsors managing dozens of requests for different internal teams would struggle to complete the most basic tasks—browsing packages, tracking approval status, and submitting requests on deadline.
Old Design 1
Old Design 2
My Role
Product Design
End-to-end UX/UI design co-led with another designer. User flows, IA, interaction design, visual design. Responsive patterns for desktop and tablet.
Design System
Built UI component library from brand guidelines. Established color palette, typography, spacing. Annotations for handoff.
Cross-Functional Partner
Partnered with PM, engineers, BA, QA, and researcher. Navigated business pivots. Advocated for users while balancing constraints.
Strategic Influence
Expanded scope from visual refresh to full overhaul. Established patterns adopted across 4 products. Built for unknown requirements.
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.
These users aren't casually shopping—they're managing complex procurement workflows for high-stakes events. The platform needed to feel less like consumer e-commerce and more like a request management hub.
Design Process
Discovery & Scope Shift
I worked with the PM and another designer to understand project goals, existing pain points, and technical constraints. The PM initially requested a visual redesign with minimal UX changes due to timeline pressure and development capacity, planning to push deeper UX improvements to a later release.
As we discussed the current user flows for requesting packages, it became clear that Milan 2026's package structure would be fundamentally different from Paris 2024. The existing flow—designed for Paris's simpler offerings—couldn't support Milan's expanded package types and configurations without major structural changes.
The other designer and I made the case that building the same experience twice (quick fix now, proper redesign later) would actually create more work than doing it right the first time. The PM agreed with the logic but was hesitant: their previous process required all designs to be complete before development could start, which would put the launch timeline at risk.
I proposed shifting to an iterative sprint-based approach: we'd spend focused time establishing the information architecture for the full site, then design and hand off key pages to development in phases while continuing to design remaining pages. This would allow development to start earlier and reduce timeline risk.
After discussing the new process, the PM was on board. We secured buy-in for a complete UX overhaul using iterative handoffs instead of a waterfall approach. This approach allowed development to start earlier and kept the project on track for launch despite the expanded scope.
DESIGN PROCESS
User Flows & Information Architecture
We mapped key user tasks based on product requirements and analysis of the legacy platform, then used those flows to inform the new information architecture. Rather than just redesigning screens, we focused on user goals and what elements were needed to achieve them efficiently.
Key flows we prioritized:
Browse packages with proper filtering & sorting
Create and manage multiple concurrent requests
Add packages to requests with correct configurations
Track request status through approval workflow
Make changes to draft requests before submission
This foundational work became critical when business requirements shifted multiple times during development—having clear user goals helped us adapt designs quickly.
DESIGN PROCESS
Homepage
The homepage structure would inform the rest of the site's patterns. Our core goal: help users easily track and manage multiple concurrent requests.
Design Decision: Pagination Over Infinite Scroll
This might seem like a small implementation detail, but it had significant implications for our users' mental model.
In consumer products, infinite scroll feels natural—users browse casually and want seamless discovery. But our users had a different workflow. They were managing dozens of requests for different internal teams, often returning to specific requests multiple times as they progressed through approval stages.
Infinite scroll would have made it difficult to return to a specific request—users would lose their place and have to scroll endlessly.
Trade-off: Added an extra click to navigate between pages. But this solved the more critical problems of findability and performance.
Other Critical Homepage Features
Dynamic request limit indicator — Shows remaining requests, disables "Create Request" when limit reached
Request list prominence — Status at a glance, quick actions from list view
Search, filter, sort tools — Essential for high-volume management
Status chips with hover details — Quick visual scanning with additional context
DESIGN PROCESS
Package Selection
This was the most critical flow—where users browse packages, understand offerings, and add them to requests for approval. It was also where we experienced the most dramatic business pivots.
Original Requirement
Sports packages would follow complex sales rules where one selection affected available options (like configuring a car). We designed a progressive "Build Your Own" flow with detailed progress tracking.
Business Pivot 1
Most sales rules removed. Shifted toward pre-made packages with fixed configurations. We redesigned for simpler browsing and selection.
Design Challenge: Editor Mode
Standard e-commerce cart patterns didn't work. Our users created multiple concurrent requests for different internal teams. Solution: "Editor mode" triggered by "Create Request"—users curate packages for one specific request, keeping work isolated rather than mixing everything in a shared cart.
Business Pivot 2
Reintroduced "Build Your Own" alongside pre-made packages. Added "Package Type" selection at the beginning: both paths fed into the same request review process.
Technical Trade-off: Quantity Editing
Originally, we designed quantity editing on the "Review Request" page for last-minute changes. But this created complex validation challenges with pricing, availability, and interdependencies. To meet launch deadline without compromising core functionality, we removed quantity editing from review—users now return to package selection to make changes. Trade-off: Reduced flexibility, but simplified validation and ensured data consistency.
DESIGN PROCESS
Design System
We created the design system from brand guidelines provided by the Olympic Games global brand team, then built components that could scale for Milan 2026 and future Olympic Games.
What we built:
Typography system — Hierarchical scale, responsive sizing, accessibility compliance
Color palette — Primary, secondary, semantic colors for status
Component library — Buttons, forms, status chips, dialogs, tables, navigation
Impact
Results
14.7% conversion rate — Achieved from launch, representing successful package requests. B2B platforms with complex flows typically see 5-10%.
Design foundation for ecosystem — Patterns adopted across Guest Management, Seat Assignment, Accommodation Assignment, Onsite Services.
Scalable system architecture — Handled 2 major business pivots during development, extends to LA 2028.
Reflection
What I Learned
Enterprise platforms need to flex, not break
Enterprise platforms—especially B2B tools serving complex procurement workflows—need to absorb constant change.
I learned to design for "unknown unknowns": building component systems flexible enough to handle requirements we didn't have yet, while staying simple enough for non-technical users.
Advocacy is part of the design job
My most valuable contributions to HRP weren't just the interfaces I designed—they were the constraints I pushed back on and the trade-offs I helped the team navigate thoughtfully.
When business stakeholders focused purely on technical feasibility ("Can we build this in time?"), I consistently asked "But will users understand this?"
Not all design work ships as originally intended
We spent significant time designing login flows that never launched because the business consolidated authentication mid-project. That work wasn't wasted—it informed the centralized system. But it taught me to hold designs loosely.
In enterprise environments with shifting priorities, beautiful work sometimes gets cut, delayed, or reimagined. That's not failure—it's reality. The skill is staying adaptable and finding ways to influence outcomes even when your original designs don't ship.
Takeaway: Design for impact, not just for craft. If your patterns influence other teams' work or shape how the business thinks about problems, that's success—even if your specific screens never launch.