How we set up the FREE NOW Wave Component Library in Figma
Taking a design library to the next level with Figma & tokens
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.
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.
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.
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.
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.
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:
- A comprehensive toolkit for developing plugins and widgets for Figma and FigJam
- Figma Developers
- Figma DIY: Building a colour system plugin
- etc.
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.
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.
As an example, Button and Input field looked like this:
It was also necessary to take into account what variables existed in the code already and what could eventually become a design token.
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.
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.
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.
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
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.
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.
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.
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.
For the template, we also created a special set of components that were used exclusively 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.
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.
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.
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.
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.
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”.
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.
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.
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.
As a pilot project, it was decided to transfer one component to tokens — the Button.
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.
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.
