TIMELINE
June 2024 - March 2025
FORMAT
Responsive Web
ROLE
Senior Product Designer
TL;DR
Co-led end-to-end redesign of the Olympic Hospitality Request Portal (HRP) for the Milan 2026 Games.
Streamlined core flows - package selection, request tracking, and login - to reduce confusion and increase clarity.
Iterated on editor mode concept and designed progressive flows and a tailored experience for corporate buyers.
Collaborated with PMs, engineers, and the business to pivot designs in response to shifting package rules.
Background
When I joined the project, the Hospitality Request Portal (HRP) was a legacy platform used by sponsors and corporate partners to request hospitality packages for the Olympic Games. It had worked well enough in the past, but the upcoming Milan 2026 Games introduced new types of packages and business rules that the system wasn’t built to support.
The original plan was to do a light visual refresh and fix a few usability issues. But once we started digging into the experience, it became clear that the platform's structure and flows couldn’t handle the level of complexity we were about to introduce. Users were already facing confusion around navigation, unclear system feedback, and inconsistent terminology — and adding new layers on top would only make things harder.
We worked closely with stakeholders to revisit the scope and focus on improving the core experience. That meant rethinking how information was organized, simplifying key flows, and building in flexibility to support changing business needs. This case study walks through how we approached that shift — along with the decisions and trade-offs we made along the way.
Responsibilities & Key Contributions
Product Design
I was brought on along with another product designer to lead a comprehensive UX overall of the pre-existing Hospitality Request Portal. I was responsible for the end-to-end UX/UI.
Design System Contributor
I built UI components, helped established the color palette, and typography.
Collaborator
I collaborated with the product manager, front-end & back-end engineers, the business analyst, QA, user researcher, and another designer to ensure alignment on all aspects of the design with both business and user goals.
Problem Identification
Through conversations with our team’s user researcher, the product manager, and through reviewing the past version of the portal, we identified key problems.
No clear user flow
It was difficult for users to submit and manage their requests due to redundant steps in the flow. There were also multiple entry points, with no clear distinction, that led to the same place.
No visibility into system status
Users have a limited number of package requests they can make. These request limits were not communicated at all in the interface so users had no idea when they reached their limit.
Inconsistent language
Users should not have to wonder about whether different words or actions mean the same thing. For example, there was an “Edit” and “Draft” button placed in close proximity. Both of those actions took the user to the same place.
Layout & interaction Issues
Many UI elements were visually disconnected from their function—for example, floating action buttons were often placed in unrelated areas of the screen and didn’t align with the user's current task. This created friction and uncertainty, especially for non-technical users.
Lack of proper sorting & filtering
Requests that had already been approved were mixed into draft requests, pending requests, and locked requests with no way to prioritize. This made it difficult for users to track and locate the request they were looking for.
Goals
BUSINESS
Make our product offerings easily discoverable
We want to ensure that our business partners can easily find the packages they need.
Align the website visually with new branding guidelines
USER
Easily find the status of their requests
Users want to know whether their request has been fulfilled along with what part of the submission process they are in.
A consistent client experience
Users want consistent terminology and actions used across the site to reduce confusion and uncertainty.
A clear pathway for browsing packages and submitting and managing requests
Users want to complete the request process with ease.
Audience
Our clients consist of corporate stakeholders, sponsors, and more. They are not tech-savvy, but have an in-depth knowledge of the olympics and the package request process.
Process
Discovery Meetings
I went through a series of discovery meetings with the product manager and the other designer to learn more about the project - the goals, current problems, the reason behind the redesign, timelines, and the project scope.
The PM originally wanted to limit the scope to a visual redesign with some minimal UX changes due to a limited timeline. However, the current site was not designed in a way that would support our new package offerings for the Milan Olympics. The confusing user flows along with the implementation of these new complex packages would result in a site that’s not usable. Through further meetings, we settled on a complete overhaul on the site’s UX.
User Flows
We determined what the key tasks would be based on product requirements and the previous version of the site. We then mapped out user flows for these key tasks.
Information Architecture
We used the user flows to help inform the IA for the site and vice versa. We focused on the user goals and what elements needed to be included to achieve those goals.
Turning the Homepage into a Request Hub
We started with the homepage because its structure would inform the design of the rest of the site. The core goal was to help users easily track and manage their requests, since request creation and tracking were the primary actions on the platform.
We tested multiple layouts and ultimately chose one that gave the request list visual prominence. It was placed on the right side of the page to align with common eye-tracking patterns, ensuring users would naturally land on it when scanning the page. We placed the “Create Request” button high on the page for visibility, as it was the most important action and needed to be easily discoverable.
To support the creation process, we introduced a dynamic indicator that showed how many requests a user could still submit—something that was missing in the previous experience. Our user base has a limited number of submissions based on business rules, so this feature provided clarity and helped prevent confusion. We placed it next to the “Create Request” button to keep related elements grouped. Once users hit their limit, the button would disable to prevent additional submissions.
We added search, filter, and sort tools to help users manage a high volume of requests. These users are often juggling multiple requests for different internal teams, so findability and organization were key. We chose pagination over infinite scroll to give users more control, improve performance, and make it easier to return to specific requests.
Each request card included a status chip so users could quickly see where each request stood. Hovering over a chip revealed more details on what each status meant, improving clarity. Clicking a request opened a detailed view that included all selected items, quantities, and pricing, giving users full transparency and reducing the need to contact support.
Throughout the design, we emphasized clarity, hierarchy, and ease of use.
Streamlining the Login Flow for Flexibility & Security
Once we had a solid foundation for the homepage, we shifted our focus to the login flow. While the overall design process wasn’t strictly linear—we frequently revisited earlier work based on business updates, PM requests, and internal discussions—this marked our next major area of exploration.
In the previous experience, password creation lacked clarity. Error messages were vague, and password requirements weren’t clearly communicated. To address this, we introduced a checklist-style system that listed each requirement with examples when needed. As users met each requirement, the corresponding item transitioned into a success state. Only when all requirements were satisfied could the user proceed to the next step.
After password creation, users were brought to the login screen. We improved error handling by highlighting the input field in red and displaying clear, specific messages below it. We also designed a “Forgot Password” flow, ensuring all error messaging remained generic for security reasons.
However, midway through the process, the business decided to consolidate login across all digital products using a centralized authentication system. As a result, the create and forgot password screens were never launched. Our work still informed the broader authentication flow: our designs were handed off as templates to the team overseeing the global login system.
The only screen that remained in our flow was the login entry point. We retained the copy and layout but removed the email and password fields. Clicking the “Log In” button now directed users to the centralized login system, and upon successful authentication, redirected them back to our platform.
Designing a Flexible Package Selection Experience
This was one of the most critical actions on the site—it allowed users to add packages to a request they would then submit for approval.
Early on, the business communicated that sports packages would follow complex sales rules where certain selections would impact what products users would have access to.
We initially designed a progressive “Build Your Own” flow to account for these constraints. Each selection affected the options available in the next step, so we used a detailed progress bar to help users stay oriented throughout the process.
Midway through, the business pivoted—removing most of these sales rules and moving toward pre-made packages. We redesigned the flow to support this shift, replacing the step-by-step process with a more traditional browsing and selection experience.
However, a standard e-commerce cart model didn’t meet the needs of our users. They were responsible for creating multiple concurrent requests—each tailored to different internal teams. This meant we needed a system that allowed for flexibility, draft saving, and clear request-level separation.
To support this, we introduced an “editor mode” triggered by the “Create Request” button. This mode let users curate packages specific to one request. They could save progress as a draft or submit when ready. After making selections, they were taken to a review page to confirm details, check pricing, and finalize their submission.
Later, the business decided to reintroduce a “Build Your Own” experience—alongside the pre-made options. We added a Package Type selection step at the beginning, allowing users to choose between pre-made and custom-built packages.
We had to make difficult trade-offs due to some technical constraints. One of these trade-offs was removing the ability for users to edit the quantity of packages once they reached the Review Request Details page. This page displayed a summary of all added packages, quantities, and total cost. While this limited users' ability to make last-minute changes, it simplified the validation logic and reduced edge-case complexity for developers—allowing us to meet release deadlines without compromising core functionality.
Package Type Selection
Pre-Made Packages
Build Your Own Package
Review Request
Building a Scalable, Brand-Aligned Design System
We created the typography and color scheme based on established branding guidelines. We then created multiple components that would allow the site to scale for future games. The homepage informed the creation of the design system as well.
