что такое дизайн-система, отличие от UI Kit
В прошлой статье я обещала разобрать разницу между UI Kit и дизайн-системой подробнее. Там я сказала коротко: UI Kit – это часть дизайн-системы. Формально верно, но эта фраза почти ничего не объясняет. Давай попробуем разобрать, что такое дизайн-система, зачем она нужна и в какой момент UI Kit перестает справляться
→ Разница в одном предложении
UI Kit отвечает на вопрос «как это выглядит». Дизайн-система отвечает на вопрос «почему это выглядит именно так и что делать, если появился новый случай»
Вот и все. Дальше – детали, но держи эту мысль в голове, она объясняет почти любой спор на эту тему
UI Kit можно открыть и увидеть: вот кнопка, вот инпут, вот палитра. Дизайн-систему целиком увидеть нельзя, потому что половина ее живет не в макете, а в документации, договоренностях команды и коде
→ Из чего собирается дизайн-система?
Мне удобно думать про нее как про четыре слоя торта. Каждый следующий опирается на предыдущий
Токены. Именованные значения: цвета, размеры шрифтов, отступы, радиусы, тени. Не #2F6BFF, а color/primary/500
Компоненты и код. То, что обычно и называют UI Kit: кнопки, поля, карточки, модалки. Собранные из токенов, а не из случайных значений, которые перенесены в код
Правила и паттерны. Когда использовать основную кнопку, а когда второстепенную. Как выглядит форма с ошибкой. Куда ставится кнопка отмены. Это то, что обычно живет в голове у дизайнерки и уходит из проекта вместе с ней
Документация и процесс. Кто добавляет новый компонент. Как проходит согласование. Что делать, если нужного элемента нет. Важная часть, без которой система разваливается за полгода
Первые два слоя – это макет. Вторые два – это работа с людьми. Поэтому дизайн-система – не файл, а продукт, у которого есть свои юзеры: другие дизайнерки и разработчики
→ Токены – то, ради чего все затевается
Если из всей статьи ты запомнишь один термин, пусть это будут токены
Токен – это переменная с именем. Вместо того чтобы вбивать цвет #2F6BFF в двадцати местах, ты один раз называешь его color/primary/500 и дальше везде используешь имя. Меняешь значение в одном месте – меняется во всех двадцати
Звучит как мелкая техническая деталь, но именно тут проходит граница между «красиво собрано» и «работает годами»
Обычно токены делят на три уровня:
- Примитивы – сырые значения. blue/500 = #2F6BFF. Просто палитра, без смысла
- Семантические – значения с назначением. Color/action/primary = blue/500. Теперь понятно, для чего этот синий
- Компонентные – значения для конкретного элемента. button/background/default = color/action/primary
Выглядит как лишняя бюрократия, пока не приходит задача «нам нужна темная тема» или «мы меняем брендовый цвет». С токенами эта таска ускоряется в разы. Без токенов – ручной обход всех макетов и разговор с разработчиками в духе «а где еще этот синий встречается, я не помню»
В Figma токены живут в переменных (Variables). Если ты уже пользуешься стилями цвета и текста – ты сделала первый шаг к токенам, просто пока в упрощенном виде
→ Когда UI Kit хватает, а когда уже нет?
Далеко не каждому проекту нужна дизайн-система. Это важно, потому что вокруг много текстов, где дизайн-систему подают как обязательную ступень зрелости. Пу-пу-пу
UI Kit хватает, если ты одна на проекте, продукт небольшой, платформа одна и меняется он редко. Строить систему тут – потратить месяц на подготовку ради проекта, который живет три месяца. Также ДС – это живой организм, который нельзя сделать и забросить
Дизайн-система нужна, когда:
- Над продуктом работает больше одной дизайнерки
- Продукт живет на нескольких платформах или в нескольких сервисах
- Есть темная тема, несколько брендов или белые лейблы
- Разработчики собирают компоненты в коде и им нужен общий язык с макетами
- Продукт живет годами и его периодически переделывают
В моем опыте в продуктовой команде это выглядело так: несколько логистических сервисов, у каждого своя команда, но интерфейсы должны выглядеть и вести себя одинаково. Без общих токенов и правил каждый сервис за полгода уехал бы в свою сторону. Не потому что кто-то плохо работает, а потому что без записанных договоренностей каждый решает по-своему – и каждый по-своему прав
→ Как понять, что твой UI Kit перерос себя?
Несколько честных признаков. Если узнала себя в двух-трех – пора думать про токены и правила
- В файле три похожих оттенка серого, и никто не помнит, чем они отличаются
- Разработчица спрашивает «а какой тут отступ» чаще, чем раз в день
- Задача «сделать темную тему» звучит как «перерисовать все с нуля»
- Новая дизайнерка на проекте делает по-своему, потому что правила нигде не записаны
- Ты сама не уверена, какую кнопку использовать в новом сценарии, и решаешь на глаз
Последний пункт – самый показательный. Если авторка макетов не может ответить на вопрос по своим же правилам, значит правил нет. Есть привычки и «на глазок»
→ Что с этим делать?
Не надо садиться и строить дизайн-систему целиком. Это классический способ потратить месяцы впустую
Начни с малого, прямо в том UI Kit, который у тебя уже есть:
- Переведи цвета в переменные. Сначала примитивы, потом добавь семантический слой
- Переведи типографику в переменные и стили. Заголовки, основной текст, подписи
- Зафиксируй шаг отступов. Например, кратно 4 или 8. Одно решение, которое снимает половину вопросов от разработчиков
- Заведи одну страницу с правилами. Буквально текстом: когда какая кнопка, что делаем с ошибками, куда ставим кнопку отмены
Это далеко не дизайн-система в полном смысле, но это уже системный UI Kit, а не набор элементов. Дальше он достраивается по мере того, как продукт этого требует
Главное – понимать, какую задачу ты решаешь, а не собирать структуру ради структуры
В следующей статье разберем токены отдельно и на конкретном примере: как выглядит переход от палитры к семантическим переменным в реальном файле
01.08.2026
от хаоса к системе
если не можешь выбрать модуль, пройди короткий тест