Как я собираю дизайн-систему продукта: 5 принципов, которые работают

Дизайн-система — это не набор красивых компонентов в Figma и не «UI-kit?Набор готовых элементов интерфейса — кнопок, полей, карточек. Часто путают с дизайн-системой, хотя это лишь её часть. на 400 слоёв». Это свод правил, по которым продуктовая команда принимает решения. Хорошая система экономит месяцы разработки и снимает половину споров на ревью. Плохая — превращается в мёртвый репозиторий, которым никто не пользуется.

За последние годы я собирал дизайн-системы для маркетплейсов, финтех-сервисов и B2B-платформ. Ниже — пять принципов, которые я применяю в каждом проекте и которые реально влияют на результат.

Когда дизайн-система не нужна

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

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

Почему я начинаю не с компонентов

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

Если на этом уровне нет системы, компоненты получатся несогласованными: одна кнопка будет иметь радиус 8, другая 10, третья 12 — и никто не сможет объяснить почему.

Принцип 1. Токены важнее компонентов

Токены?Переменные дизайн-системы: цвета, размеры, радиусы, тени. Хранятся в Figma Variables или в коде — и меняются в одном месте, а не в сотне макетов. — это переменные дизайн-системы. Цвета, размеры, радиусы, тени, отступы. Всё, что повторяется в интерфейсе, должно быть вынесено в токен.

Я делю токены на три уровня:

• Примитивы — сырые значения: blue-500, gray-100, space-4.
• Семантика?Токен, который описывает роль, а не значение. color-text-primary — это семантика: он может указывать на чёрный в светлой теме и на белый в тёмной. — то, как они используются: color-text-primary, color-bg-surface, color-border-subtle.
• Компонентные — локальные значения для конкретного компонента: button-primary-bg, input-border-focus.

Когда у продукта появляется тёмная тема, брендовая тема или тема для партнёров — вы просто подменяете семантику, а не перерисовываете сотни экранов.

Компонент без токенов — это макет. Компонент на токенах — это инструмент.

Принцип 2. Сначала правило, потом компонент

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

Например, у нас есть четыре варианта кнопки. Прежде чем рисовать, мы договариваемся:

• Primary — одно действие на экране.
• Secondary — альтернативное действие.
• Ghost — третичное действие в плотных интерфейсах.
• Danger — необратимое действие.

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

Как это выглядит на практике

Когда правило зафиксировано, компонент становится очевидным. У нас появляется по одной кнопке с чёткими вариациями размера и состояния. Разработчик видит пропсы?Параметры компонента в коде: размер, вариант, состояние. Через них разработчик настраивает компонент, не меняя его исходник., а не «макет с картинки». Дизайнер не выдумывает пятый вариант под давлением стейкхолдера — у него есть аргумент.

Принцип 3. Документация должна жить в макете

Документация в отдельном Notion, Confluence, Битрикс24 или другом рабочем пространстве команды умирает за две недели. Инструмент тут не главное — важнее, насколько легко найти нужное правило в момент работы. Но если правило лежит в другом окне, а не рядом с макетом, его не откроют.

Я делаю так:

1. У каждого компонента в Figma — описание прямо в макете: когда использовать, когда нет, какие есть состояния.
2. Отдельная страница «Foundations» с токенами и примерами их применения.
3. Рядом с компонентом — ссылка на его версию в коде (Storybook?Инструмент, в котором разработчики показывают компоненты в разных состояниях — как «живой» каталог. Дизайнер может открыть и увидеть, как компонент работает в коде., документация разработчика).

Если правило нельзя найти за 10 секунд — правило не существует.

Принцип 4. Дизайн-система — это контракт с разработкой

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

Мой подход: дизайн-система — это не файл, а договорённость между дизайном и разработкой. Всё, что попадает в систему, должно быть реализуемо в коде без обходных путей. И наоборот: если компонент есть в коде, он должен быть в Figma в том же виде.

Если разработчик не может собрать интерфейс из компонентов системы — система не готова.

Это значит, что дизайнер обязан понимать, как устроен фронтенд продукта. Не писать код, но знать, что такое пропсы, варианты, состояния и как они работают в выбранной технологии.

Принцип 5. Система растёт от боли, а не от плана

Самая большая ошибка — пытаться спроектировать всю систему сразу. Это приводит к огромному «дизайн-системному проекту» на полгода, который в итоге не приживается.

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

• Появилась вторая модалка — вынес модалку в систему.
• Дизайнеры начали расходиться в размерах карточек — зафиксировал карточки.
• Маркетинг попросил баннеры — вынес баннер в отдельный набор.

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

Что в итоге

Дизайн-система работает, когда она:

• Начинается с правил и токенов, а не с компонентов.
• Живёт в макетах, а не в отдельной папке с документацией.
• Согласована с разработкой на уровне контракта.
• Растёт от боли команды, а не от плана на год вперёд.
• Проверяется практикой: если её не используют — это не система.

Хорошая дизайн-система невидима. Она не мешает работать, не заставляет дизайнера думать о том, какие цвета использовать, и не создаёт споров на ревью. Она просто делает своё дело — а команда делает продукт.