A New Flight Search Panel for Copa Airlines
Designing with clear goals in mind allows for a focused, intuitive experience.
RoleDesign lead, UX Researcher, UI designer
We needed to renovate the booking panel experience on the Copa Airlines mobile app. The booking functionality at launch was entirely implemented as a “webview” inside the app, offering a slow and inconsistent experience for users. Copa was soon to launch an entirely new online booking platform, and so my job was to redesign the search panel experience and bring that crucial step of the shopping process into the app as a fully native experience.
Goals for a New Search Experience
Based on our understanding of how users were using the search panel on the web and on the app, we laid out three main goals our new search for the app needed to achieve:
Optimize for the most common searches
From our usage data, we understood that Round Trip searches are by a large margin the most common type of flight searches users make. After that, we have One-way searches and Multi-city searches. This insight gave us clear direction into what should be the default search mode. Other interesting pieces of data on this front were “number of passengers selected” (for a majority of searches, 1 adult) and "origin city" (usually where the user was currently located)
Speed up the search process without getting in the way
Building up on the idea of optimizing for common searches, we wanted to explore what small tweaks we could make to the sequence of data input in the search form in order to make the process of filling out the data speedier. We wanted to bake in assumptions that made sense to most users, while making it easy to change course if the user wanted so.
Support users during the planning phase of their trip
Booking a flight is never a straight-forward process. Looking at recordings from real users on our website we found evidence that users often make a similar search over and over again, tweaking parameters such as dates or even origin/destination cities. We understood that this exploration process is very important for users, and so our search panel needed to accommodate it.
A Flight search panel is hardly a new or cutting edge artifact in an airline’s digital ecosystem. It is a problem that has been “solved” many times over, and which has received incremental improvements throughout the years. We found it important then, to understand what other airlines and related competitors were doing in this space so that their search experiences, along with our own existing booking panel could give us a starting point from which to explore new ideas.
From a layout and aesthetic point-of-view, we initially drew inspiration from the “Flight Cards” that were already part of the UI in our app and in our Web Check-in platform. At first, this made sense to us since it had this built-in analogy of “putting together” a flight plan that users would later revisit in the app once they had completed their purchase. As we moved forward with the design, this idea fell out of favor.
This first iteration allowed us to explore different design decisions that aligned with the goals we had initially defined.
From Point A to Point B: Selecting Origin and Destination
After playing with some first drafts of the booking panel and sharing it with coworkers, we felt dissatisfied with the Origin and Destination selection process. It required too many jumps between screens for selecting the cities and it didn’t give the user a strong sense of progress in their selection. It also put heavy emphasis on the IATA airport codes, which we feared many users are not familiar with. Even more critically, in hallway testing we found that many of our coworkers had a hard time figuring out where to tap to begin selecting the cities. We went back to the drawing board.
To solve the affordance issue we had, we began exploring more traditional looking inputs for our Origin and Destination fields. This in turn opened up other possibilities for how the input process itself could work. We began exploring the idea of using the “main view” panel itself as the OD (origin-destination) selection view, by creating an “OD selection” state of the panel where users could input the cities directly. The advantage in doing this was to avoid the constant switching between the “main” view and the “OD selection” view, which we found caused unnecessary cognitive load by requiring users to reevaluate each screen every time they wanted to select a city.
To make it easy for users to perform a similar search multiple times, we bring up recently selected cities just below the field so that users can select them quickly. Additionally, since we know users often want to search for flights from the city they’re currently at, we also surface the nearest airport option based on their geolocation.
When translating this idea into a higher-fidelity prototype, we put special attention to animation, in order to maximize the effectiveness of the mechanic.
Search modes: Cleverness vs. Convention
Earlier I mentioned how we tried to embed the search mode (Round Trip or One-Way) right into the dates selection. This made sense to us since we thought it mapped more neatly into a user’s thinking when looking for flights, and it did away with language we weren’t sure most users clearly understood and pushed them into a rigid path early on in the process. This way of determining the type of search broke heavily with convention among existing airline apps and websites. Most of them have their search panel segregated primarily by type of search, and so the first thing users must choose when looking for flights is what kind of flight search they want to perform. For this reason, it was very important for us to test our mechanism in the wild so that we could validate our assumptions.
In our tests, we found two points of trouble for users:
- When users were selecting round trip dates, they were often thrown off by seeing the date selection screen offering them to continue with a “one-way” once they selected the outbound date. This effect seemed to go against our goal of optimizing for the most common searches. While most eventually figured out that selecting the return date would allow them to continue with their desired flight search, a few users even left the date selection screen to check if they had missed an option earlier in the flow.
- That last observed behavior connects with the other major issue we found: Perhaps because of how most airlines’ search panels work, the first thing many testers looked for when starting a search was the “RT” / ”OW” / ”MC” option and were confused or frustrated to not find it.
These behaviors countered our assumptions that users did not understand or care about actively making that decision, and was the reason we ultimately decided to move away from this mechanic. We decided to restructure the main view in a more traditional way, by placing the search modes above the search panel. Users would now have to first select their desired search mode before continuing. This also had the added benefit of helping us solve a discoverability issue we found with the “multi-city search” link.
The multi-city search mode allows users to build a special itinerary that can involve multiple stops in different cities. The user can select up to 5 different stops or “ODs” in their search. For this mode, we built upon the “card” analogy for our search panel and made each possible stop into a separate card that users could select an origin and destination for.
Some key takeaways from this design process:
- Defining design goals early on is incredibly important, as it helps inform your design decisions later on and helps you spot areas where your design isn’t achieving its intended purpose.
- Conventional design often trumps clever design. It’s important to always test ideas with users and understand how they behave around new concepts or mechanics.
- As designers, we need to avoid “marrying” an idea, no matter how much sense it makes or how neat it seems. A willingness to iterate through a problem will always yield better results than strokes of genius.
The new Copa Airlines booking panel is due to be released in December 2020.