← Back

Booking.com: Design system color playground

Wireframed, designed, prototyped and tested the functional color playground for the Design system at Booking.com
Booking playground case study cover

Overview

Booking.com is the largest accommodations platform in the world. Its tech team is made of 1.2K+ employees split into product teams. My team, the Design System team, had a main goal: to enable product teams of Booking.com to deliver higher quality work faster by creating and maintaining tools, guidelines and libraries of the Design System.

My role

My role in this project was to wireframe, design, test and hand off the prototype to developers for implementation.

Target audience

This project’s target audience was the designers at Booking.com who use the Booking Design System.


Problem statement

Historically, the design system contained a color palette that is directly available for usage by our designers and developers. To strengthen the foundations of the design system, my team introduced Functional Colors.

Sketch folders for each component

Rather than referring to colour names, functional colours communicate a specific context where colour is used. For example, functional colors can be action-foreground, background-disabled, border. Whereas the old color palette had colors such as “grayscale-900”, action-300”, etc.

Sketch folders for each component

Even though this concept was not new to the design world, it was new to the company. To make it easy for designers and developers to use these functional colors, I was responsible for designing a playground interface where users can discover colors and understand their usages to help them choose a color better.


The process

Define

First, with the help of my team, I defined the requirements that we needed to fulfill for this project to move forward.

  • The old color palette playground needs to be replaced the new functional color palette playground Sketch folders for each component
  • The playground is part of our internal Design System documentation tool, therefore the shell of the playground (header, sidebar, etc) needs to be consistent with the tool Sketch folders for each component
  • The playground should provide a way for designers and developers to

    • Browse the colors, categorised by function
    • See a color’s properties
    • See example of the color’s usage
    • Search for a color by keyword
    • See colors in dark mode
    • See snippets of code

Design

Next, I came up with a couple of options for a concept playground. To help make an unbiased decision, I listed pros and cons for each option.

Option 1
In the first option, the component example is in the middle of the page. The sidebar contains all colors that the user can scroll and choose from. Sketch folders for each component Pros:

  • The layout (component in the middle playground) is consistent with the other pages of the tool
  • The design of colors in the right sidebar is similar to most design tools (such as Figma) which makes it intuitive and easy to use
Cons:
  • The layout does not allow for a place for properties and information about each color. We would have to use a modal which we do not prefer

Option 2
In this option, the colors are shown in the middle of the page as a list of two columns. The properties and example preview is on the right sidebar. Sketch folders for each component

Pros:
  • Right sidebar allows space for properties
Cons:
  • The colors’ list layout takes too much space
  • The two columns of lists can be confusing with the way the categories are shown

Option 3
In this option, the properties and example preview is also on the right sidebar, but the colors are displayed in a grid layout. Sketch folders for each component

Pros:
  • The grid layout allows more space for colors to be displayed
  • The grid layout allows categories to be listed in an organised manner

I presented the options to my team and after a few rounds of feedback, I decided to go with option 3 as it fits all requirements that we needed.

Prototype & test

Using option 3 to move forward, it was time to make the concept into reality. I designed a few other screens then created a Figma prototype where a user can hover and click on multiple colors and see their properties.

Try it out!



I shared the Figma prototype with designers and developers across the business and I sent out a survey to fill after browsing the prototype. From the 16 responses I received, 75% found the functional color feature helpful in their daily design work

Challenges

  1. Many did not understand the difference between core color palette and the functional palette as this was a new concept for them
  2. Dark mode switch was not visible to many
  3. The current layout and structure of functional colors seemed random to some and hard to scan
  4. Some think they need more than one example per color to prevent ambiguity
Using these results, I made changes on the prototype
  1. To make functional colors easier to understand, I added a temporary banner at the top that links to the full documentation on Functional colors
  2. I changed the dark mode switch position and placed it inside the playground to make it more visible as this is where the eye will be focused on the most
  3. I rearranged the colors to follow a more harmonious order between colors
  4. I added more examples per color and added a Back and Next buttons to browse between them
Sketch folders for each component

Outcome

I handed off the prototype and Figma file to the developer in my team and presented the design covering all use cases and limitations. After the developer implemented it and me reviewing the implementation, the playground was released.

The feedback we received from the community was overwhelmingly positive. Because of this playground, designers and developers were able to discover colors and understand their context which avoids misusages and creates a consistent design throughout the product.