Без дизайн-системы ты переделываешь одно и то же — снова и снова

Возьми любой продукт которому больше года и открой три разных экрана. Найди кнопку «Сохранить» на каждом. Скорее всего увидишь три слегка разные кнопки: padding чуть отличается, border-radius немного другой, шрифт другого размера. Никто специально этого не делал. Просто первый разработчик не нашёл нужный компонент и написал свой. Второй детачнул библиотечный чтобы быстрее. Третий скопировал с другого экрана но случайно изменил стиль.

Это не проблема с командой. Это отсутствие системы.

## Что дизайн-система решает — конкретно

Дизайн-система — это не про «делать красиво». Это про скорость и предсказуемость.

Скорость. Дизайнер не рисует кнопку — берёт из библиотеки. Разработчик не пишет кнопку — использует компонент. AI-агент не придумывает кнопку — обращается к системе по имени. На каждом шаге экономится время. Умножь на количество компонентов и экранов — получишь недели.

Предсказуемость. Меняется основной цвет бренда — меняется один токен, всё обновляется везде. Нужна тёмная тема — переключается Mode в Variables. Приходит новый разработчик — открывает документацию и видит что и как использовать.

Три части которые это обеспечивают:

Токены — именованные переменные для визуальных значений. color/brand/accent вместо #E94560. spacing/md вместо 16px. Меняешь значение в одном месте — меняется везде.

Компоненты — строительные блоки с полным набором состояний. Одна кнопка с вариантами (Primary, Secondary, Ghost) и состояниями (Default, Hover, Disabled, Loading) — не восемь разных кнопок.

Документация — правила когда что использовать. Не только для дизайнеров и разработчиков, но и для AI-агентов которые работают с кодовой базой.

## Три болевые точки без системы

### Ты отвечаешь на одни и те же вопросы снова и снова

«Здесь 16px или 18?» «Это тот же синий что в шапке?» «Что должна делать кнопка в disabled-состоянии?»

Каждый такой вопрос — 15 минут потерянного времени обоих. Ответ уже был дан месяц назад другому разработчику. Но нигде не зафиксирован. Нужно объяснять снова.

Команда в среднем теряет 3–5 часов в неделю на такие вопросы. В год это больше двух рабочих месяцев — только на то что уже было решено раньше.

### Любое изменение это ручная работа

Продукт меняет основной шрифт. Без системы это обход каждого экрана в Figma и каждого компонента в коде. Сорок экранов, три часа работы, и всё равно найдётся три места которые забыли.

«Давайте попробуем другой оттенок синего» — без токенов это не эксперимент, это проект на полдня. С токенами — пять минут.

### AI генерирует «что-то похожее но не то»

В 2026 году AI-инструменты генерируют экраны и компоненты. Без системного контекста каждый промпт — лотерея. AI не знает что Button называется Button/Primary, что отступы кратны 4px, что Inter запрещён. Он берёт самые распространённые паттерны из обучающих данных — то есть shadcn с Inter по умолчанию.

После 20 экранов без системы продукт выглядит как сделанный разными командами с разным вкусом. Хотя делала одна команда.

## Почему «просто договориться» не работает

Первая реакция на эту проблему: «Нужно просто поставить правила и следить». Не работает по трём причинам.

Новые люди. Приходит новый разработчик. Ему рассказали про правила. Он помнит неделю. Потом забывает, потому что нет быстрого ответа «как правильно здесь».

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

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

Система решает все три: правила зафиксированы в токенах и компонентах, а не в головах людей; делать по системе удобнее чем без неё; AI читает DESIGN.md и AGENTS.md.

## Как начать — без боли и без «большого переезда»

Самое вредное что можно сделать — попытаться построить идеальную систему перед тем как начать использовать. Это приводит к тому что тратишь месяц на систему которая потом лежит без дела.

Рабочий подход: система минимального размера которую начинают использовать немедленно.

День 1–2: токены. Figma Variables: цвета (primary, surface, text/primary, text/secondary, border, error, success), типографика (5 уровней — display, heading, subheading, body, caption), отступы (4px-grid: 4, 8, 12, 16, 24, 32, 48). Подключить через Tokens Studio к JSON в репозитории.

Это не займёт неделю. Создать базовые Variables в Figma можно за 2–3 часа. Tokens Studio настраивается ещё за час. В итоге — работающий pipeline от Figma до CSS Custom Properties.

День 3–5: пять базовых компонентов. Button, Input, Card, Badge, Modal. Каждый на Auto Layout, с именами [Тип]/[Вариант]/[Состояние], с токенами, с полным набором состояний. Не рисовать всё с нуля — взять существующие компоненты которые уже есть в продукте, привести к единому стандарту.

День 6–7: документация. Одна страница в Figma или Notion. Для каждого компонента: когда использовать, что запрещено, примеры правильного и неправильного применения. Ещё — DESIGN.md в корне репозитория: имена компонентов, запрещённые шрифты, токены. Это то что читает AI.

Итого: одна рабочая неделя. После неё у команды есть рабочая система.

## Правило трёх мест

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

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

Это предотвращает ситуацию «200 компонентов из которых 150 использовались один раз».

## Что меняется через месяц после запуска

Первые две недели — самые сложные. Команда ещё не привыкла, есть соблазн сделать «как раньше». Важно в этот период: каждый PR проходит проверку — «использует ли это компоненты из системы?».

Через месяц происходит перелом. Команда замечает что делать по системе быстрее. Не нужно принимать решения о цветах — они уже приняты. Не нужно объяснять AI что использовать — он читает DESIGN.md.

Через три месяца система начинает жить сама: люди сами добавляют компоненты когда видят повторение, сами обновляют документацию. Это момент когда система работает, а не поддерживается через силу.

## Промпт для аудита перед созданием системы

Проанализируй кодовую базу и найди:

1. Все уникальные hex-значения цветов в CSS и Tailwind.
   Отсортируй по частоте. Топ-10 — кандидаты на токены.

2. Все компоненты с "button" или "btn" в имени.
   Для каждого: padding, font-size, border-radius, background.
   Какие отличаются только одним значением? Это дубли.

3. Самые частые значения padding и gap. Кратны ли они 4?

Результат: список 5 самых дорогих мест где нет консистентности
с конкретными файлами и строками.

☐ Токены созданы до компонентов — обязательный порядок
☐ Figma Variables синхронизированы с кодом через Tokens Studio
☐ Компоненты: [Тип]/[Вариант]/[Состояние], все состояния явно
☐ Документация: когда использовать, что запрещено, примеры
☐ DESIGN.md в репозитории с именами компонентов и запретами для AI
☐ Правило проверки при ревью: PR использует компоненты из системы?