How we scaled our design system to unleash Skyscanner’s new brand

Skyscanner’s design system, ‘Backpack’, played a crucial role in enabling the company’s recent brand refresh. In this piece, Shaun Donnelly looks at how having a design system helped Skyscanner — and could help other businesses give themselves a makeover

Skyscanner Engineering
Nov 19 · 8 min read

Introduction

In September 2019, our new brand launched. It was the culmination of over a year of work, touching every part of the company.

Three screenshots of the Skyscanner app on iPhone, displaying various screens from the UI.
Three screenshots of the Skyscanner app on iPhone, displaying various screens from the UI.
Our iOS app showing off our new brand.

The squad I work in looks after Backpack — Skyscanner’s design system. We were tasked with using Backpack to seamlessly roll out the new brand across all of Skyscanner’s products. Here’s how we did it.

Primer

We describe Backpack as ‘the codification of Skyscanner’s design language’ — a representation of all the discussions, debates and decisions that make up design at Skyscanner.

Backpack is the codification of Skyscanner’s design language.

Backpack provides components for three platforms: Android (Kotlin/Java, React Native), iOS (Swift/Objective-C, React Native) and web (React). These components are used to build a consistent interface for travellers regardless of the platform they’re using.

Note: All code samples here use React, but the approach I describe broadly works for other platforms, just using different syntax.

The new stuff

The new brand changed pretty much everything about our products. Our logo, typeface, illustration style and colour scheme all changed completely.

Early on, the design team decided that Backpack components would be replaced like-for-like. Rather than completely changing our components, we’d just change some style attributes and keep all the APIs the same. This meant that users of Backpack would have an easy upgrade path as only the look of components would change.

For example, here’s our flight search button component. The version using the new brand has a different font, corner radius and background, but everything else is the same.

Backpack’s primary button in the old Skyscanner brand.
Backpack’s primary button in the old Skyscanner brand.
Backpack’s primary button in the old Skyscanner brand.
Backpack’s primary button in the new Skyscanner brand.
Backpack’s primary button in the new Skyscanner brand.
Backpack’s primary button with the new Skyscanner branding.

The problem

Back to our task — roll out the new brand for web and apps in a way that satisfied the following criteria:

  • We should be able to turn it on via an experiment for testing it with travellers before it goes live to everyone.
  • It should require as little work from individual squads as possible. They have their own priorities and can’t drop everything to update their screens to support the new brand.
  • Ideally, Backpack should remain open source throughout without leaking the new brand to the outside world.

We discussed a number of ways to accomplish this. Some of the options we considered were:

A new prop

Add a prop to all of our components to toggle the appearance of the new brand, like this:

<BpkButton title=”Book hotel” newBrand={true} />

This approach was appealing for its simplicity, but it meant that we’d be building the new brand into the components themselves and therefore we’d have to make the code closed-source lest we leak the new brand.

Completely new components

Create a bunch of new components we could publish on our internal GitHub that match the API of the old components, but have the appearance of the new brand.

<BpkButtonWithNewBrand title=”Book hotel” />

We discounted this idea pretty quickly, as splitting our code in two would undoubtedly cause us a lot of headaches. If we changed something in one component, we’d have to remember to mirror the change in the other component every time. Then, once the new brand went public we’d have to pull all of the closed-source code back into the open-source repo. In summary: nope.

New versions of components

We’ve always strictly followed semantic versioning with our components. Maybe we could publish updated components to Skyscanner’s internal npm registry, then consumers could switch the versions they’re using:

