How Heathrow Launched an Easter Mobile App

This post is part 2 in a new series by the Heathrow Airport Innovation Team. In the previous post, Richard introduced the Heathrow innovation process; how we gather business challenges, score and prioritise them for trial projects. Today, we share a successful initiative that combines several smaller business challenges with innovative technology to produce a fully fledged passenger-facing, custom-made mobile app. The Easter Treasure Trail app enables families to play an interactive game using iBeacons. It uses location-based and context-aware services that were tested and launched in Heathrow Terminal 2.

Combining Challenge with Research

After discussions with business units across Heathrow, we collected several small challenges that individually scored low in our challenge scoring method. These were:

• Family groups are small but a significant percentage of our passenger numbers overall, and become an important part of the passenger make-up during holiday periods. How do we use technology to help make family time at the airport more enjoyable?

• Terminal 2 is the newest Heathrow terminal and many passengers haven’t flown through it before. How can we provide a subtle way to improve passenger knowledge of the terminal layout?

• How can we encourage passengers to walk past more of the retail outlets, before they sit down to wait for their flight?

• How can we point out great Heathrow landmarks in an interesting way?

• How can we influence the redemption rate of retail offers by making these offers specific to the passengers’ location and context?

Also, we were interested in using Bluetooth beacons to provide location-based services indoors. So we decided to develop a treasure hunt mobile application for our family passengers.

By providing clues to lead passengers around the departure lounge, we’d provide a fun way to address the challenges here mentioned and at the same time learn about deploying and operating beacons in an airport environment.

Build code

Agile App Development and Honing the MVP

As with all app projects, we defined the minimum set of features and functionality that will deliver the experience we are looking for – the Minimum Viable Product (MVP). To do this, we worked with a development partner to define the user personas, critical functionality, user experience (UX) and design language. This was developed in short series of workshops over two weeks, using the agile methodology.

For the app, we created 2 user personas;

Persona 1 A British family consisting of 1 parent (assuming the other parent is with cases, or in a retail environment) with 1 child aged 8 years. The family are moderately well off, and are flying to North America to visit extended family. This persona was considered our primary user.

Persona 2 A female, aged around 30, working in a professional role, and going abroad on business. She has an interest in technology, and uses an iPhone for business and for her personal life.

Before we started the trial, we thought we’d get a considerable amount of interest from passengers fitting persona 2. And that they may be more aware of the game and with more time to spend. But in reality, we found that persona 1 made up the highest proportion of players; but were predominantly non-British nationals.

When we were defining the MVP, there was another key component to be specified and that was the route itself. We had taken the decision to fix this at the point of beacon installation, given the time and complexity involved in deploying the beacons in an airport environment.

So we started trialling the route intensively in the beginning, holding the beacons and checking the received signal strength as we walked the route, as well as checking the feasibility of potential installation locations against the goals of including specific waypoints such as a post box or ‘selfie-moment’ in the route. We didn’t have scope to install a matrix of beacons with which we could use trilateration for user positioning, so we measured the proximity to specific beacons as the trigger for meeting the journey waypoints. Our aim was to install beacons in discreet locations; given the height of the ceilings and positioning of furniture, the top of flight information screens or advertising pillars turned out to be the most useful beacon sites.

T2 interactive map

Launching and Testing MVP

Adopting an agile, iterative development process meant that we were able to deliver the first functioning app within 3 weeks. At this stage, we deliberately avoided any interaction with other teams that might have ‘slowed us down’. For example, we did not consult with Brand or PR – as the MVP product was for internal testing only and not to be shared externally at this stage.

The key driver for developing the MVP was to gain business buy-in to the user experience and its success in overcoming the business challenges we identified at the start. This meant that we could illustrate some of the user experience through suggestion, rather than going through the process of development for all of the features.

For example, the feature of posting a selfie to twitter simply showed a mockup of the results rather than actually posting to twitter. This allowed us to simplify the implementation, to paint the picture of what we were trying to achieve and allowed our stakeholders to visualise the experience.

Then we moved into the app testing phase, inviting a wide range of Heathrow staff to trial it and give feedback. It is at this point that we brought in the Brand and PR teams to provide direction for a successful second iteration.

Second Iteration

Once the proof of concept piece MVP app was complete, and our Innovation Steering Group (ISG) approved a real version, we set to work on completing the second iteration. So we removed faked content and processes, and created a final product which could be deployed over Easter.

At the start of the second iteration, we wanted to ensure that the goal was clearly understood: to polish the app sufficiently so that we could launch it publicly within a limited environment to get ‘real’ user feedback and analytics.

