Expedia - Flight Itinerary Unification

Problem Statement:
Expedia’s flight itinerary redesign efforts exist in varying stages of development. How do we ensure that the experience is unified between app/web and across all breakpoints and LOB’s? This created an interesting problem that allowed for collaboration with the app itinerary design & development teams, and ultimately ensured we were aligned in our design directons.

Project Overview:
Itinerary on app is live, while web is still being designed and developed. Northstar conceptual web designs had previously been completed, accounting for one ideal scenario. My iterative work began with designing for each scenario that did not show in the Northstar concept. Not only was it necessary to adhere to current content frameworks, I also designed within a design system, called Unified Design System (UDS).

System Overview:
There are 5 key pages within Expedias Itinerary: base page, manage booking, traveler information, pricing and rewards, and travel protection. Interactions vary significantly by breakpoint.

My Role:
UX Designer

Team:
UI Designer
Senior UX Designer
Content Strategist
Technical Program Manager
Development Team

Problem:
Currently, we do not explicitly show the time length of each individual leg of a flight. This is especially frustrating for users traveling to different timezones, with multiple legs. This is demonstrated in example (1).

Scenarios:
Because of the just about infinite number of legs, layovers, and suppliers I could account for, I chose to design for a two leg flight, with a layover. Altogether, I will show each individual leg length, as well as the layover length, and total duration of travel. This would allow me to solve this problem holistically, and ensure my solution was scalable.

Design Solution:
One important thing to note is that I focused primarily on mobile for my initial explorations. I wanted the itinerary to tell the story of your trip, from top to bottom. It was necessary to ensure that flight duration and layover times were never mistaken for one another. Many initial explorations leaned in this direction (2, 3). I then explored making this messaging more explicit (4, 5), but was agreed to read more like a CTA. I combined the best from both previous explorations and toned down the color (6). Further explorations were attempting to include the duration inside the module, and using icons to help indicate flight duration(7, 8, 9). This was also widely agreed to feel busy, and difficult to scan. The addition of icons further adds to this issue.

Taking a step back it was necessary to include the duration near or associated with the relative module in which it was referring. It would too easily be understood to indicate a total travel time. Including the duration inside the module was also unsuccessful.

Option 6 was decided to be the best option as it is scalable, clearly indicates which flight it is associated with, layovers are legible and clearly not associated with a flight. I was able to ensure a linear story of the trip is told, reducing the possibility of users’ misreading itinerary. In the instance where we show many flights (3+) in an itinerary, the linear story will continue. All functionality remains, as users are still able to easily access their personal traveler details, pricing breakdowns, travel protection, and manage the booking.

Problem:
Baggage info policies were originally displayed as a button that presents an overlay on mobile, and directs users to a dedicated page on tablet and desktop. It had been communicated by users that the baggage information page was unnecessarily displayed separately from all other itinerary, causing difficulty tracking airlines’ varying policies. How would I display all relative baggage information by default on tablet and desktop?

Scenarios:
Baggage information returns, No information returns

Design Solution:
Airlines carry-on and checked baggage policies vary significantly. It was important to include detailed breakdowns of checked baggage fees when possible, and include the prompt for users to confirm with airline, as these fees (collected by the airline) frequently change. It is always important for users to have access to the airline directly, especially in these instances when communicating monetary fees. Because of this, I included links directly to the airline in both states. In the state with returned fees, the cost associated with additional checked baggage is displayed, with the instruction of “how to pay” and a link to the airline you have booked. In the non returned state, I communicate that no baggage information is available, and provide the airline link for support.

It was important to consider secondary currencies and languages in this instance. Because of this, I ensured there would be enough room for text to wrap, and intentionally demonstrated what this would look like on mobile.

I approached this project as I did the following - Mobile first. This helped parse dense content, and ensure hierarchy was intentional.

Problem: Currently, in the Traveler information module, the ticket number only shows when a ticket is confirmed. The defined problem is - what do we show in the traveler information module when a ticket is in progress? These multiple scenarios would actively change what was displayed on screen.

Scenarios: Ticket Number displays, ticketing is in progress

Design Solution: I approached this problem holistically to consider if we should indicate status of ticketing. Instead of heavily altering the existing UI, I chose to indicate that the ticketing was still in progress directly where the ticket number would appear, and where users would expect to see it. This allowed for collaboration with our content strategists to ensure messaging was consistent with the existing framework. One important thing to note is that not only was it necessary to adhere to content frameworks, I also designed within a design system, called Unified Design System (UDS).

Traveler name, ticket number, and phone number were now separated from the remaining content by a horizontal rule and spaced consistently from one another. It was important to make the content distinction because name and ticket number always return, whereas the remaining traveler information content is only displayed when a user enters it. Because of this, it was important to keep a consistent framework for all scenarios, allowing users to quickly and easily reference which traveler is associated with each returned piece of traveler information. This becomes more obvious when the module is showing multiple travelers.

Problem: When traveling with more than one passenger, we currently repeat the entire module vertically. This causes users difficulty in comparing traveler details, and creates an unnecessarily long and dense page.

Scenarios: Expedia currently allows a maximum of 6 passengers to be booked on one itinerary.

Design Solution: Referencing Expedias Unified Design System, I explored the use of radio buttons, expandable blades (used on hotel itin frequently), paging buttons, and horizontal tabs. Expandable blades were considered further as well because of the unified styling and experience as hotels, but would not apply here as 6 names of varying length can be entered. Tabs allow users to easily compare itineraries, and will not take up an unnecessary amount of screen space when showing multiple travelers. When horizontal space becomes fully occupied, a more tab shows, and allows users to collapse the opened tab in case it covers important content, while still affording users the ability to navigate from traveler to traveler easily.

Round Trip Flight

The current itinerary is organized per transaction. This functionality is expected to remain the same moving forward. So, for example, if you book a round trip flight, both flights show up on the same “My Trips” page. This causes two issues. One being the content on the page. If two flights are booked to the same destination (common occurrence), users are unable to differentiate flights on the my trips page. Secondly, the possibility of users misreading their itinerary, or calling support for help because of this misunderstanding is increased. I approached this project as I mentioned in the previous project - taking a step back and evaluating the system as a whole, understanding the current behavior to more easily identify potential areas of improvement. The pictured user flow illustrates the entry point to the itinerary page.