Design System


Building an Atomic Design System with Sketch Libraries

How we implemented it in GVC Product Design team


Our ecosystem

For a better understanding let’s start with some context about the online betting and gambling company I am working for. 
I am currently working for a big corporation called GVC Holdings as a Senior UX/UI Designer. GVC operates some of the leading consumer-facing brands in the online gaming industry, including Bwin, Party Poker, Party Casino, Foxy Bingo, Ladbrokes and Coral.

The Company acquired Bwin.Party Digital Entertainment in 2016 and Ladbrokes Coral in December 2017. The strategy of the Company is acquiring the most promising gambling brands in the market and migrate them into their own platform. It is a white labelling philosophy. There are several brands running into the same platform but each website looks different, having a small level of customization (logo, main colors, typography, products, lobbies, game tiles, etc) regulated by a general theme park.

The need of a design system

Going through so many acquisitions and merges, which means migrating the new labels into our platform, we felt the need to implement a design system.

GVC main brands and their products

GVC has several design and development teams spread across offices in different countries (London, Vienna, Gibraltar, Hyderabad, etc) which means we all need to collaborate to keep the company’s design consistent. That is why we created a design system, a centralised place for designers and developers’ communication. Rather than repeatedly building the same component over and over, we can share, reuse, and distribute the same design and code from a centralized space: an online website with all the components and its code for every brand  —  the theme park.

img_building a design system.png

Implementing a design system:

1. Grids

Using a grid is very important, specially when working on a big team with designers in different locations and workspaces. And by team we also include the developers. Each member of the team can be working on a different page/screen for the same product so make sure you are all using the same grid. Every team member should be aligned, otherwise the designs will not match the implementation and you might be duplicating unnecessary work. Example: if the developers are working on bootstrap the designers should probably be using the bootstrap grids.

Real life grids applied to a responsive website

2. Libraries

In GVC, we use Sketch to design our products. As there is many people working on improving the products at the same time we felt the need to have libraries with shared components and key pages (in our case they are the homepages, registration, login, account pages, cashback, deposit, etc.) — templates (groups of pages that are based on the same layout) we use when we need to design a new page or improve an existing one.
To implement these shared components and pages we used Dropbox (to share the file) and Sketch Libraries (to create the file) include symbols that can be used across projects. Saving your library in a shared location means that every member of the team can access these symbols and components.

Every time someone updates a library, there will be a notification in the files that have the changed components. We have one designer responsible for every library file. Having several designers updating the same shared file could become messy!

Since we are running on a white label platform, we have one library per brand and another generic that contains all the common elements (typography, colors, buttons, input fields, headers, navigation, switchers, cards, footers, etc.) and wireframes of all the pages shared between the brands (such as registration, login, cashier, deposit, etc).

Mobile headers: wireframes from generic library vs. Party Casino library

Mobile headers: wireframes from generic library vs. Party Casino library

The libraries have nested Symbols and they are organized in atoms, molecules, organisms, templates and pages (Brad Frost’s Atomic design).

atomic design.png
  • The atoms are the simplest elements and they can be used individually (ex.: label, button, input field, icon)

  • The molecules are a combination of atoms (example of a search bar: an input field with a “search” label, a button and a magnifying lens icon)

  • The organisms are bigger components with a combination of atoms as molecules (such as a menu header with the brand logo, links to other pages and a search bar)

  • The templates are groups of organisms working together to form a page, it’s basically a wireframe.

  • The pages are specific instances of templates, where the placeholders are replaced with real content to give the highest level of fidelity.

We’re not designing pages, we’re designing systems of components.
 — Stephen Hay

3. UI Style Guide

At this point the Libraries need Style Guides as supporting material. The Style Guide, as the name suggests, tells the designer and the developer when to use a certain font size, a specific input field, etc. It’s also a document that compiles all the atoms, molecules, organisms and templates available for each brand. We have created a Style Guide per brand.

Input fields common to every brand (from the generic library)

4. Everything in one place

Available to every element of the product team, including product owners, is the theme park — the online version of the libraries made by the developers with the codes for every color, atoms, molecules, organisms.

5. Change log

Every time the responsible designer for a Sketch library updates it he should note it on the change log (it can be a shared text document) for all the designers to be aware and for the developers to update it the theme park.



The design system in place improved the work process and productivity of designers and developers.