- Client
- Virgin Holidays
- Sector
- Travel
- What we did
Early in 2017, Virgin Holidays had a strong case for wanting an app. Various pieces of research suggested clear opportunities to enhance customers’ holiday experience with the offline capabilities of a native app and that actually, customers already expected one. But the cost of engaging an agency to design and build an app from scratch—not to mention maintaining it going forward—gave the team cause for pause.
The Results
Future friendly
New capabilities
The Full Story
How do you strike the right balance between in house resources and agency input?
So you want an app? I guess you’ll need to talk to various agencies to find the one that really gets your business, has a track record of delivering apps of the right quality and that can work to your budget and timescale. Then you’ll need to commit your time and resource to design and launch version 1 with your agency. Then you’ll need to continue that commitment indefinitely to keep on top of bug fixes, device changes and if you’re lucky, new features. Ah. It’s starting to sound expensive.
When exploring the agency option, it’s only natural to ask, “Could we build it here, ourselves?” Virgin Holidays has a capable digital team including a growing design function. On the tech side, the team is well established with agile processes, continuous delivery and team-by-team autonomy in choosing frameworks and setting the code agenda. But… The stack is all front-end web technologies. There are no native iOS or Android developers or QA. The specialist expertise and sheer effort required to design, deliver and maintain an app should rule out the in-house route but for Virgin Holidays’ abundant optimism and can-do ethos. Still, enthusiasm alone never launched an app. The team had to give careful thought to what the app needed to be, if it was even possible to bring all the work in-house and if so, how to go about it.
Making it happen
With a view that a hybrid app would be the most efficient route to market, we began exploring how to build it. We wanted to manage as much of the design, build and QA in house as possible so that those skills could stay in the building for the ongoing fixes and development but knew we’d benefit from some experienced hands. Our tech lead spoke with a few specialist agencies before engaging Buckhill to build a simple hybrid proof-of-concept. The concept proved the hybrid framework could support our needs and we put the plan in place for Buckhill to support us through to launch.
An (almost) blank canvas
In designing the app we had the opportunity to define what it should be. The business case included a lot of ideas for potential features but first we took a step back to ask ‘What do our customers want and need and how can we offer that in ways we don’t already?’. By mapping customer pain points against the booking lifecycle, we could find the best candidates for including in an MVP. In parallel we ran workshops with key business stakeholders to sketch ideas and score suggested capabilities by impact to customer and ease of delivery.
All this informed our first round of testing with users. Through another round of sketching we produced a set of hypothetical app concepts each focused on serving holidaymakers with limited and specific functions. We then interviewed real customers about the propositions to find what features they found the most valuable. By the time we picked up Sketch to start designing the MVP, we could be reasonably confident we were working towards a product that would serve customers and the business needs well.
It’s going to take longer than you think
As well as the Clearleft designers and one hybrid developer, our new Scrum team was made up of regular Virgin Holidays team members, normally responsible for web channels. This meant a steep setup and learning curve. Teething problems came from every direction:
- Jumping through hoops for developer accounts with Apple and Google
- Buying and preparing test devices
- Setting up new build and QA environments
- Starting the build with fresh frameworks and plug-ins
- Learning the frameworks and plug-ins
It’s fair to say, velocity was slow for the first few weeks but these are the necessary foundations of a solid app house and eventually the stumbling blocks were fewer and further between.
After a month or so, we were cooking on gas. We’d locked-down the core hub and spoke navigation model. Designs were coming thick and fast and quickly being made real. Before long we were testing build release candidates that were starting to look like an MVP.
Getting it into users hands
After our faltering start, the pressure was on to get our first release into the app stores ahead of Christmas and Virgin Holidays’ peak trading period. Without losing sight of the deadline, we wanted to be confident that our app would work for users so set about testing in a variety of ways, adapting to our level of certainty as the designs progressed.
Guerilla testing early prototypes
We took our basic visual prototypes to local coffee shops and lured participants with the promise of free coffee in exchange for their time and feedback. Across two full days with a day between to update prototypes, our tests helped us quickly and cheaply decide and refine the core IA, navigation model and level of detail in the content.
Remote testing navigation models
As the funnel narrowed on our design patterns, we wanted to test the crucial navigation more vigorously. Using more complete prototypes that incorporated our earlier learnings, we ran an online unmoderated A/B test to compare how our two navigation front-runners performed and arrived at a clear decision for what to bring into build.
Live pilot with real customers
We now had plenty of confidence in our MVP designs so turned our attention to testing our build with Virgin Holidays customers. Would our app work overseas? Would it work offline? Would it help our customers to enjoy a better holiday?
After trialling a few distribution methods we settled on using Apple’s TestFlight for a pilot with iOS users to run a few weeks ahead of launch. We directly recruited customers travelling to New York within our short test window and set them up to receive the app. In the spirit of agile, we gave our testers an app build hot off the press and awaited their feedback. Through emails and a survey we gathered some very useful qualitative feedback and crucially, helped prove our app not only worked in real life but happily improved our customers holiday experience.
Pressing the button
By launch day, the team had done everything possible to make sure we were giving our customers a robust and useful app. Rather than the common panicked flurry of new code, our app was released as a stable and well tested build and the email was sent to selected customers to sustainability grow our user base. Nonetheless, your first public release is also a figurative release of pressure for the team – the culmination of months of effort and plenty of hurdles overcome!
Shipping it is just the start
It seems we’re all programmed to think of ‘launch day’ as a finish line but in reality it’s just the beginning of your relationship with your users. If you’ve kept it lean ahead of launch, you’ll have a lengthy backlog of features that didn’t make it into the MVP. Plus, now the genie is out of the bottle. No matter how well you’ve tested, expect a flurry of feedback and bug reports via app store reviews as your new users explore every edge case imaginable. Like a website, keeping an app out there involves more than just adding features. Your app will need to keep pace with new devices and operating systems. Changes to your service or content that impact the web and the app will now have two sets of code to be updated. At Virgin Holidays, the launch of the app meant a product team would now own it on an ongoing basis.