Каждый дизайнер хотя бы раз в жизни открывал Figma Variables чужого проекта и переживал existential crisis. Где-то там рядом с red-1-final-new, gray_main_2_copy и button-blue-maybe лежала судьба дизайн-системы.

Каждый дизайнер видит структуру токенов по-своему, и поэтому разбирать чужую дизайн-систему довольно сложно.

У кого-то токены живут по уровням.
У кого-то по темам.
У третьих всё перемешано: цвета, состояния, компоненты, темы — всё в одной папке.

Например, есть ДС, где в одной коллекции живут сразу surface-1, fill-3, border-1, disabled, а рядом — 200+ токенов с цветами вроде colors/alpha/light/900 или colors/pink/300.
Всё работает, но понять почему это именно так — задача со звёздочкой.

Может работать если ты работаешь один и не планируется масштабирование ДС.

Зачем вообще нужны уровни?

Потому что токены — это язык, на котором говорят дизайнеры и разработка.

При удобном устройстве переменных, мы можем переиспользовать цвета/отступы/скругления и пр.; быстро переключать темы; масштабировать систему без долгого разбора ДС и помощи дизайнера, который ее создавал.

Уровень 1 — Примитивы

Коллекция: Primitives
Содержит: цвета (hex), opacity, числовые размеры.

color/white/100  → FFFFFF 4%
color/white/200  → FFFFFF 8%
color/black/300  → 19191B 16%

dimension/1      → 4px
dimension/2      → 8px
dimension/5      → 20px

Так можно легко обновить цвет в одном месте (например, новый фирменный цвет — меняем один раз здесь).

Уровень 2 — Семантика

Коллекция: Color Modes / Semantic
Содержит: текстовые токены, фоновые, обводка, состояния и т. д.

Это слой, который знает, зачем цвет нужен:

text/neutral/primary

text/brand/primary

bg/neutral/default

surface/neutral/default

Семантика уже живёт в темах: Light / Dark.

Token                | Light            | Dark             |
-------------------- | ---------------- | ---------------- |
text/neutral/primary | color/gray/1500  | color/gray/100   |
text/on-bold         | color/white/1000 | color/black/1500 |
bg/brand/primary     | color/brand/700  | color/brand/400  |

• Компонент не знает, какой именно серый используется. Он знает, что нужен primary нейтральный текст.

• При переключении тем все компоненты автоматически подхватывают правильные цвета.

• Семантика — это словарь. Понятный и дизайнеру, и разработчику.

Плюс: мгновенная смена темы — никаких костылей в компонентах.
Минус: нужен строгий контроль нейминга, иначе семантика развалится.

Уровень 3 — Dimensions

Коллекция: Dimensions
Содержит: отступы, радиусы.

space/sm  → dimension/3
space/md  → dimension/4
radius/md → dimension/6

Уровень 4 — Типографика

Коллекция: Typography
Содержит: family, size, line-height, letter-spacing, weight, paragraph-spacing.

Так же, как и с цветовыми и числовыми примитивами, каждый параметр — это отдельный токен, а сами текстовые стили собираются из этих модулей, а не задаются вручную.

size/body-m         → 18px
size/caption-s      → 10px

line-height/h2      → 72 / 56
line-height/body-m  → 26

letter-spacing/display → -3.6
letter-spacing/caption → 0

А затем на базе этих примитивов формируются семантические стили:

text/body-m
    size           → size/body-m
    line-height    → line-height/body-m
    weight         → weight/400
    letter-spacing → letter-spacing/body

Такое разделение позволяет:

1) Избежать ручных стилей

Никаких “H2-который-чуть-поменьше” или “body-16-new”.

2) Легко масштабировать и поддерживать дизайн-систему

Если завтра меняется бренд-шрифт, размеры — корректируем только примитивы, а не полсотни текстовых стилей.

4) Сохранить консистентность во всех продуктах

Desktop, Mobile, Web — вся типографика связана общими токенами.

Как понять, что система работает правильно?

1. Компоненты не содержат HEX-кодов

2. Цветовые значения собраны в примитивах

3. Темы работают переключением одной коллекции

4. Семантика описывает смысл, а не цвет

Итого

Когда дизайн-система растёт, хаос без архитектуры — не вопрос «если», а вопрос «когда». Появляются дубли, странные названия, ручные правки и вечные вопросы в стиле: «почему этот цвет тут называется primary, а там — accent?»

В какой-то момент система перестаёт помогать и начинает мешать — и это самый надёжный сигнал, что архитектура не выдержала масштабирования.

Хорошо выстроенная структура токенов позволяет:

• экономить часы на рутинных действиях — и дизайнерам, и разработчикам;

• снижать количество правок при дизайн-ревью;

• легко ориентироваться в дизайн-системе;

• формировать единый язык, понятный и команде, и новым участникам проекта.

Но главное — устойчивость. Всё держится на логике и правилах, а значит, дизайн можно безопасно масштабировать, передавать между командами и адаптировать под новые продукты.