Developing a diverse, accessible and scaleable colour palette
How we evolved Wellcome’s brand colours to support our digital products and make sure that we can confidently build accessible digital experiences.
Colour is a fundamental part of how we perceive the world around us; it evokes emotion, grabs our attention and conveys meaning. Understanding colour and its relationship to religious, cultural, political and social influences can become a powerful communication tool.
The importance of colour in UX design goes much further than an individual designer’s taste and choosing aesthetically pleasing combinations. In addition to implementing colour psychology and theory to influence users, designers also account for how the users perceive colour and the profound impact it can have on the usability and effectiveness of a website or app. Colour is used to reinforce the brand values of an organisation, create a visual hierarchy within a webpage, to engage users and to help them learn interaction cues.
Applying colour to a website seems simple; however, with over 16 million unique colour values to choose from, ensuring it is used harmoniously across larger products and teams can quickly become complicated.
Why did Wellcome’s colours need developing?
Before I started this project, Wellcome’s colour guidelines included both RGB and HEX values — the codes that describe colour digitally — but guidance for digital usage stopped there. By only specifying a few variations of each colour, with no direction on how they should be modified, the guidelines created uncertainty around how colour should be applied digitally and how we could work to meet the standards of the Web Content Accessibility Guidelines.
I was receiving an increasing number of questions around how to apply Wellcome’s existing colours and multiple requests to make sure that designs passed the WCAG for accessibility. It became clear that our brand colours did not support our digital products as well as they could, and we would need to develop them so that we could confidently build digital experiences that are both accessible and inclusive.
Understanding the breadth of the problem
The first step was to look at all the colours specified in Wellcome’s guidelines and used across our product codebases. This audit revealed two things: firstly, due to the lack of detail in Wellcome’s colour guidelines, multiple colour variations were being used across our products. For example, one product listed eight subtly different oranges and, out of the 200 colours I discovered, there were 53 shades of grey. In addition, the absence of a shared naming convention across our products meant that the same colour values repeatedly appeared under different names; adding to the confusion.
When developing digital products, the names we use to describe colours can become confusing if not chosen sensibly. Without a shared language, colours become abstract and hard to discuss. A naming convention provides a consistent way that both engineers and designers can to refer to colours.
Designer: Can we make that box dark grey, please?
Engineer: Sure, which dark grey? #3D3D3D or $Silvergrey?
Designer: No, make it $Boulderdarker
Engineer: Great. There are two HEX values for $Boulderdarker… which one should we use?
So our new colour guidelines would have to;
1. Specify a higher number of variations of tints and shades for each colour
2. Create a naming convention to describe our colours
3. Guide designers and engineers on how to work within Web Content Accessibility Guidelines
Filling in the gaps
By creating a matrix of the existing colours across a colour spectrum, organising them from light to dark, it quickly became clear just how many tints and shades of each colour were missing from the existing guidelines.
The next step was to fill in the gaps between these existing colours. The aim was to make sure that the colours worked harmoniously together with the existing colours. To achieve this, I knew it would be a process of refining and tweaking the colours.
I decided to use the HSB (Hue Saturation Brightness) colour model while plotting new colours as it allows for more nuanced control than RGB, making it easier to create colour palettes that work harmoniously. In the HSB colour model, brightness is determined by a number between 0 and 100, with 0 being black and 100 being white. With that in mind, I decided that each hue should have ten variations in tint and shade.
I used a combination of two existing tools to generate the first iteration of the missing colours. The Sketch plugin Chromatic can be used to plot a segmented gradient between any two colours, and Lyft has done exciting work in developing their ColorBox tool that generates a range of colours from an individual hue.
For this first version, I took one colour from each hue and expanded it across ten tints and shades, giving me a foundation from which to iterate. Comparing this library of colours against the colour matrix, I tweaked each of the values to make them align more closely.
What’s in a name?
The next step was to implement a logical naming convention. The Wellcome brand colours all have names. Names such as Bora Bora, Rich Tea 3 and Brogues. I like these names, but they don’t contain any information about the colours that they describe. A more logical approach is to call the colour by its common name; for example, Bora Bora becomes $blue; then add a number from 0 to 100 that represents its lightness. So if 0 is light and 100 is dark, if I say $blue80, it should be clear that the name describes a dark blue.
Accessibility first
At Wellcome, we strive to make products that are inclusive and accessible to everyone. One of the ways that we do this is to use the Web Content Accessibility Guidelines to make sure that all text across our sites passes to a AA standard. The current brand guidelines do not offer any instruction on how to work within the WCAG guidelines.
My ambition was to embed the WCAG rules for text contrast into the colour palette itself so that both designers and engineers can be confident that they are building accessible products. By checking the contrast of each colour against white and black text, and making some adjustments, I was able to achieve this goal. Colour variables from $colour00 to $colour50 (the lightest tints) are all accessible to AA standard when overlaid with black text. Colour variables from $colour60 to $colour90 (the darkest shades) are all accessible to AA standard when overlaid with white text. With some further adjustments, these darker shades all passed AA when used as coloured text.
With the small adjustments made to the colours, it was then necessary to repeat the second step and compare the new colours with the old, making further tweaks to align them, ensuring that they still passed the accessibility rules I had embedded into the colour palette.
Applying to our products
We want the new colours to have a low visual impact from the user’s perspective so that they don’t notice a huge difference when the new colours are applied. The final step was to test the new colour palette by taking key pages from the websites and adjusting their colours to match the new palette. Of course, in doing so there were further adjustments to be made. The image below shows the final colour palette, including the accessibility rules. Colours with stars indicate that they are matches with the original colours.
With so many colours to choose from, there is a risk that the products become busy and multi-coloured. To provide some guidance on how to use the palette, I split it into groups of colours for each product and created a diagram that illustrates the ratio in which to use them.
Our new digital colour palette is just the first iteration; as we use and test it, I expect it to adapt to ours and our user’s needs. By taking the approach that I have outlined, we now have a colour palette that is diverse, accessible and scalable, one that can evolve alongside our digital products. We will be sure to update you on how these colours continue to develop in the coming months.
