My name is Anastasia Kabalkina, I am the Head of Design at VK Tech. In this post, I will tell how we synchronized one third of our design system through automated generation of design tokens and components.
Our team develops financial and analytical b2b products — VK Tax Compliance, VK GRC, VK Data Symphony, VK Process Mining, etc. While supporting the products we have already released, we deploy about 10 product initiatives every year, so our product portfolio is growing very fast all the time.
This fast growth has its downside — it becomes ever more difficult and at the same time very important to control the interface quality and ensure consistency of UX/UI patterns.
Design and Frontend Misalignment
Just like most product development teams, several years ago we faced misalignment between design and frontend.
In our design system, many changes happen: new components are added from time to time, the already existing components are improved and developed further, while other components become obsolete — and for a number of reasons, not all of these changes are introduced into the frontend with 100% precision.
At some point, this misalignment became critical — almost every frontend's component differed from design to some extent.
Obviously, even the smallest inconsistencies, when taken as a whole, greatly distort the overall picture.
It may be a different color, a different indentation, corner radius, or size — and ultimately, in real life, we get the interface that doesn't look like the one on the layout.
Our attempts to align design and frontend with “traditional methods” didn't work out.
We failed to embed the design review stage in the development process, or to manually compare all components, or to find time for these activities during the sprint — we always handled other tasks that had higher priority for us.
On the other hand, we couldn't put up with this misalignment, either, as ultimately it made things worse for everybody — designers, developers, analysts, presale managers, testers, and, most importantly, users and business.
The Idea of Auto Generation of Styles and Components from the Figma File
What shall we do if we have work to complete, but don't have time for it? Automation is the only way out.
Of course, automation consumes resources, too, but mostly at the implementation stage. Then it starts saving much of your time and efforts and enhances the overall process efficiency.
We decided to automate export of styles and components from design to code and started looking for any tools that allowed to cope with this task, such as Figma plugins or standalone products.
We didn't find anything of the kind. But after we examined Figma's API, we understood that generally we could retrieve from it the information we needed and try generating styles and components by ourselves.
The overall workflow looks as follows:
- Taking data directly from the Figma file via API.
- Passing them through the hand-crafting code generator (hereinafter, Figma generator).
- Getting output, including design tokens of styles in css, json, ts formats (though any other format is available as well), svg icons and the code for react (javascript) components.
- Automatically placing the generated components to the storybook.
As the Figma file is the source of code generation, it must reflect all parameters of styles and components.
For this, we invented a specific format to manage Figma styles and parametrization of components that can be used for generation and doesn’t conflict with generally accepted design system approaches.
Managing the Figma File for Style Auto Generation
Text styles, colors and effects are managed by a standard method via Local styles (Text styles, Color styles, Effect styles) and are generated as is without additional settings.
To generate styles you can’t manage via Local styles (in our case, these are border, borderRadius, spacing and iconSize*), we create special components. Every component is assigned a style name and the parameters this style delivers.
For example, to generate the border style, the solution creates a component with the style name (let’s say, default, fieldBorder, imageBorder or any other at the designer’s or frontend developer’s discretion) and assigned Stroke color and Stroke width parameters. If there are several border styles, a separate component is created for every style.
* The code for style generation had been written before Variables appeared. Now we plan to elaborate this aspect of the Figma generator to generate styles both from Local styles, and Variables.
Managing the Figma File for Auto Generation of Components
Component generation is a more complicated and wide-ranging task, as components have multiple characteristics that must be imported to and correctly handled by the Figma generator.
These are several examples of such characteristics:
- variants that differ from each other by combinations of parameters,
- pseudo-states (pseudo-classes) that determine component styles depending on the state of the component (hover, focus, active, checked),
- components can contain other components (for example, icon components inside the button),
- components can be configurable (for example, an icon inside the button can be visible or not, and can be placed on the right and/or on the left),
- components can contain a text (for example, label of the button, checkbox or radio button), and a shape or a curve (for example, a check mark inside the checkbox or a circle inside the radio button).
To generate the component correctly, the Figma generator should get all the above information from the Figma file, and use it to generate the react (javascript) code of the component. For this, we developed a plain technique of Figma layout and parametrization of components based on the Auto layout and Properties functions.
All our components are arranged with the Auto layout function. We use:
- Horizontal gap between items, Horizontal and Vertical padding parameters to set paddings and internal indentations,
- Min width, Max width, Min height and Max height parameters to determine limits of the component width and height,
- the Truncate text parameter to enable “cutting” the text that doesn’t fit in,
- the Max lines parameter to set the allowable number of lines in the text container.
Besides, we export to the frontend a type of the component behavior using the Horizontal and Vertical resizing parameters (they determine, if the component size depends on its content (hug), or the component will take the entire space allocated to it (fill)).
The Examples of Managing Properties
To manage properties with multiple values (for example, the size property with xs, s, m, l values), we use the Variant property function. The properties that accept true/false values, for example, disabled, isNegative, isLoading etc. are specified the same way.
Pseudo-states (pseudo-classes) are also specified through the Variant property, and accept true/false values, while names of these states additionally include a colon to help the Figma generator differentiate these properties from others (for example, :hover, :focus, :active).
We manage Boolean properties in the standard manner with the Boolean function (for example, showIconLeft, showFirstButton properties etc.), while to insert a component in another component, we set the Instance swap property parameter to the insert areas.
If a component contains the text container, such container is assigned the Text parameter named Children so that the frontend could “add” any text to the component.
Achievements and Constraints of the Component Auto Generation
In less than one year, we learned to generate 18 components — and each generation was a kind of challenge.
Nevertheless, we have managed to:
- export all main parameters of the components to the frontend,
- generate fully-fledged components with the adequate code written as competently as if it were written by a highly qualified developer,
- generate components that support connectivity to third-party libraries (for example, we generate the title component, but the tooltip component that appears when hovering over the “i” icon is the AntDesign component that is enabled automatically).
The generation has its own constraints, though. Thus, there are components that can’t be generated, mostly because it’s just not feasible — the cost of writing the code for the generator will be too high and will never pay off (it’s much easier to take the tested select component with the elaborate logic from the open-source library than to write this component generator from scratch).
Besides, so far we didn’t manage to export animation parameters from Figma and to invent how to generate the components accepting any number of other components.
And probably the most important constraint is that the Figma generator obtains data via API that’s beyond our control. Therefore, changes of or restricted access to API can make it necessary to further develop the generator or to completely abandon the idea of generating components this way. And who knows what the Dev Mode of the Figma’s next upgrade will offer?)
The Output we’ve Got
Though we didn’t manage to generate the entire design system, we’ve got a fully generated style library and a set of automatically generated components that come up to about 30% of all components of our design system.
What does it mean for us?
It means that we have 100% synchronized one third of our design system, and since synchronization is done automatically, we don’t have to waste resources on design review of at least this portion of the system.
We can improve the generated components and enrich them with variants, and then deliver them to the frontend just in minutes.
We can adjust styles of interfaces (change colors, fonts, corner radius, etc.) on the fly.
We have the foundation for further experiments as we can keep on improving our Figma generator.
But, most importantly, we (and hopefully you as well) are now sure that designers and frontend developers, who work and professionally grow together, are able to solve the most unusual tasks!
This post described the designer part of the process. Read about details of the code generation in another article that will be coming soon!
Contacts and Acknowledgements
Thanks to the team for an interesting internal project, for their bravery and support, for unique experience and assistance when we wrote this article!
If you have ideas and suggestions, please share them in your comments to the post!
