How the Avito design system library in Figma works
Avito manages a colossal number of interfaces and screens — about 1000 in its desktop and mobile apps. To make the user interfaces consistent and reliable and to be able to create them faster and easier, we have a design system.
At its most basic level, a design system is a collection of components and styles. Ours also includes guidelines, flows, and patterns for designers and specifications for developers. Our Figma library is maintained by the design system team. Its users are our product designers and developers. Here we are going to explain how the library works.
Design system library structure
Our design system in Figma has six sections:
- Intro for new employees.
- Work-in-progress files.
- Styles.
- Component libraries.
- Specifications for developers.
- Guidelines for designers.
Intro for new employees is a tutorial that helps one figure out the basics and settings. Here we briefly explain how to connect libraries, use components, prepare specifications, and present the design review process.
Work-in-progress stores internal projects and developments of the design system team. These are the current tasks that our team is working on.
Let’s take a closer look at the other sections of the library.
Styles
Avito has several platforms: web, mobile version of the website, and mobile apps. This is the most general division. There are separate styles for each platform.
Styles are the cornerstone of any product designer’s work. These consist of a pre-defined set of texts and colors that designers use in their work. When creating new layouts or modifying existing ones, one needs to plug a style file in Figma and add fonts and colors from the ready-made palette to the components. We never make random choices in our layouts: all projects should use approved styles.
Fonts for interface texts have their respective names, for example, Heading or Body, and a note about the size and line spacing. Text styles for the web and mobile are slightly different, with some elements smaller in the former case and larger in the latter. We store the colors as a light to dark ramp. These also have names, for example, blue50 or blue700.
For developers, the same sets and names are available in the code. The style names in the design system must coincide with those in the code. Otherwise, there is a risk that fixing inconsistencies will be time-consuming and expensive.
A style library helps you test hypotheses faster if you have a large team. For example, if we think that a specific set of text styles suits its purpose better than the existing one, it is worth testing it using layouts. Since several people can test a hypothesis, adding a test style to the library is easier than explaining to everyone what it looks like.
Component library
Like styles, layouts’ components should not be random; otherwise, different screens and products will not have a consistent look. Therefore, within the Avito design system, there is a ready-made library of components, which designers are free to copy into their projects. The same component library is available as code to developers — thus, we support the implementation and the possibility of end-to-end changes both in design and code.
Components are like bricks that we can use to build any structure. For example, page headers and footers, search filters, banners, maps, and side menus.
The design system’s common library stores:
- Components for the web.
- Components for mobile apps.
- Ready-to-use illustrations.
- A set of icons.
The colors are the same for the web and mobile, but the fonts and the set of elements are different. We have to distinguish between the two because people interact with a desktop and a smartphone in different ways. A button’s size may be smaller in the former case because the mouse or touchpad cursor is small, allowing to make exact clicks. A large button is more convenient on a mobile screen because the user uses her finger to tap the button.
There are also web-only and mobile-only components. For example, pop-ups perform better in web layouts, while bottom sheets are preferred in mobile layouts. We also have photo carousels for the web version, which are not available for the mobile.
Both out-of-the-box styles and out-of-the-box components are needed for quick end-to-end changes. On the design system side, one can change the color in style, and it will be updated in all components. If we make changes to the component, say, change the font size, the designers will be able to apply this change to their layouts quickly.
Working with the design system components
Avito has pre-defined patterns and solutions. We support and update these on the design system side. If necessary, we create new components: we can create a simple component or a complex one using a master component.
With simple new components, everything is more or less clear. We either have an order for a new component from the team or see the designers’ needs. We learn that a need exists from questions like “do we have this or that component? have you ever come across a solution like this?”.
But it also happens that an existing component has several implementations. We can see this in repetitions in layouts by different designers. Then we implement the component more sophisticated and start by working out the master component.
On the design system side, we go through designer layouts, check the production, and collect all the components’ alternative appearances into a single file inside Figma. Next, we analyze similar elements: these always exist. Let’s take a list item component as an example. The list item is always text and signature with some graphics. Next, we look at the differences: how the solutions differ and why designers created their own versions. We ask designers why they did something this way and not otherwise and what user problem they were trying to solve.
When all the necessary data is collected, we build a large master component with possible combinations of the component’s appearance. Of course, we share the alternatives with the designers and ask them for advice. Designers can suggest improvements and highlight problems. Inside Figma, the list item master component now looks like this:
A master component is the main component that contains all the necessary elements. Designers use it to make instances — these are child components. If you need to make an edit, it is done in the master: all child components will then be automatically updated.
If there are many instances and we need to specify their state, for example, highlighted or disabled, we use the variants in Figma. We combine the components into one and customize it.
We add the necessary elements in the component itself and make it possible to use it on different devices. From the technical point of view, we do everything to make the components in the design system library flexible.
For example, we set the auto layout to type any number of lines in the component’s text field. We set constraints so that when the component is resized, nothing becomes displaced or shrinks. Our goal is to give the designers a completely ready-to-use component so that they do not have to configure everything on their own every time.
When all the necessary configurations of the component states are set up, we place them on the artboard — a single Figma page with components for the web or mobile. In this way, after opening the file, the designer immediately sees the needed layout element and can grab it to use on the project page. Designers tend to look for things visually, and they want an expanded presentation of component states.
On the design system side, we carefully monitor the use of components in layouts. Designers don’t always use components correctly. If something is wrong, we note in the layout that a component needs to be replaced with something else, we discuss this at meetings or suggest re-reading the guideline.
Development can be a little tricky. It is not always that what a designer uses as a component remains a component for a design system developer. Some things are difficult to implement or difficult to maintain.
You need to talk to the team about which component you want to embed in the shared library and whether it will have support in the code. If yes — great; if not, then warn the designers about this because the development progress in other teams may not be as you expected. We decide whether or not to add a component to the code collectively.
The component in Figma and the code
Designers need a library in Figma to have a general idea of the available components and easy copy-pasting into their layouts. But for the layouts to be implementable, it is essential that each component exists in the code for all platforms and that all Avito development teams can easily access it. The design system developers are responsible for the code implementation of existing components.
Figma components are not mirrored in the code. For example, our input component in the code is a gray block and everything inside it: text, icons, and so on. For a developer, a title and a subheading are no longer an input, but a container component. In design, we call input both the gray block and the gray block with the title.
To avoid misunderstandings and make life easier for developers, we write specifications for the components.
Specifications for developers
Inside the Figma library, specifications are divided first by platform and then by individual components. The specifications describe the component’s technical features: its anatomy, indents, sizes, fonts, colors, behavior, animations. We try to think over and describe all possible use scenarios and states.
Here is a specification fragment for a list item component:
When the technical description is ready and approved by the development team, we set the task to develop the component. Each component undergoes a very rigorous and detailed design review.
The developers are preparing a full-fledged implementation of the component, which can be seen in a dedicated demo app. It is an app that can be downloaded on iOS and Android to test the component’s functionality: dimensions, element arrangement, highlighted, and everything described in the specifications.
It looks simple enough. In some cases, the component is presented with several variations or a preview of the component, followed by a set of settings applied to it. The demo app is needed not only for design reviews but also for Avito teams. It provides a clear understanding of what is currently available for use by our developers and designers.
When development is completed, we write a guideline for designers. The guideline contains information on when to use the component. When this is done, we inform the designers that a new component has become available both in the code and in the design, and it can be used in layouts. For this, both the design system and the developers have their own slack channels and joint meetings.
Not only design system developers but also other tech development teams need specifications. We do not always have time to make all the necessary components on our side. In this case, a developer from a different team can open the specification and produce the required component independently.
Guidelines for designers
Guidelines are detailed illustrated instructions for designers. These describe when to use which component, how to use it in a layout, how to animate it, what padding should be, and many other technical details.
We have guidelines for using components on different platforms, illustrations, icons, and mobile website version guidelines. Let’s take a quick look at what these look like using the mobile component bottom sheet as an illustration — a panel that emerges from the screen’s bottom.
The long and detailed bottom sheet guideline has seven sections:
- Which bottom sheet to choose depending on the situation.
- Bottom sheet height.
- Animation.
- Footer selection.
- Offsets from the screen edge and navigation elements.
- How and when to use buttons in a component.
- Don’ts.
In each section, there are real-life examples of using the bottom sheet component. It is much easier to look at a figure and read a short comment to it than read a long text. In general, this library section exists to ensure that the designer can find answers to all basic questions without contacting the design system team.
The guideline structure may differ depending on the component. If you need to make any patterns, you can describe the operating principle.
Contribution by other teams
Not only the design system team works on the design system. All Avito developers and designers contribute to this effort. A developer from a different unit can add a code component if he or she needs the component to achieve something. A designer can finalize the new component and create states for it. We then only need to make minor adjustments, e.g., add settings.
The design system team has its backlog with non-urgent tasks that need to be done in the future. Any Avito designer can come and take on a task from the shared backlog, such as making a pop-up description, creating a form based on a set of inputs, or multi-select rules. The design system itself may suggest a task if the designer comes with a question to which there is no ready answer.
From our experience, when a designer works out the rules, he or she is very picky when it comes to her proposals and layouts. The more people are involved in a design system, the better it works. This does not add any complications, but, on the contrary, it streamlines the process. This approach reduces the decision-making time and frees it up for something else.
Conclusions
A design system, like any product, requires constant development and flexibility. Building each component is a complete task; if done in haste, designers won’t use it. To avoid this, observe how designers use components and when they use them.
If a designer asks if she can use a particular component or replace a button in a component with another, ask what she wants to achieve before saying no. Perhaps the designer needs not this specific component and not this specific button to address her needs. Suggest a better solution, but first, figure out the problem and try to avoid harming.
The design system does not exist separately from the product, it is an integral part of the product.
Special thanks
Thanks to Inessa Voronina for the inspiration to write this article and for all our work on the design system library. And, of course, many thanks to the team for their help in implementing everything written in here.
