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.
Flight Search panels for Delta, United and Aeromexico.
First Explorations
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.
We started out with a bare-bones panel that showed only the search parameters chosen by the user. All controls were hidden away in their own dedicated screen, in order to maximize the space available to interact with them. This was an idea that persisted, albeit with some changes.
We wanted to test an “unconventional” approach of putting together a search: Instead of asking users to select a “round trip” or a “one-way” search upfront, we would allow them to choose that when selecting dates. The idea was to “dissolve” away the Round Trip/One-Way choice into a selection process that felt more natural and straightforward. This was an idea that we felt excited for, but that would meet a less-than-stellar fate in testing.
From the start it was evident to us that multicity search was a different kind of beast, meant mostly for power users with very specific travel plans in mind. It made sense to have it on a totally separate screen, accessible within the main search screen.
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.
Sketches for a new OD selection mechanic.
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.
In the 2nd version of our search panel, we use the panel itself as the place where users type and search for cities, by morphing the main view into a dedicated search view. We also decided to chain the Origin and Destination selection so as to speed up the search process. For this interaction we lean on animation for communicating what’s happening on the screen more clearly.
At any point during the search, the user can scroll the results list and this will dismiss the keyboard in order to maximize the space available for scanning the list. The user can bring up the keyboard again by tapping on the text field.
Users may also tap on “View all airports” to see a full list of cities we fly to. We do this to support a more exploratory mode of search.
For dismissing the search view, we tried several approaches, but we finally settled on placing a “handlebar” at the top of the card to allow users to drag down. Users can also tap on the dead space above the card to dismiss it. We felt these two interaction patterns were common enough for users to understand.
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.
This interaction heatmap shows users selecting "Round Trip" dates. Several users felt confused about what to do. Some attempted to go back while others tapped on "Continue" without fully understanding what they were doing.
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.
Multi-city Search
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.
Multi-city Search Mode.
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.