To do this, we restricted development to iOS only and just tested it (and not Android), and for one terminal only, Terminal 2. In addition, the Treasure Trail (as it was eventually named) would end on a specific date. The latter is especially key for us in the Innovation team; we exist to facilitate trials to understand their impact and to describe a business case for a fuller deployment, rather than a half-hearted attempt.  However, we did take the opportunity to write the app in a modular way to allow any future development to build on the work already done.

The second iteration took about 1 month, including development time and testing various versions of iOS and the array of compatible devices, all of which had slightly different Bluetooth performance in the field.

It was an interesting learning experience, and a direct result of us choosing beacon proximity by received signal strength as a trigger, as each device type needed a slightly different configuration to work in the same way. This involved quite a bit of calibration work on our part, walking the route dozens of times (and many 1000s of steps on our wearable fitness trackers!) to finesse the experience.

Implementation

As part of the work to design the second iteration, we sought the advice of our Branding team, who helped us alongside our original UX/UI (user interface) developer to create the colourful yet on-brand version of the application that went live. We had elements of Easter (bunnies) mixed with verdant fields of the British Isles and a traditional ‘Sandcastle’ type castle peeking over a hill. This background was combined with our distinct purple branding to achieve the final result (pictured).

Once ready, this version was showcased to various stakeholders, live in the terminal for the first time – to help get buy in from these teams. Both groups loved the application and worked tirelessly across the Easter period to promote it and help passengers use it.

Timing was critical to this project, with Easter being an immovable date. As with all App Store releases, we were beholden to the Apple approval process. Actually, we found the App Store approval timescales to fit the 2-week turnaround generally experienced by other developers.

Thereafter, we developed advertising for the app via Heathrow’s social media channels, through terminal leafleting and physical signage to let passengers know where the game began and what it involved.

Furthermore, we did a bit of advertising through WiFi welcome screens. The physical signage in the terminal directly corresponded with an increase in the amount of people playing the game, so all this proved really valuable in driving awareness and use of the app.

What Did We Learn?

With the Easter period now over, we are now collecting the data and writing the final report. This experience has given us the opportunity to learn a number of lessons, which we can summarise below:

User Experience For the first iteration, focus on the user experience. Provide the minimum functionality that gives the optimum user experience.

Stakeholders Bring in a wide range of stakeholders and build in their views as soon as possible.

Lead Time Work out the long lead-time items – don't forget to involve Brand, PR and Advertising teams early (if applicable) to understand the timeframes they need too.

Deadline A hard deadline focuses the mind on keeping to a tight scope.

Interest People will turn on Bluetooth if they've got a strong enough reason to do so.

Deployment Beacon deployment is all about the use cases. In this case, the installation was specific to the Treasure Trail, so we chose to work in proximity mode with individual beacons. That might not have been the best solution in a different beacon environment.

Permissions Consider radio interference and get permission before you install.

Adults Adults like to play too – this kind of game isn't just for children.

Value Passengers really liked that we weren't just taking them around the terminal for no reason, but showing them sights and facilities that they might otherwise not know about (viewing Concorde, children's play areas, water fountains, quiet areas and baby change facilities etc.).

Reward People also really appreciated the surprise reward of a Heathrow branded chocolate egg on completion.

In conclusion, the Easter Treasure Trail project was an opportunity to use the agile approach to deliver a mobile app in a very short time. We launched an app experience that passengers enjoyed, in a short timescale, with a limited budget and which addressed real business challenges in Terminal 2.

In ‘doing agile’, we gained valuable experience, increased our knowledge of working with beacons and adapted our app development approach to take all of this learning on board. The upcoming app projects are already realising the benefit from the work we started with the Easter Treasure Trail app. It is an ongoing process to making every journey better for Heathrow passengers.

Robin Gissing, a technology architect at Heathrow co-authored this post. His background is in academia and emerging technology having previously worked as a Technologist and Technology Enhanced Learning Advisor in the Higher Education sector. There Robin co-chaired a number of regional and national user groups and spearheaded first of type innovative learning experiences to students across the UK.

This article was written by Robin Gissing and Colin Mair.

Resources: Easter at HeathrowHeathrow Airport Terminal MapsThe Lean StartupGartner: CIOs need to focus on supporting mobile, context-aware services, analyticsWhat you need to know about using Bluetooth beaconsBeacons, Bluetooth & Mobile: The Future of Context Marketing

Image credit: Vitor Azevedo, MVPdiagram from DeutscheStartups.de; T2 map via Heathrow's website; and Easter app image via Heathrow's innovation team.