Booking.com is well-known for its hotel search. As the company decided to branch out and build products to fill the rest of people's time while traveling, I began leading the team that developed flight search.
We sought to understand how people researched and purchased a flight, to then tailor our search experience to what they expected.
We conducted several rounds of user testing, including street testing, internal and external surveys, testing with customer service executives, and finally, testing a prototype and live site with users.
In initial surveys, we asked a slew of questions based on the last flight they booked: which research tools (if any) they used, how they began their search, if their dates were flexible (and if they stuck to their original dates), etc.
We had a few key discoveries from our research. These themes surfaced no matter who we asked about their search process:
One thing that surprised me personally was that many travelers had little familiarity with airport codes. These are everywhere in flight searches, especially on mobile web and apps.
I made sure any attempt to shorten the airport name was accompanied with the expanded airport name in some way.
Based on initial responses to our surveys, we built a prototype and began putting it in front of users. Initially, we allowed users to select flights one at a time, instead of overloading them with the round trip information right away.
The priority order of the search result filters was based on what people said their deciding factors were. Often, they would check the "Non-Stop" filter immediately after searching, and then order by price.
Once they'd selected both their outgoing and return flights, we showed a summary of their entire itinerary, with a link to book the flight.
We ran tests with customers using this prototype, to see if they understood the process of building their flight itinerary one flight at a time.
While many of the younger participants picked up on the pattern quickly, and liked that you could see which parts of the trip were more expensive, most users overall found it too "jumpy" — if you wanted to change your flight, you had to go back to previous screens and redo your trip build.
From our initial research, we had discovered that many people used Skyscanner to research prices and available flights. It's possible that since they were used to that interface, they wanted to see the price of the whole trip in one go.
So, I built a new design for selecting a round trip, all at once.
Another detail I had to design for in this new format was the possibility that an airline could have multiple flight times available for a particular route.
For example, KLM has quite a few flights from Amsterdam to London daily — instead of showing a ton of results with every possible combination, a selector to switch between available flight times would allow more itinerary customization without breaking the familiar pattern of the roundtrip search result.
Since we'd be linking to our partners' websites for the users to complete their transactions, we had to make it clear where they'd be heading when they clicked book.
While you can't see this solution implemented on Booking.com anymore, I learned a ton while working on and building this project.
Despite any or all efforts, a personal preference for how something should work may creep in to a design. In this project, my personal love of airport codes and building my own trip was not the way that most people preferred to find their flights.
Eventually, through research, testing, and iteration, I was able to filter out my bias and put the product into context, and truly build something people want.