FREE NOW Blog
Published in

FREE NOW Blog

How we set up the FREE NOW Wave Component Library in Figma

Taking a design library to the next level with Figma & tokens

How we set up the FREE NOW Wave Component Library in Figma

The Wave design system is the foundation of all FREE NOW web products. Born from a developer initiative, it quickly became a cornerstone of web development and web design.

Almost a year ago, our design team decided to switch to Figma. This article describes a general approach to how the new library was created and how we maintain it.

Where it started…

Initially, our design team used Abstract, Sketch and Zeplin. Everything worked fine, but testing Figma for a while prompted us to switch to this new tool entirely. Primarily to improve collaboration between designers, which has become especially important now that most of us work remotely.

What did this decision mean? Besides having to get used to a new tool, we had to transfer not only all the design layouts (including drafts), but also the design libraries that we used for work. Not to forget that in such cases, it is desirable to transfer the libraries first, since transferring layouts without them would imply having to redo everything.

At FREE NOW, we use three main libraries:

  • two design libraries for our two major mobile apps
  • the Wave DS for all our web products (more than 10).

This article will only cover Wave.

We set a clear timeline for the migration to avoid working on two different design platforms at the same time. We didn’t have a dedicated team — most of our developers and designers worked for product teams, so we had limited resources.

… and how it’s going

Before starting the migration, we needed to assess the situation: what worked, what was missing and what major problems we already knew about.

A large library of components

A big number of options for text fields, buttons, and other components simplified the work on the design to a big extent. The library had almost everything we needed. Initially, there was not much need for flexibility and extensibility when the library was created. However, as more and more components were added, it became clear that they were difficult to maintain and update.

Part of our old library
Part of our old library

Non-transparent colour management

The shared library included a brand palette containing different shades of various colours. The library was quite rich, but it was not clear which colour should be used in what situation. We documented our choices and framed our onboarding, but sometimes even company veterans had second thoughts about which colour to use in specific cases.

Not transparent color management
Not transparent color management

Component implementation in code varied from design

Sometimes, these differences were small and barely noticeable, like paddings or text styles. However, in some cases, they were quite visible.

In the code, some things were better organised

With a little research, we found that some assets were organised more clearly in the code. Furthermore, the developers thought about logic for some aspects we hadn’t even considered in the design library. And much of what we discovered gave us a better idea of what our design library was supposed to be.

Best practices

When starting to work on a new platform, it is very important to learn the best approaches for solving certain problems. One of the significant advantages of Figma is its huge community. And this is not just a huge number of articles and various kinds of video tips. Figma has made the community a part of its platform: there is a special “Community” section where you can find layouts, templates, plugins and widgets published by users themselves. And it’s all a great source of inspiration.

Figma community
Figma community

Naming convention

One of the things we decided to adopt from the developers was the naming convention.

First of all, to be a little bit closer to the code. When we migrated all the components, we wanted to relate the names of the components in the design library to their code name. And also, where possible, bring them in line with the code and the name of variant properties.

An example of an API draft for new design library components
An example of an API draft for new design library components

The naming convention was later extended to how we name design layouts in Figma.

Design tokens

While trying to solve several problems, such as transparency in dealing with colour, size, and other properties, we realised a lot can be solved with design tokens.

Tokens everywhere
Tokens everywhere

Design tokens are a quite popular topic and many articles have been written about them. So, to avoid redundancy, their main feature is that they allow you to simplify the development and support of design systems to a great extent.

Unfortunately, Figma doesn’t have a built-in support system for tokens. For now. Therefore, when we discussed the possibility of using design tokens in our library, it was important to understand how realistic the prospect could be. And it was important to define what efforts it would require. After all, if we talk openly, a lot of things are possible in Figma, mainly because Figma supports plugins. Which you can create yourself . There are a lot of great tutorials that explain how to do this:

But we needed a ready-to-use solution. And we found it: Figma Tokens plugin. If you want to know how it works, look at their documentation () or read this short article.

Figma Tokens plugin

Naming convention for tokens

