Figma tokens automatically turned into code: how we kickstarted our design system

Part 4: Profits!

• Part 1: Down the rabbit hole
• Part 2: Using the Figma API
• Part 3: From Figma to our codebase
• Part 4: Profits! (you are here)

That wasn’t so hard! Even if it were, it’s definitely worth it. All that work is now the backbone of our “design system” and we profited from it quickly. From our color token library we made others: fonts, shadows, radiuses, sizes. We even extracted icons, illustrations and logos (which are more atoms than tokens, but never mind).

Now that our tokens are available and reliable, we consume them widely in our apps. The distribution as standalone SCSS stylesheets made it very efficient.

We’ve had plenty of chances to see how reliable our Figma extraction was. Designers have changed hues, added colors, renamed variables as the need arose and they did not need the engineers’ help to do so.

In turn, we consume those tokens and update our codebase often in an automated way. The first library took us a week or two to cook up. The other ones took us very little time as we only had to replicate our code and adapt it to fit the specific needs.

For icons we have a different pipeline to host our extracted `svg` files on a server and fetch them at runtime. This took us a bit more time to build but this is another story. We now have almost nothing to do to maintain these libraries.

The other perks are less direct and were not obvious to us when we started.

Automation calls for more automation

This pipeline also means the designers are now fully independent in handling tokens. Some changes can be completely transparent to developers. Others are more tedious and can break our code. At the beginning of our journey we only had the extraction pipeline but as time went by we added an automatic changelog, a notification when the build fails and when new versions are released. Since everything works without any manual action,we need to know when something happens, and what happened. Otherwise we could be left with a broken version for months without noticing.

We are now looking for an automated way to update our Design system components with the new versions of our tokens. Tokens will reach their full potential when everything is automated.

Communication

But more tooling doesn’t remove the need for communication. When there is such a strong contract between the designers’ and the developers’ toolset, communication becomes much more important. Automating design to code was a brand new way to work between our teams, as was a common design system. We did get into some back and forth on colors naming (and naming as a whole…). Before automation, some of the names had diverged between our two workspaces, but a common ground doesn’t allow for divergences. We needed to agree on the right shared vocabulary.

The very concept of automatic design to code handoff blurs the line between “them” and “us”. It supposes that there’s only one managing entity responsible for the shared concept of a token. This maybe was the greatest value extracted from this as it can be applied to many other aspects for the design system.

The next frontier

Our first experience with color tokens was so profitable that we kept going and extracted much more into standalone front-end libraries.

Some of these rely on Figma tokens, but others such as sizes are only conventions. Even if Figma has a limited range of tokens to its designer customers, we look at its API as a way to provide us all with more. We are still looking for other types of tokens which we could extract from Figma. We want to ensure that our design team has the means to “own” our product designs as directly as possible.

Figma’s API is of course only a part of that journey. Automation (such as automatically updating packages for non-breaking changes) is another, and we have yet to fully master it. We’re also continuously challenging our previous choices, arguing over semantic names and abstractions and finding the right balance between quantity and complexity.

It’s a journey. But it’s a very profitable one.