Learnings from building a flight search product from the ground up — a UX case study
Agoda is a major player in Asia for hotels (think of us like the B.com of the east), and to stay competitive we entered the business of selling flights in 2018.
I was 1 of the 2 (now 3!) designers who worked on this, along with a team of 40+ developers and 3 PMs. This is still an ongoing project, and we’ve only just shipped the MVP in July so there’s lots of work to do. The scope of this project was end to end — for apps, web, and mobile web. For most part of this project I focused on the desktop experience.
Business goal
An interesting thing about this project was that the goal was also a challenge/problem — the goal was to enable the first booking in 7 months.
The objective was not only to build a product from the ground up within a short time, but also to set a strong foundation for our current and future web offerings. We needed to gather research and work the findings into our solutions, build a product that meets customer needs, create a design system that scales and works holistically with our existing hotel one, and do it all within a tight launch deadline.
Understanding the user
The foundation of any product is built on data. One of the advantages we had was our existing hotel data. But to supplement that, we carried out a few more research efforts focused on understanding user behaviours within the flights space — an internal lab, a survey, a user lab.
From the data we collected, we uncovered a few key points:
- Timing is everything — We saw evidence of this during the competitor user lab when the time-related filters were used most and used first, upon landing on search. Whether they are a single young professional or a busy mother booking for her entire family, timing is an important consideration.
- Browsing behaviour was influenced by trip type (long vs short haul) — long: more rigorous process, different priorities (comfort, airplane type, entertainment) and for short: maximise time, price is king, things like leg room/wifi become less relevant.
- Predicting what to optimise for — being in the hotel business for over 10 years, we have a lot of data on the patterns around hotel bookings. This was one of the datasets we found relevant:
Based on that we drew the assumption that most of our flight bookings will be short haul. So now that we know what to optimise for, what are some ways the design can respond to that?
Understanding the problem space
To understand a problem well means also understanding the ecosystem in which the problem exists. So the next thing we did was to analyze our competitors, to find out things like — How are our competitors approaching it, what’s being done well? Are there emerging trends or patterns? What is being done poorly, which might mean an opportunity for us to introduce a better approach? Our goal was to find out ways we can “meet and beat” the competition.
MVP design goals
With a better understanding of our users and the current flights space, we decided the design should address these key elements:
- We know that time is an important factor. Flight results have a lot of information, do we structure it well enough so a user can quickly find what they want? Does our design include features that let users scan information effectively and efficiently, based on what we know to be their most important factors when booking a flight?
- Is the look and feel consistent with the hotel side? This is important to ensure a cohesive, trustworthy product. During the booking process, users might jump between devices. Are we ensuring that the experience between platforms is cohesive enough to flow seamlessly?
- In terms of features offered, are we doing a good job “meeting & beating” the market where applicable?
Shipped product (desktop)
For the purpose of this article, I’ll only be sharing the desktop experience.
One of our first foundational explorations was on the flight results card. We tried a bunch of concepts that were careful in the way we brought focus to the important things — bright red for price (as was proven successful from many hotel a/b tests), and reserving the boldest and biggest font weight for timings. Eventually we landed on this design after doing a little dog-fooding and it showed itself to have the best readability. Initially when we first launched, the ‘SELECT’ button was nested within the flight details — we had the hypothesis that if we forced our users to review the details before giving them the ability to book, there would be less human errors in bookings. But the data we got back quickly disproved that — we saw that some users were going from search to checkout too fast to mean they were actually reviewing the details properly. We dug deeper and saw that these were repeats, so we deduced they were the ones who had already gone thru the process a few times and knew what they wanted, and that us forcing them into this extra step was actually a point of friction. We removed that functionality, and moved the ‘SELECT’ button one level higher in our next iteration.
With every result there is a lot of info to take in so it’s important to be strategic about how and when we display things. The great thing about desktop is that you can nest secondary pieces of info under mouseovers, and that’s exactly what we did. We gave users all the info that needed to be on the results card and got them to establish a hierarchy for us. Based on this, we decided to nest things like layover airports, arrival dates, and airlines (when there’s a few) to only appear on hover.
Doing the info hierarchy user lab also informed the way we structured the expanded flight details in terms of what should live together and what can live apart — for example the depart and return and baggage info is separated into tabs.
Again on the search results page, we maintain that timing + price are the top considerations. By including a variety of sort and filter options — filters with elaborate toggles for departure and landing times, and very detailed sort capabilities like total journey time or outbound arrival time… We want to give users the ability to skim results as much as they want, so we do our best to reduce the fatigue that happens when you go thru hundreds of results.
We’ve learned a lot about structuring an effective check-out process from selling hotels, and we’ve applied these to the architecture of the booking form. For example maintaining the ability to constantly check your trip summary and payment details, to give a sense of reassurance and confidence in booking.
What success looks like
Once we launch a product, a lot of data and metrics come in. But what are some ways we have defined success, so we know how to filter the noise out to focus on the numbers that matter?
- Repeat bookers — people will try a lot of things once, maybe because they were curious and don’t know what it is, or maybe because of a promotion. But if people come back to book again, this tells us the product and experience was valuable, and that they’re likely to incorporate it and make it part of their lives.
- Less calls to customer service — most if not all of the calls have to do with our customers not finding what they need, or not being given enough information in the funnel such that they have to seek it out themselves. Our goal is to provide an experience that is so complete, our users navigate from start to end without feeling the need to reach out to customer service.
- More hotel-flight overlap in bookings — customers who booked a hotel also has a corresponding flight booking on our platform, bringing us one step closer to being a one-stop shop.
- We see evidence that users are able to easily navigate the product from start to finish, within and between platforms.
Learnings
I’ve learned so much in the last 8 months, but here are two of my favourites:
Ownership
After working on hotel side for almost 2 years, I had a pretty big process culture shock coming onto Flights. Previously the majority of my time was with the product owner, sprinkles of contact with the engineers, and little to no engagement with any other designer. A comparison pie chart of my time looked like this:
For the first time, I had learn to work closely with another designer, fight for the attention of a PM that was spread thin from having to oversee 4 scrum teams, and engage with almost 40 developers across 4 platforms.
When you get so much less PM exposure than what you’re used to and you can’t run things by him every single time, how does that change and impact your workflow? What goes into these new gaps of time, and how do you take ownership of planning and executing the things that were previously lined out for you?
Through this startup-like environment and the autonomy that came with it, I learned that anyone can take lead, and take ownership of a problem. It’s important to realize that the rest of the team is looking to you to propose solutions for any UX related issues, they see you as the go-to person when theres a dead end in the flow, or a glitch in the design… All of which is pressurizing, but also an opportunity to shine. An opportunity to gain their trust, and show them that you are reliable and have ownership.
Collaborating at scale
Between engineers: When you with with 40+ developers, things are in constant motion. It might not even be the same developer who you worked with to solve the problem who ends up implementing it. Rigour in documentation becomes so critical in order to reduce confusion, and align everyone to a single source of truth. We learned this the hard way — through experienced setbacks that were caused by lack of communication on our part, resulting in diverging designs that went on to get developed and then exist as inconsistencies, that we then had to go back and reinvestigate and fix — costing us more time than should have.
We’ve also learned the value of maintaining and fostering relationships between design & engineering. Most of the design team is centralised on a floor, but we piloted an effort to start sitting by them in order to be accessible. I cannot stress the importance of this — the breaking down of physical barriers has led to more a pixel-perfect product, better camaraderie, and increased understanding of their systems. We have found that to be effective in breaking down the walls that having different roles come with.
Between designers: As we continue to scale our team, it is even more crucial to ensure transparency and accountability amongst ourselves. Communication is key. Little things like moving stand-ups to Slack if someone is OOO has helped ensure that person can get caught up to speed quicker when they return. Regular pulse checks to discuss what is and isn’t working so we can adapt and iterate our own processes.
Looking forward
We’ve learned and achieved so much in the last 8 months of hard work and intense deadlines, and I’m very proud of our accomplishments and thankful to be part of a truly blue moon project in a place like Agoda. We’ve only just scraped the surface of what we want to get the flights product to become. As we roll out across the markets, it’s been emotional to watch our product gain traction and we celebrate the little milestones every day.
As always, design is a journey and I truly believe that a product is never complete — there is always something more to be done. As we continue to make the flights experience a pleasure to use, any sort of feedback or suggestion is essential in helping us get to the best that we can be.
Check out the site (and maybe book a flight) at www.agoda.com/flights.
