On the Feasibility of Automating Design and Development – Our Lessons from Building the Veera Design System

Design Tokens are the smallest reusable parts of a design system. They convey information such as:

This information is typically presented in a machine-readable format - JSON. This makes the whole solution front-end agnostic, meaning it can be integrated with different frameworks (React, Angular, Vue, etc.).

The issue of obtaining Design Tokens is not new to us. We have previously tested such solutions in-house - they worked, but were very sensitive and error-prone. These would not be suitable for a national design system.

There are also third-party solutions available in the market, such as Tokens Studio. This would solve the problem but would bring ongoing licensing costs, which was not in line with the project requirements.

Fortunately, the project's start coincided with Figma's annual conference, FigConf, where new functionalities are announced. At this conference, the Variables functionality was announced, and it was the answer to our prayers. With Variables, it is possible to create a Design Tokens system using Figma's built-in solutions. Although this is a beta solution and not everything is as ready as it could be, we decided to formalize all design decisions using variables.

By the end of the project, we had a system with 976 design tokens, comprising 116 primitive and 851 semantic tokens.

We decided to continue in the version 1.0 file with the approach that components are consolidated on one page. This allows users of Figma's free plan to use the Veera file. We defined the different sizes and interaction states for each component. We set the target that if something was possible in HTML/CSS, then designs would depict what it should look like.

Veera's primary target audience is creators of e-services. Consequently, design decisions are made in such a way that they facilitate the creation of information-dense screen views.

For example, H1 headlines are only 1.75 times larger than the body text. For presenting slogans, we defined both large and expressive headlines separately. Components are predominantly available in three sizes:

We decided to simplify the previous system for colours. The new palette consists of 6 colours, each with 10 shades (the pre-alpha offered 20 shades). In addition to the base palette, 3 transparent colours are used. A smaller palette helps maintain a unified style but still provides enough freedom to create unique solutions. The tones of all colours are derived algorithmically from the respective 600 shades of the colour. Some tones have been manually adjusted to increase the number of color combinations that meet contrast requirements.

In creating the dark mode, we also based it on the base palette colors. In most cases, it was sufficient to divide the base palette tones conceptually in two – 5 light tones and 5 dark tones – and replace the light color with its counterpart in the split palette. Figma's variables solution was a great help in the technical implementation. It allows defining different states for variables. Veera now had two: Light mode and Dark mode.
Now, when switching the design to dark mode, the light color is replaced with the dark color, and vice versa.

The biggest challenge in creating components turned out to be the naming of Design Tokens. After some experimentation, the following pattern began to emerge:

Component:

This pattern had to be applied to each component. Generally, the components are divided into 45 different categories. In total, approximately 104 larger or smaller Figma components were created. Many components also have several variations, each with at least five interaction states. This easily illustrates how the number of necessary design decisions grows.

The "aha moment" in designing components came when, in a discussion with developers, the following was suggested: that once tokens are agreed upon and set, then from there on their values can be iterated as much as needed. This was a clear indication that we had reached a point in our process where the transfer of design decisions to development was automated, provided that the tokens existed and their naming did not change.

Since Figma is primarily a domain for designers, in the Veera 1.0 project, designers handled the development of tokens. This was a new challenge for many and required a period of adjustment. After hours of work, the result was “an Excel table with some variables,” not the visual design that designers are usually accustomed to. Certainly, the immaturity of Figma's variables management interface complicated the process. To date, it's relatively difficult to find the definition of a specific component’s token.

To modify any Design Token, the following steps are necessary:

Hopefully, Figma will make processing variables more convenient soon, such as by searching by name. Our designers used a workflow where the same work file was open in two windows - one was the main work file, and the other simply displayed the variables panel. This made life somewhat easier.

Despite all the challenges, using the variables solution was the right decision, as it allowed us to much more quickly hand off design decisions to development.