How we fixed Skyscanner’s broken colour palette
We untangled a complex web of colours so distinctive brand moments could live alongside accessible, usable interfaces.
It all started back in 2019 before I was working at Skyscanner. I remember sitting in a cafe in Budapest reading the latest conversations online about the new brand update. It’d sparked a flurry of debate — something which edged Skyscanner into the focus of discussion in many design threads.
A slick new look. Fonts by Colophon. What was not to love? One thing that caught my eye was all the refreshed colours. 31 of them in total. All with creative names like ‘Monteverde’ and ‘Buñol’, which made me wonder, how would you ever know what to use and where? Choice can be liberating, but too much can be overwhelming.
But, I was on holiday. And was headed to the Szechenyi Baths later that day. I put down my phone and continued my life for another 2 years.
I landed a job in control of colour
Fast forward to July 2021 and it was me under the watchful eyes of those design threads. I’d landed a job at Skyscanner as a Senior Product Designer. As with all design jobs, there was plenty to learn. Brand guidelines, GitHub docs, Figma files, and a load more to get to grips with.
It wasn’t quite black and white
Even after a few months, I was still struggling with which colours go where in the product. Every day I’d spot a Slack thread or Jira ticket discussing a Product Designer’s use of certain colour combinations and whether they were right or wrong.
Links were different colours. Primary buttons were mostly green unless they were for a certain type of booking; then they were blue. Confused? I was too.
There were two main problems we knew we had to fix. Our Brand and Product teams were using the same colour rules. We knew one palette needed to be simple and easy to use, and the other needed to be bold and attention-grabbing. To add to this, the colour palette combinations weren’t entirely accessible.
It was time to get to work
We spent some time untangling examples of where colour was confusing. Was it the colour, or was it the UI? Or a bit of both? There was the initial idea to make a few of the existing colours more accessible, but the more and more we looked at it the more we realised they all needed changing.
Coming up with the new colour values was a creative process first — technical later. Trusting our gut was key, we never relied on tools or plugins to come up with combinations. We put the colours and the UI in front of the stakeholders and asked them what they thought. Plugins can never take into account human feedback.
We defined a more focused palette with core pairings and extended pairings. The darks got darker and the brights brighter. Not everything was simply a tint either. For brand colours, we mixed new complementary colours that weren’t derived from the same hex codes.
Ordinary works best
Then we looked at the naming: the poetic names had to go. They just didn’t work. We started calling ‘Kolkata’ “that orange colour” and ‘Erfound’, “that yellowish colour”. If you didn’t know, Kolkata is India’s West Bengal State famed for its colourful yellow flower markets, and Erfound represents the sand of a desert oasis in Morocco — while these allusions were beautiful, they were too difficult to remember and made it harder to discuss the colours, not easier. Things needed simplifying.
We all know simple names like yellow, orange and purple are much more usable. Also, we were about the change the actual colour so couldn’t say that Kolkata was still Kolkata.
Making our colours inclusive
A single colour alone can’t be inaccessible, but when paired with another colour, simple contrast standards need to be met. Our problem was that we already had 31 colours being used in endless combinations and our old combinations chart was incredibly complex.
The chart also ignored combinations that technically met the accessibility standards but the Good Taste Police (that’s us) didn’t actually like. So we made the simple decision that limitless colour combinations weren’t allowed. If text is only black or white, it limits the number of combinations available.
Accessibility issues in our product related to colour contrast looked like this:
- 25% of colour combinations of iOS were inaccessible
- 17% of colour combinations on Android were inaccessible
- Numerous accessibility colour tickets
It was a bit of an endless web — If we changed a colour in one place it could break a combination somewhere else.
Not my first rodeo with Brand and Product
I’ve been lucky enough to work with several big brands in the digital space. If there’s one thing that I’ve found they have in common it’s that their brand guidelines are rarely digitally focused.
Colour in particular gets created with marketing in mind where the objective is to grab attention. Bigger. Bolder. Better. But we all know if everything shouts, then nothing shouts. I know that colour adds emotion and gives users a way of remembering a brand. But it can also cause a lot of confusion, too. A wide range of colours shouldn’t be relied on to indicate meaning alone.
By using a brand’s digital products (you’ve downloaded our app, right?) we can assume your attention has been grabbed and you’re already somewhat engaged. Colour palettes for products should be the opposite of attention-grabbing. They should be an antidote to anxiety — there to create a sense of calm. Less is more.
A shared set of colours and principles
We split the palettes into Brand and Product libraries, driving from the same primitive values but used differently.
The Product library was published and applied to dozens of screens. We wrote rules and kept all of this together in Figma. Screens were scrutinised, rules were questioned and combinations examined. But we had a core set of colours and principles as a vision. All of this was before we’d even started talking to Engineering.
When design met code
The first steps of the process were purely design-focused and conceptual. We needed to take it right to the end and be sure our logic was foolproof. Next, we applied these changes to a massive product. I wish it was as simple as updating a few HEX codes. But Skyscanner is a website with 2 apps on various code platforms, built by dozens of feature teams. Even the smallest of changes can be a lengthy process globally. Luckily, I work in the Design System (it’s called Backpack) and it was clear we needed to make these changes centrally. Hello, tokens 🙏
Less colours. More tokens
We had made big reductions in the number of physical colours Product Designers and Engineers could use, but this shifted the problem sideways by creating more tokens.
Tokens are the biggest buzzword in Design Systems right now. Simply put, these are design decisions that hold a single value. A colour code, type size, or measurement.
Tokens are the smallest part of the system (sub-atomic), they apply to large-level pieces of the Design System (atoms, molecules, patterns etc). If you set up tokens correctly you can make cascading changes later with ease.
Here’s the first post on Atomic Design if you need to know more.
Our changes in Figma and in code
- More than 80 visible token styles in code
- More than 30 private tokens
- Remapped 69 old code tokens
- Migrated and deprecated 40 Figma styles
- Synced this all across Figma and code.
Semantic colours in design
Since drafting this article, Figma introduced something we were unable to do back in 2022 — add both primitive tokens and semantic tokens and link them together. We added this to our Colour documentation in our Design System.
Rather than picking colours by their primitive names, we wanted Product Designers to start thinking of colours by their role. ‘Sky Blue*’* meant nothing. ‘Core Accent’ on its own is rather abstract, but when grouped into folders like Text, Core, Status, Surface and Canvas, it started to build a simple set of choices anyone can understand. The names are the rules.
Our semantic Product colours’ names correspond with the code so Engineers use the same names to build features from these limited styles. We published install guides for Engineers for the three platforms. The primitive name is shown next to the semantic name for extra affordance.
Some tokens are hidden
Although everyone can access the 28 final tokens we needed more choices to deliver interactive states for components. For instance, our feature button needs to change colour on hover or on press. That colour doesn't need to be openly available as it’s a temporary state change.
So, we used a collaborative Figma file where we worked out tints and shades for all of the colours, and then picked the appropriate one for the specific UI. Ultimately it doesn’t really matter how many hidden tokens there are, everyone gets the interactive states for free without worrying about where the colour comes from.
Colours for illustrations and maps
There have been a few exceptions since we started our colour adventure. Our brand illustrations need a wider set of colours. And so do our maps and data products. Product Designers can extend the colour usage as long as it’s put back into the system.
Colours sent to the graveyard 👻
Deprecation is something you don’t hear about much as a Product Designer. If something exists in code and is in use, you can’t just get rid of it. It’ll break something, somewhere. You must deprecate it.
The same is true for the colours we removed in Figma as they couldn’t relink themselves. We had to work out what could be remapped as a global rule and what couldn’t.
We used our dedicated Graveyard Library to place unwanted styles. This made it easier to batch style changes later. We even prefixed all the styles with a ghost emoji 👻 as a handy flag not to use the colour. This was backed up with a table of suggested colours to use instead.
The process took months. We had styles synced across Figma, code and Excel, as well as an extensive timeline planned in ClickUp. The rollout took even longer but was staggered so we could support different teams adopting the changes at different rates.
Two libraries for two teams
Our Product and Design teams need their own libraries so there’s less chance of Product Designers choosing a Brand colour. And Product Designers shouldn’t have access to the Brand colours either. If you’re still exposing primitives in 2023, you’re doing it wrong.
Making dark mode cool🌛
As we all know dark mode isn’t just about saving battery or improving visibility, it’s also a stylistic choice. And there are no rules that say dark mode needs to be the inverse of day mode, so we tweaked our system by injecting cool blue hues throughout the palette. These colours are special, even their names align with the lights going out.
The modifier ‘Dark’ wouldn’t have sounded right (Dark Dark Sky, Dark Sky Blue) so we opted to rename the colours using ‘Night’ as the modifier.
- ‘Dark Sky’ becomes ‘Night Sky’
- ‘Sky Blue’ becomes ‘Night Blue’ and so on…
We recently updated all of our Figma styles to variables (Figma’s name for tokens) so we can flip between day and night in a few clicks. This is the power of working with tokens.
Making accessible choices
For Product
Our new reduced Product colour palette has far fewer colours with well-established rules on how to use them. For instance, mixing and matching use cases isn’t allowed — Designers know this by looking at the semantic names. But just in case, we also have an internal swatch guide: ‘AA’ denotes text colour + background is accessible. If there’s no ‘AA’, you don’t use it that way.
For Brand
The Brand palette is more expressive for when we want to dial up our brand volume. This is where typography, images, colour, and use of white space come together on a social campaign, on billboards, or even on merchandise given to new starters.
Our Hero Typography is often shown in uppercase with black weight (900) over an image, which makes the background a moving target. This is impossible to measure so common sense must be applied: if we think it’s hard to read, it most probably is. This is covered in more detail in our internal brand guidelines.
To help land our minimum standards, we used APCA Contrast Checker for display typography rather than WCAG standards*. APCA doesn’t offer a pass/fail solution. It looks at font weight, size, and background against text order to determine different results. 48px Bold is our minimum standard when combining Core + Bright colours. We refer to this as Hero Text. Any text smaller than 48px Bold should be pure white or black for the corresponding surface.
Solving the problem, or just adding to it?
Coming up with colours is easy. Managing how they’re used is incredibly difficult. Going back and resolving unchecked uses for 31 colours was a job bigger than we could’ve ever imagined. This took a year and involved dozens of contributors, and many stakeholders. But our travellers will continue to enjoy the benefits of this refined palette as we continue to refine our UI.
If you’re thinking about adding colour to a digital product without defining the system first, take a second and ask yourself; ‘are you solving the problem, or just adding to it?’
Fancy hopping on board the Skyscanner team?
Check out our jobs board to see if any design roles suit you.
Credits
Giles Perry — Director, Product Design
Ross Mawdsley — Head of Visual Design
Oliver Curtis — Senior Web Engineer / Squad Lead
Maria Neumayer — Principal Mobile Engineer
Gert-Jan Vercauteren — Senior Mobile Engineer / Accessibility Lead
Heather Hepburn — Head of Accessibility
James Wesson — Content Design
Caveat
This project only focused on the colours within our UI, the UI remained unchanged (we’re working on it).
