Дизайн-система в коде: как не превратить UI в хаос

Дизайн-система — это не макет в Figma и не страница с цветовыми кружками, которую дизайнер прислал раз и забыл. Для разработчика это прежде всего код: набор переменных, компонентов и договорённостей, через которые интерфейс собирается из одних и тех же кирпичиков, а не пишется заново на каждой странице. Если спросить команду, где именно живёт дизайн-система проекта, и услышать «в Figma» — это уже тревожный симптом: значит, код и дизайн расходятся где-то между макетом и реализацией.

Боль без дизайн-системы знакома любому, кто работал над проектом дольше полугода: в одном месте кнопка со скруглением 8px, в другом — 6px, потому что копировали из разных мест. Три оттенка «того же самого» синего цвета в разных компонентах, потому что никто не сверялся с палитрой. Отступ между карточками то 16px, то 20px — просто потому что так получилось. По отдельности каждая мелочь не критична, но их сумма — это продукт, который выглядит так, будто его делали разные команды, даже если писал его один и тот же человек в разное время.

Там, где проект дорастает до того, что такую дисциплину уже не удержать на глаз, разумно подключить профильную команду UI/UX-дизайна — например, команду дизайна интерфейсов в YuSMP Group, которая выстраивает визуальную систему так, чтобы она прижилась в реальном коде, а не осталась красивым макетом без шансов на внедрение.

Зачем дизайн-система нужна именно разработчику

Дизайн-систему обычно преподносят как инструмент дизайнера, но её главный выгодоприобретатель в ежедневной работе — разработчик. Первый эффект — скорость ревью: когда в проекте есть готовый компонент кнопки с состояниями hover, focus и disabled, ревьюеру не нужно разбирать очередную самописную реализацию с нуля и спорить, правильно ли обработан фокус для клавиатурной навигации — достаточно проверить, что использован существующий компонент.

Второй эффект — меньше дублирующегося CSS. Без общих токенов и компонентов каждая новая страница тянет за собой собственный набор стилей, частично повторяющий уже написанные где-то рядом. Через год в проекте накапливаются десятки почти одинаковых классов для кнопок и карточек, и никто уже не рискует удалить ни один из них — вдруг он используется где-то, что не попало в беглый поиск по проекту.

Что ломается первым без дизайн-системы

Симптомы предсказуемы и повторяются от проекта к проекту. Отступы между однотипными блоками расходятся на несколько пикселей — незаметно по отдельности, но бросается в глаза при сравнении двух соседних экранов. Кнопки с одинаковым визуальным смыслом ведут себя по-разному: где-то фокус обведён рамкой, где-то — нет, потому что стили писались в разное время разными людьми без общего эталона.

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

Токены — единый источник правды для цвета, типографики и отступов

Токен — это именованное значение дизайн-решения: цвет, отступ, радиус скругления, размер шрифта. В коде токены обычно живут как CSS custom properties (--color-primary-600) или SCSS-переменные, которые подставляются везде, где раньше были захардкоженные значения. Технология вторична — важен сам принцип: значение определено один раз, а используется в десятках мест через ссылку, а не копипастой.

:root {
  --color-primary-600: #2a5ea8;
  --space-md: 16px;
  --radius-control: 8px;
  --font-size-body: 15px;
}

.btn {
  background: var(--color-primary-600);
  padding: var(--space-md);
  border-radius: var(--radius-control);
}

Частая ошибка на стыке дизайна и разработки — токены существуют в Figma как стили, но в код их переносят вручную, глазами, один раз при вёрстке. Дальше дизайнер меняет значение в макете, а разработчик об этом не узнаёт — и расхождение копится незаметно, пока кто-то не сравнит экран с макетом напрямую. Решает это не дисциплина «не забывать», а механика: токены описываются в одном файле (JSON или YAML), из которого синхронизированно генерируются и переменные в коде, и стили в дизайн-инструменте — тогда рассинхрон технически невозможен, а не просто маловероятен. Формат такого файла необязательно изобретать с нуля — есть открытая спецификация Design Tokens Community Group, которую уже поддерживают многие инструменты синхронизации дизайна и кода.

Компонентная библиотека: от атомов к готовым блокам

Не каждый кусок разметки заслуживает звания «компонент». Разовая вёрстка — это блок, который используется один раз на конкретной странице и вряд ли повторится: его не нужно выносить в библиотеку и документировать, это лишняя работа без будущей выгоды. Компонентом стоит считать то, что реально переиспользуется — кнопку, поле ввода, карточку, бейдж статуса — и для чего полезно зафиксировать состояния (hover, disabled, loading) и варианты (размер, цвет, иконка) в одном месте.

Удобный ориентир — принцип atomic design: атомы (кнопка, иконка, поле) собираются в молекулы (строка поиска с иконкой и кнопкой), молекулы — в организмы (форма логина, карточка товара). Его не обязательно соблюдать буквально по терминологии, но сама идея — не проектировать сложные блоки раньше простых — помогает не начинать компонентную библиотеку сразу с десятка специфичных composite-компонентов, которые сложно переиспользовать.

Документация, которую реально открывают

PDF-гайд по дизайн-системе, который лежит в облачном диске отдельно от репозитория, открывают один раз — при знакомстве с проектом, и больше никогда, потому что искать его неудобнее, чем написать новый CSS-класс с нуля. Документация, которая реально работает, лежит рядом с кодом компонентов: это может быть Storybook с живыми примерами и описанием props, MDX-файл в том же каталоге, что и сам компонент, или просто страница в самом приложении со списком всех доступных вариантов.

Ключевое требование — не полнота, а доступность в момент, когда разработчик уже пишет код и ему нужно быстро понять, есть ли готовый компонент под задачу. Документация, до которой нужно идти в другой инструмент и искать по неочевидному названию, проигрывает конкуренцию с «проще написать своё» — даже если формально она полная и актуальная.

Процесс: кто и когда правит дизайн-систему

У дизайн-системы должен быть явный владелец токенов и базовых компонентов — не обязательно отдельный человек на полной ставке, но конкретная роль, к которой идут с вопросом «можно ли завести новый оттенок цвета» вместо того, чтобы завести его самостоятельно и никому не сказать. Без этого правила дизайн-система быстро обрастает исключениями, которые со временем становятся новой нормой, и система перестаёт быть системой.

Изменения базовых компонентов — отдельная категория pull request, которая заслуживает более внимательного ревью, чем обычная фича: правка в общей кнопке затрагивает все страницы, где она используется, а не одну конкретную. Перед релизом такие изменения стоит прогонять через визуальное регресс-тестирование — инструмент делает скриншоты компонентов до и после изменения и показывает разницу пиксель в пиксель, что ловит именно те поломки интерфейса, которые функциональные тесты не замечают: цвет отличается на соседний из палитры, а функция работает штатно.

Если дизайн-системе пора вырасти за рамки самодельного UI-кита

Пока в проекте десяток компонентов и работает над ним небольшая команда, самодельного набора токенов и правил обычно достаточно. Но когда компонентов становится несколько десятков, подключаются новые разработчики без контекста по истории решений, а продукт выходит на несколько платформ с разным визуальным языком — самодельная система начинает требовать ресурсов, которых у команды разработки обычно нет: выстроить консистентную визуальную иерархию, продумать расширяемую палитру под будущие продукты, формализовать принципы, а не латать их по мере возникновения проблем. Это тот момент, когда разумно не продолжать тянуть систему силами команды, а передать визуальную часть профильной команде — сохранив при этом всю инженерную дисциплину вокруг токенов и компонентов, которая разобрана выше.