Studying the experience of other companies, we realised that the naming convention for token design requires separate attention. For this, we also had to take into account the plugin’s own naming convention, which imposed certain restrictions. Our developers fixed this issue in later versions.

There’s a great article by Nathan Curtis detailing the different naming approaches and commonalities used by different companies. What’s important in this article is that Nathan defines a sort of template that you can use as is or adapt to your needs.

Given the limitations of the plugin at the time, the general feedback from the developers and the original component structure, we decided to adapt Nathan’s template.

Naming convention
Naming convention

As an example, Button and Input field looked like this:

Naming convention — example
Naming convention — example

It was also necessary to take into account what variables existed in the code already and what could eventually become a design token.

Existing variables
Existing variables

Token types

Brand identity is one of the foundations of the colour system in any design system. In our case, this meant that not only did we need to identify the brand colours, but also set a clear reference to them for all the other colour tokens. To do that, we needed to categorise the colour tokens by their type.

While adapting existing approaches, we identified the following types:

Base tokens
Primitive values in a design language, represented by context-agnostic names. We use them mainly to keep our brand colours (in raw colour values — HEX, RGBA) and specify values for core spacing, sizes, etc.

Base tokens
Base tokens

Common tokens
Common tokens relate to a specific context, usage or abstraction. They help communicate the intended functional purpose of a token and are effective when a value with a single intent will appear in multiple places.

Common tokens
Common tokens

Component tokens
Component tokens relate to a specific component using them. Their scope only targets the component they belong to. Component tokens can communicate not only the targeted properties but also their states.

Component tokens
Component tokens

We use component tokens only in extreme cases — when it is difficult for a particular element to be explicitly linked to common tokens. Both common tokens and component tokens are references to base tokens.

Migration

One does not simply…
One does not simply…

Backlog

It is not uncommon for components to depend on each other. The dependency can be direct, if one component contains the other, or indirect. For example, if both components have a common structure and it makes sense to create/design them together to take into account different cases.

Since we had two designers ( 😅) working on the migration project, it was necessary to decide which components to create first and divide the work between them.

In such cases, we should ideally start with the simplest atomic components, such as toggles, checkboxes, buttons, text fields, etc. These are basic components and even in the absence of other more complex components, designers will already be able to create new designs based on them.

Review

To track the work we used a simple kanban board in Trello with “To do”, “In progress”, “In review” and “Done” columns. Even when working on components in a team of two people, it is important to have a dedicated “In review” column.

Trello board

Developers check each other’s work through Pull requests, and designers need to follow the same principle when working on a design system. For a number of reasons:

  • The structure of components needs to be consistent.
  • To check for errors. We all make mistakes and it never hurts to have a second look.
  • During work, sometimes the eye gets tired. Some simple things are no longer visible, and you need someone with a fresh view.

In general, the creation of components should be treated very responsibly, because after their publication, other designers will start to use them, and at some point, it will be too late to fix any errors. You can try to fix everything, of course, but in some situations, the fixing may take hours or even days. So extra care in designing components will help avoid problems in the future.

A simple documentation

Initially, due to limited time for migration, we planned to go without documentation and just recreate all the components in Figma. However, in the process of working on the first components, we realised that it’s better to prepare the simplest documentation at once. In particular, we needed to document what tokens are used in the components. At the same time, for some complex components, we also needed to describe how to work with them in Figma.

Basic documentation
Basic documentation

Component block template

With the emergence of additional documentation for each component, the need to somehow arrange everything together arose. Preparing a template that would be used to describe all the components was ideal.

Template description
Template description

The template later on became the basis for the component documentation in Figma and allowed us to combine the description for both developers and designers.

Example of several components sets
Example of several components sets

For the template, we also created a special set of components that were used exclusively for documentation.

Components for documentation
Components for documentation

Restructuring the library

We added more and more components to the library until we started running into issues related to performance: with so many components on one screen, Figma rendered with significant delay. The solution was to split the library into separate pages and restructure the content.

Library pages
Library pages

Release. Releases.

After we added all the main components to the library and having finally published it, it was necessary to keep track of all the changes.

Figma has a basic system for dealing with library updates: if you use components or styles from a library when it is updated, you will receive a notification every time a change to a library has been published.

Component update notification
Component update notification

You can always opt out of updates if you are working on some concepts and you do not care about reviewing changes. But if you do want to keep your designs up to date with the latest modifications in the design system, it’s important to understand what exactly has changed and keep track of those changes. Figma also helps in this regard by showing details and allowing you to update exclusively the things you need.

Update dialog
Update dialog

In this dialogue, it becomes critical to have a system that allows designers to understand when and what has changed in the library. In our case, we borrowed the Semantic Versioning system from the developers for this purpose: Given a version number MAJOR.MINOR.PATCH:

  • MAJOR version when we make incompatible changes,
  • MINOR version when we add functionality in a backwards-compatible manner, and
  • PATCH version when we make backwards-compatible bug fixes.

In the library file, we have a separate page where we keep a log of all edits - Releases.

Releases
Releases

Stage two

After the release, it became important to start tracking how designers use the library and to test components in real-life situations. When it comes to tracking usage, Figma offers great built-in tools, like analytics. They include information starting from the projects or files in which certain components are used, to “unofficial dissatisfaction statistics”, i.e. how many times this or that component was detached. Detachment often shows that something is wrong, or perhaps the designer is missing a certain functionality in the component.

Library statistics
Library statistics

But the best way to understand what works and what doesn’t is to use the components in your daily work. When the creators of the design system use the components in their work on a regular basis, they can understand the problems that arise a little more broadly and perhaps see the solution in the system.

Introducing token design in development

Initially, the decision to transfer the library to tokens was dictated in many respects by the desire to be closer to development. The developers helped tremendously to deal with what they had in the code. However, at the first stage, tokens worked only within the Figma library.

With the design library already finished, it was easier to start a full-fledged conversation about migrating code to tokens.

Reviewing the token naming convention

To start with, we analysed our token structure together with the developers and made small changes to the naming convention. Largely for the greater convenience of “coding”.

Naming convention review
Naming convention review

Additionally, some adjustments were proposed to simplify the overall structure. So we needed not only to rename the tokens, but also to restructure them a bit.

Restructuring color tokens

During refactoring, the colours used in the tokens were also analysed. This made it possible to identify inconsistencies. This could have been done at the beginning, but without having a token structure ready, such errors would have been harder to spot.

Examples of inconsistencies
Examples of inconsistencies

Code migration

The colours were the first to start with during code migration. Thanks to the fact that the Figma tokens plugin stores everything in a regular JSON format, it was enough for us to pass the code to the developers. With minor modifications, all we had to do was to send the code to the developers.

Tokens in Figma and code
Tokens in Figma and code

As a pilot project, it was decided to transfer one component to tokens — the Button.

Button component code with tokens
Button component code with tokens

Contribution

Wave is currently supported in code and design by a small group of people. Ideally, the design system should be OpenSource and, at least within the company, everyone should be able to contribute. And for this, we created a special section in our library “ReadMe and HowTo”, which describes the basic information and also briefly explains how someone can make changes to the library.

Also, every two weeks we hold an open Wave-sync that anyone can join: to ask a question directly, make a suggestion or just to be in the know.

Feedback sessions are held regularly for designers to understand what works and what doesn’t, and in what direction we should be going.

ReadMe and HowTo
ReadMe and HowTo

Future plans

The migration of the Wave library into Figma has taught us a lot. There are probably some things we would have done differently now, but overall the original plan worked as intended.

We have a big backlog and, in general, big plans for the future:

  • New brand colours. During the migration (not only Wave but all 3 libraries) we realised that our basic colours need to be improved: some colours are missing and some require adjustments. Although, thanks to the fact that all the colours in Wave are now based on the tokens, the transition to any new base colours will not be a big problem.
  • Migrating all components in the code to tokens, the most time-consuming part.
  • Polishing the texts in the documentation. Initially, all of the documentation was written by the designers without the involvement of our content team, because we had to first understand what we needed and how we needed it. Now that most of it is ready, we work with the content team to improve all the texts.
  • Publishing the Wave Figma library. Our library of components in the code is already published, but to make it complete we need to make the design library public too.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store