Flight Status - How we redesigned one of BA's most crucial tools with a 25% increase in customer satisfaction

Me - (Product Designer)

TLDR

Re-designed BA's flight status tool - with over 1.5 million visits per year
Achieved a 25% increase in customer satisfaction score post re-design
Fully WCAG 2.2 accessible using 100% BA design system components.

A screen recording of the live site from ba.com/flightstatus

A bit of background

British Airways' Flight Status tool is one of BA's most important tools for communicating real time flight information to customers. It's used by millions of people every year. My product team and I were tasked with redesigning and rebuilding the tool.

The tool was built on an old tech stack and was becoming difficult to maintain. We were also phashing in our new design system components (BAgel 2.0) across our digital products - this would be one of the first tools to properly utilise them.

The origin of the existing tool was pretty much unknown. There were some heatmaps and basic usage metrics, but no designs. We really needed to understand the tool and the customer's needs before we could start designing and building.

The original flight status UI

Early Analytics

We had a few data points and heatmaps of where people were interacting on the old too. These gave us some insight into not what to change and also what to keep. We really didn't want to re-invent the wheel with this redesign as we knew it already did the job and did the job well.

Some initial questions

We knew roughly that the basic functionality would remain the same. It was the same APIs, service and architecture. One of the first questions we had however was: Why are people coming to this tool? What information are they looking for? and of what importance does each level of information have?

We had a rough idea, but I started off with a card sort to try and nail this down. I took all the information that the current tool provided and asked candidates to sort them into categories: "Relevant", "Not Relevant" and "Not Sure". We would then use this to benchmark what pieces of information to prioritise in the UI. Our old flight status UI

Competitor analysis

I ran a workshop with our design team to gather some competitor analysis to see how other airlines handled flight status information. Noting and voting on what we liked and didn't like from various other airlines and digital products.

The landing page and search

The search parameters for this tool largely remained the same due to the requests to the API. The main effort on this screen was translating the requirements to our design system components. Initially we wanted a tabular structure here similar to the initial design to break up the search modes.
Tabs pose accessibility and translation issues especially when used on mobile. We opted for using radio buttons with added screen reader context for updating the state. We also needed to fix some understandability issues with searching for display times. Other updates including left aligning text, and updating taxonomies to be more contextual. Eg. "Show departing times" instead of just "departing".

A before and after of the search screen

The results screen and details

The main structure of the results page again, largely stayed the same. But the flight details section needed a rethink. This is where we really used our card sort to determine what information is of what importance. Naturally, timing and delayed state was the most important, followed by lesser important information like local time, airport code and terminal.

Desktop version of the flight card UI and flight details section.

We also had to accomodate for 12 different flight status states served from the API - all with different UI.

Outcomes and successes

With the release of the revamped application - within a few short months we started seeing vastly improved metrics from our CSAT and intercept surveys. The main purpose of this tool is to provide relevant and contextual information to customers about their flight. Naturally, one of the metrics we measured was success of finding of information.

Customer satisfation metric improvements

Intercept survey improvements

Bumps in the road

With any new release, there are always bumps in the road. One edgecase that popped up was when a flight was delayed until the next day, but with another with the same flight number being still on time. Usually a flight has the same flight number everyday, but when delayed flights were being pushed into the next day, the UI would then show two flights with the same flight number on the same day - confusing customers as to what flight they were looking at.

Example of a flight with the same flight number showing up in the results of the next day