Дизайн-система для tutu.ru
Это обзорный кейс с рассказом о том, из чего состояла дизайн-система, без избыточных подробностей. Отдельно про интересные штуки опишу позже.
Как это устроено в Figma
Конечно, есть файл с компонентами. Помимо этого:
- Docs — подробная документация, где описываем лейауты и логику работы компонентов
- Patterns — куски флоу и логики, о которых договаривались с продуктовыми командами
- Icons & images — иконки и графический контент (например, логотипы и флаги стран)
- Mail kit — усеченный по компонентам набор для email-рассылок, при этом он использует те же дизайн-токены.
С чего начать?
Уже классика в моих проектах. Это страница с главными ссылками и информацией о продукте: кто дизайнеры, какое покрытие компонентами, какие библиотеки нужны для работы и где они находятся. Плюс витрина компонентов: если пользователь не знает название нужного компонента, он может найти его визуально и перейти на нужную страницу.
Дизайн-токены
Дизайн-токены в виде JSON-файла на GitHub мы доставляли через Tokens Studio в Figma. В библиотеку компонентов на Stash — вручную, так как тогда у Tokens Studio еще не было поддержки (сейчас уже есть). При этом в iOS и Android токены передавались автоматически.
Автоматизированный процесс передачи токенов нам сэкономил много времени, как можно увидеть, дизайн-токенов было много:)
Для цветов мы использовали довольно хитрую систему зависимостей для семантических и компонентных токенов. Вручную таким управлять почти нереально.
Все эти токены нужны для работы модов. Например: смена бренда и светлой/темной темы.
Или смена контрастности элемента.
Конечно, есть и примитивы, и мы всегда знаем, на какие примитивы ссылаются наши семантические токены (обозначены иконками). У нас светлая и темная темы задаются на уровне примитивов, поэтому, чтобы не подбирать каждый раз, какой цвет использовать в темной теме, при создании компонента мы просто назначаем цвет из светлой темы и получаем адекватный вариант в темной.
Для темной темы рассчитаны только те цвета, которые используются, для экономии времени.
Процессы
Дизайн-система — это не только компоненты и токены, но и процессы, люди, договоренности. В Tutu дизайнеров было около 30 и х2-х3 разработчиков, и со всеми на разных этапах нужно было договариваться, а часто и продавать дизайн-систему через удобство, без административного ресурса. Для каждого решения у нас был этап discovery: мы обсуждали его результат с другими дизайнерами ДС, затем презентовали его дизайнерам продуктов, продавали решение, выставляли на голосование, если было несколько вариантов, показывали разработке и ревьюили результат разработки.
Компоненты
Kite — это более 60 компонентов и система модов, которая позволяет менять тему, бренд, контрастность и адаптив.
Design system for tutu.ru
This is an overview case with a story of what the design system consisted of, without too many extra details. I will describe separate interesting parts in more detail later.
How it is organized in Figma
Of course, there is a component file. Besides that:
- Docs — detailed documentation with layouts and component behavior
- Patterns — flow and logic chunks aligned with product teams
- Icons & images — icons and visual assets (for example logos and country flags)
- Mail kit — a reduced component kit for email, still based on the same design tokens.
Where to start?
A classic pattern in my projects. This page contains key links and product information: who owns design, component coverage, what libraries are needed, and where they are located. It also has a component showcase, so if a user does not know a component name, they can find it visually and jump to the right page.
Design tokens
Design tokens as a JSON file on GitHub were delivered via Tokens Studio into Figma. Into the component library in Stash, we delivered them manually at that time because Tokens Studio did not support that flow yet (it does now). For iOS and Android, token delivery was automated.
The automated token delivery process saved us a lot of time. As you can see, there were many design tokens.
For colors, we used a rather complex dependency model for semantic and component tokens. Managing this manually would be unrealistic.
All these tokens are needed for mode support. For example: switching brand and light/dark theme.
Or switching element contrast.
Of course, there are primitives as well, and we always know which primitives our semantic tokens reference (marked with icons). In our setup, light and dark themes are defined at the primitive level, so to avoid manually picking a dark-theme color every time, we assign a light-theme color when creating a component and get a valid dark-theme variant automatically.
For the dark theme, only the colors that are actually used were computed, to save time.
Processes
A design system is not only components and tokens, but also processes, people, and agreements. At Tutu, there were around 30 designers and x2-x3 developers, and at different stages we had to align with everyone — and often sell the design system through convenience, without administrative pressure. For every solution, we had a discovery stage: we discussed results with other DS designers, then presented to product designers, sold the solution, put it to a vote when there were multiple options, showed it to engineering, and reviewed the implementation result.
Components
Kite is more than 60 components and a modes system that allows switching theme, brand, contrast, and adaptive behavior.