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
Introduction
In September 2019, our new brand launched. It was the culmination of over a year of work, touching every part of the company.
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.
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: { “bpk-component-button”: “8.0.0.new-brand”}
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.
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 = { buttonPrimaryTextColor: ‘black’, buttonPrimaryGradientStartColor: ‘red’, buttonPrimaryGradientEndColor: ‘orange’,};<BpkThemeProvider theme={partnerTheme}> <BpkButton title=”Book hotel” /></BpkThemeProvider>
This results in the button component changing from this:
To this:
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.
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 = () => ( newBrandEnabled ?
<CoolRebrandedComponent /> :
<OldBrandComponent />);
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
- Skyscanner for Android, iOS and on the web
- Our brand story
- Backpack — Skyscanner’s design system
- Case study for our new brand by Koto
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.