dependencies: {

Unfortunately there were a few big downsides to this approach. We’d have to publish the code on our internal GitHub so we’d have all the same issues that the ‘Completely new components’ idea suffered from, plus we’d have to ask consumers to switch over to these new versions all at once, which would make it difficult to test the new brand and roll it out market by market.

In summary, all of these solutions were bad for different reasons. Fortunately, we came up with a better one.

The solution

Our components have supported theming for some time. It’s used in our booking flows so that our partners can give travellers an experience that reflects their brand when they’re booking directly on Skyscanner.

Screenshot of a partner-branded hotel booking screen on Skyscanner’s desktop website.
Screenshot of a partner-branded hotel booking screen on Skyscanner’s desktop website.
A partner-branded booking screen. The primary button is using Hyatt Regency’s brand colour.

Applying a theme is straightforward. Engineers wrap a ‘theme provider’ around the components they want to apply a theme to and then pass the theme provider some information to tell it about the theme. Any Backpack components inside this theme provider have access to this information through React’s context API, and contain logic to change their appearance accordingly. Here’s a simple example:

const partnerTheme = {

This results in the button component changing from this:

Screenshot of a standard Backpack primary button.
Screenshot of a standard Backpack primary button.
A standard Backpack primary button.

To this:

Screenshot of a Backpack primary button with some theme properties applied.
Screenshot of a Backpack primary button with some theme properties applied.
A Backpack primary button with some theme properties applied.

Extending theming

With a working solution, the next step was to actually put it in place.

As theming support was originally intended for partner branding, it only allowed certain colour properties to be themed. In the example above, you can see how the only themeable properties of the button component were the text and background colours.

To get theming to a place where it could be used to showcase the new brand, we needed to make lots more things themeable. This required a mixture of adding more themeable properties, for example adding corner radius theming to the button component, and adding theming to components that didn’t need it before like the star rating component.

To make things more difficult, we were doing all this in the open source world which meant we needed to be very careful to not reveal why we were making all these changes in our pull requests.

Building tooling

Once the design system was in a good place, we had to ensure that the roll-out of the new brand would work. For this, each squad that used Backpack needed to be able to check if the pieces of UI they look after were ready for the brand refresh.

To do this, we built some tooling for our website and apps that would allow internal users to turn on a particular theme.

Because everything is wrapped in a theme, all the components on the page change their appearance instantly. Squads could now apply a theme using a switch in the developer menu and would know straight away which parts of their UI weren’t ready, as they’d still show up with the old Skyscanner branding.

The two themes

We built two different themes, named London and Azure.

London

This theme was purposefully garish, to make it really obvious to people when things weren’t being themed correctly. For hopefully obvious reasons, we were very careful not to accidentally release this to travellers.

Screenshot of a flight search page in Skyscanner’s iPhone app with the ‘London’ theme enabled.
Screenshot of a flight search page in Skyscanner’s iPhone app with the ‘London’ theme enabled.
Much wow.

Azure

This was the theme we used to encapsulate the new brand. We chose ‘Azure’ because it was the original name for our new signature ‘sky blue’ colour. It also had an additional benefit: if any references to it accidentally made their way into our products ahead of time people would likely assume that we were referring to the cloud computing platform rather than our new branding.

Feature toggles

For components that should only be shown when the new brand was enabled, we added a feature toggle that could be read from inside the code, so engineers could do things like this:

const someComponent = () => (

Getting everything ready

Once the tooling was in place, our colleagues in more than 41 teams across Skyscanner came together to test all the screens they looked after with the theme applied, and then fixed any issues that came up.

Hooking it up

The final piece was to hook the theming support up to the internal tool we use for running experiments; this tool is called ‘Dr Jekyll’. Thanks to Skyscanner’s strong experimentation culture we had lots of support doing this from our colleagues.

This allowed us to selectively enable the new brand in any way we wanted using Dr Jekyll. We could roll it out region by region, on a percentage basis, or using any other heuristic we wanted.

Rolling it out

On launch day, we enabled the new brand for tens of millions of travellers by flipping a switch in Dr Jekyll’s UI — a simple-sounding act, but one with thousands of team hours behind it.

At the same time, there was a huge coordinated effort elsewhere, which saw colleagues carrying out tasks like uploading assets to app stores at exactly the right time, coordinating with partners, replacing our logo all over the internet, updating the liveries of our physical offices — and much, much more.

In summary

This was a big undertaking for us. As a design system team we primarily work on small, discrete tasks like components. Working towards a huge, immovable deadline was new for us, but we really enjoyed the way it brought us together.

We couldn’t have done any of this without the over 40 squads who got us to 100% design system adoption — when people don’t use a design system is loses its purpose, which was emphatically not the case here.

For the future, we now have a clear, modern brand that we’ll use to enhance our design system further to give our travellers a world-class experience.

Further reading

Join Skyscanner, see the world

Life-enriching travel isn’t just for our customers — it’s for our employees too! Skyscanner team members get £500 (or their local currency equivalent) towards the travel trip of their choice in 2019 — and that’s just one of the great benefits we offer. Read more about our benefits and have a look at all of our open roles right here.

About the author

I’m Shaun Donnelly, a Senior Software Engineer working in the Phone Experience tribe in London. I work in Backpack squad — an enablement team who create beautiful, accessible and reusable UI components for our colleagues to use across Skyscanner. Outside of work my hobbies include cooking, failing at DIY and complicated flight itineraries.

The author in the CNN Centre in Atlanta Georgia, stood next to a cartoon bear.
The author in the CNN Centre in Atlanta Georgia, stood next to a cartoon bear.
Shaun Donnelly, Senior Software Engineer at Skyscanner

Skyscanner Engineering

Written by

We are the engineers at Skyscanner, the company changing how the world travels. Visit skyscanner.net to see how we walk the talk!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade