Overview

User Experience

UI Components

Design Tokens

Overview

User Experience

UI Components

Design Tokens

Overview

User Experience

UI Components

Design Tokens

Product

Design Tokens

What we share here is the theory. Which strategy we used and how we applied it within our work process.We plan to share a public, light version of our UI Kit on Figma Community. Stay tuned!

Ground rules

Design tokens are extremely powerful to speed up the integration process and ensure cohesion and consistency. But their application can be complex and if wrongly setup, they could cost the organization more resources than they save up.

Naming conventions

In order to make this collaborative and cross-functional, we need strong naming conventions and we need to stick to it. Tokens includes lots of aliases, variables consuming other variables. If a naming convention isn't correct, the whole logic falls apart. We detail how we handle naming conventions in the protocols section.

Architecture

As mentioned, and as you will see in more details below, tokens are meant to be nested and consumed by other tokens. This requires a strong and flexible architecture from the get-go. We follow a 3 steps architecture composed of:

  • The Core

  • The Base (or semantic)

  • The components

While the Core remains unique, Base and Components will most likely be duplicated to create themes.

Supported attributes

Not everything is included inside design tokens. But we are confident to say that the rest is negligent at this stage.

Here are the list of supported attributes:

  • colors

  • spacings (padding, gap)

  • sizes

  • border

  • border-radius

  • typography

    • font-family

    • font-size

    • font-weight

    • line-height

    • letter-spacing

    • …

  • shadows

  • opacities

More tokens are actually supported, but we won't make use of it.

Design tokens are extremely powerful to speed up the integration process and ensure cohesion and consistency. But their application can be complex and if wrongly setup, they could cost the organization more resources than they save up.

Naming conventions

In order to make this collaborative and cross-functional, we need strong naming conventions and we need to stick to it. Tokens includes lots of aliases, variables consuming other variables. If a naming convention isn't correct, the whole logic falls apart. We detail how we handle naming conventions in the protocols section.

Architecture

As mentioned, and as you will see in more details below, tokens are meant to be nested and consumed by other tokens. This requires a strong and flexible architecture from the get-go. We follow a 3 steps architecture composed of:

  • The Core

  • The Base (or semantic)

  • The components

While the Core remains unique, Base and Components will most likely be duplicated to create themes.

Supported attributes

Not everything is included inside design tokens. But we are confident to say that the rest is negligent at this stage.

Here are the list of supported attributes:

  • colors

  • spacings (padding, gap)

  • sizes

  • border

  • border-radius

  • typography

    • font-family

    • font-size

    • font-weight

    • line-height

    • letter-spacing

    • …

  • shadows

  • opacities

More tokens are actually supported, but we won't make use of it.

Design tokens are extremely powerful to speed up the integration process and ensure cohesion and consistency. But their application can be complex and if wrongly setup, they could cost the organization more resources than they save up.

Naming conventions

In order to make this collaborative and cross-functional, we need strong naming conventions and we need to stick to it. Tokens includes lots of aliases, variables consuming other variables. If a naming convention isn't correct, the whole logic falls apart. We detail how we handle naming conventions in the protocols section.

Architecture

As mentioned, and as you will see in more details below, tokens are meant to be nested and consumed by other tokens. This requires a strong and flexible architecture from the get-go. We follow a 3 steps architecture composed of:

  • The Core

  • The Base (or semantic)

  • The components

While the Core remains unique, Base and Components will most likely be duplicated to create themes.

Supported attributes

Not everything is included inside design tokens. But we are confident to say that the rest is negligent at this stage.

Here are the list of supported attributes:

  • colors

  • spacings (padding, gap)

  • sizes

  • border

  • border-radius

  • typography

    • font-family

    • font-size

    • font-weight

    • line-height

    • letter-spacing

    • …

  • shadows

  • opacities

More tokens are actually supported, but we won't make use of it.

The Core set

The Core collection

The Core tokens are covering all the raw variables we need to cover nearly 100% of our design decisions.

For instance, this set includes an extensive color palette made of hundreds of values (we used the amazing tailwindcss color palette).

The Core tokens are covering all the raw variables. This covers nearly 100% of our design decisions.

For instance, this set includes an extensive color palette made of hundreds of values (we used the amazing tailwindcss color palette).

The Base set (or semantic)

Semantic collections

The base set gives meaning to some of our core tokens. The logic applied here is fitting our needs but can vary a lot from a company to the other as we all work on different products with different attributes and levels of complexity.

Semantic sets give meaning to our design decisions through clear naming conventions. The logic applied here is fitting our needs but can vary a lot from a company to the other as we all work on different products with different attributes and levels of complexity.

The components

Component collections

Our Product Design building strategy is based on our resources and optimized for us to ship quality UI in no time. So that designers can focus on customer and user scenarios.

In the making process of this UI kit, we've decided to embed the wireframe level as our Base UI.

This Base UI can be skinned with any customer theme we need, in a matter of seconds.

These themes are helpful to provide highly customized offers and mockups to our potential clients. They are also automatically exported and packaged to our various runtime environments, so that developers and engineers can integrate them in no time.

In the long run, these themes will be very useful as we move toward a self-serving model, whereas customers will be able to skin their products from the admin page. So we start paving for what is coming next.

Design tokens automation and package

From Figma to each of our runtime environments, our tokens are automatically shared and packaged for developers to use while integrating a piece of UI.

From Figma to GitHub

While waiting for Figma to natively support Design tokens, we use the Tokens-Studio plugin. It allows us to manage and store our sets into a GitHub repository.

From a JSON file to any platform or language

Once a change is made on Figma and pushed to our GitHub, and once the Pull Request has been reviewed and confirmed, an action script automatically converts the new JSON file into multiple languages using Style dictionary from Amazon.

The plugins uses logics such as simple math formulas. These logics aren't understood by style-dictionary and another step is required to 'flatten' these logics first. For this we use Token-transformer from Tokens-Studio team inside our script, prior to let Style dictionary do its magic.

Packaging for each runtime environments

To make it usable, it needs to be where developers need it. For this our DevOps team automated the creation of packages from our Design tokens repo to the various runtime environments that require to consume Design tokens.