As the Senior UX designer, I led the project from its inception, reporting directly to the Head of Product. I was responsible for the output of a UX designer and managing the relationships with the external research agency, the internal UI team, the engineering team, and the company's stakeholders.

Thomas Cook’s goal was to build an app to enable its strategy of maintaining a relationship with customers throughout the holiday journey.

With the business aim of more effectively serving and selling to their customers post-booking, we decided the key metrics for the product were to improve:

• The sales of ancillary products
• Customer service and satisfaction levels
• The operational efficiency of the business

There was limited knowledge of the post-booking space, as the company had previously focused much of its research on the flight purchasing experience.

With Fluent Interaction, I planned and ran four focus groups with our user groups. The objectives were to gain a rich understanding of the key phases in the journey, the external factors influencing people when they carry out specific tasks and the challenges they face. The focus groups allowed us to uncover perceptions and opinions quickly and organise findings.

Alongside this, I reviewed our website feedback tool (Usabilla) and analytics. The feedback provided insight into pain points in key areas critical to customers: flight details, check-in, seats, baggage, and advanced passenger information (API). The website analytics provided data on the most essential ancillaries and when customers purchase them.

We also undertook a competitor review of airline industry apps and some non-airline travel-based apps, examining areas of innovation, feature use, common patterns/conventions, and opportunities to differentiate.

I produced experience maps for our three core groups: family, young, and older travellers (see Fig. 1). They showed the journeys were relatively linear, where the pain points and challenges were occurring and the variations across the user types. I layered the maps with context, core needs and possible exploration opportunities.

Using the experience maps and the data from the feedback and analytics, we were able to plot the most common periods when people were completing tasks or viewing the information related to their bookings (see Fig. 1). This evolved as we continued and became key to the conceptual foundation of the design.

We also examined the content needed for the app and mapped it out into an information model (see Fig. 1). This allowed us to discuss with the engineering team how best to access this content.

We ran several workshops to tease out key themes, generate valuable insights aligned with our objectives, and unlock opportunities.

To convey the findings and insights in a more digestible way, we framed them with ‘how might we’ questions. This made them more useful when sharing with stakeholders to uncover other perspectives and generate ideas in the preceding stages. Examples of our insights:

Choice paralysis

Customers fear they may make the wrong choice because bookings are complex.
How might we impulsively offer add-on services without additional choice?

Financial satisfaction

Customers will pay for convenience but think some things could be better value.
How might we maximise value and convenience with the add-on services?

Information overload

Customers experience information overload at most points in their journey.
How might we provide accurate, up-to-date information in a timely way?

We knew that communicating the time-sensitive information and tasks that passengers need to know and complete would be a vital component of the final solution.

Discovery showed us that a passenger's journey is reasonably linear, from booking to preparing for and then undertaking the trip. We used this knowledge and data from the research as a starting point to map a framework of customers' needs across a timeline from booking to take off.

This developed into an elegant system for delivering information when passengers most needed it (see Fig. 2).

The interface focused on ‘action cards’; each card gave the passenger valuable information and, if necessary, a call to action.

The cards are delivered in line with the framework and synchronously according to the journey and travel requirements. The most critical or mandatory cards are displayed first using a prioritisation system, ensuring the most salient card is always in focus - passengers can always answer the question “What do I need to do next?”.

The action card takes up the central portion of the home screen, with the booking details always available at the bottom of the screen in a ‘bottom sheet pattern’ that can be swiped up (see Fig. 2).

To reduce the amount of information and clutter in the app, we used a hub-and-spoke navigation model, with the booking details on the bottom sheet being the hub rather than the flight, as per most airline apps.

We created a much simpler itinerary layout on the booking details sheet. We could then show single ancillaries across a booking (multiple flights) with one tap rather than navigating to a flight and viewing all ancillaries for that flight. Passengers can open these ancillary ‘overlays’ and make changes before checking out in a single transaction.

Secondary activities such as switching bookings, booking flights, contact details and settings were placed behind the burger menu. This helped to declutter and increased the focus on the booking details and add-ons.

The action card design tested well. Participants understood that action cards were time-sensitive and were reassured they would receive the correct information at the right time.

Booking details were found and opened successfully, but most participants were troubled because they couldn’t see all the booking details “in one place”. After using the initially unfamiliar design pattern of the overlays to quickly jump in and out of the ancillaries on the booking, they saw the advantage of not being overwhelmed with information and data.

The ancillary overlays worked well for direct flight itineraries, about 81% of TCA bookings. They didn’t test as well for bookings with connecting flights, which, if served by a different airline, are subject to different business rules - participants often missed the distinction between flights.

The first idea was to group the content around the passenger’s journey, with the bottom navigation divided into pre-flight, airport, and in-flight (see Fig. 3). I quickly realised that it made no sense for the passenger to switch between these modes manually - it should be intelligent enough to do this automatically.

The second major iteration was a flight-centric design, with the key content and data split between the home and bookings tabs, accessed from a bottom navigation bar. The home screen displayed a horizontal carousel of the passenger's itinerary divided into flight cards; the bookings tab was a vertical view of the flights with a further flight detail view. Testing showed users were frustrated by the long flight details view and adding ancillaries to each flight.

Many attempts were made to summarise the booking information concisely for the booking details and flight details view, including seat numbers, baggage allowances and meals. They all tested badly due to the complexity behind outbound/inbound legs, fare inclusive/extra allowances and connecting flights.

We repeatedly observed a lack of trust in airline apps, mostly around gate announcements and boarding cards. Passengers would always check departure boards as they didn’t trust the gate information supplied in apps, and they would always print or screenshot boarding cards as they didn’t trust the app to display them when required.