Design system для цифрового продукта: от токенов до governance

Введение. Design system — не «библиотека кнопок», а контракт между дизайном, продуктом и frontend. Материал для product- и engineering-лидеров, которые принимают решения на горизонте 12–24 месяцев, а не гонятся за хайпом в презентации.

Зачем аудит до редизайна

Большинство срывов в теме «design system» начинается не с кода, а с размытого scope: маркетинг обещает одно, продажи фиксируют другое, а ИТ закрывает техдолг третьим приоритетом. В итоге бюджет уходит в интеграции «на скотч» и ручные сверки в Excel. Мы видим это в проектах, где не описаны границы MVP, нет владельца метрик и не зафиксированы SLA на данные между системами.

Команды без design system тратят 20–40% времени фронтенда на повторное изобретение одних и тех же паттернов: ещё одна модалка, ещё один вариант кнопки с чуть другим паддингом. Это не мелочи стиля, а спринты, которые могли бы идти в фичи, а уходят на пересборку того, что уже где-то есть в проекте.

Сигналы, что интерфейс мешает деньгам

Опорный принцип: сначала поток ценности, потом стек. Нарисуйте journey от первого касания до оплаты и поддержки, отметьте ручные шаги и точки отказа. Только после этого выбирайте React и модель данных. Для design system мы обычно рекомендуем токены → примитивы → композиции → документация в Storybook + версионирование: она даёт предсказуемый TCO и не блокирует масштабирование команды.

Зафиксируйте ADR по ключевым решениям: хранилище, очереди, авторизация, наблюдаемость. Включите в Definition of Done контрактные тесты API, схему событий и политику миграций. design system имеет смысл заказывать только когда есть согласованный backlog с приоритетами P0/P1 и измеримые KPI на квартал.

Дрейф между Figma и продакшеном — не придирка дизайнера, а измеримая метрика: сколько компонентов в коде расходятся с актуальным макетом. Заведите линтер или codegen-проверку, которая ловит расхождения на PR, а не на ревью через три месяца после релиза.

Как проводить UX-аудит

Кейс A (финтех). Клиент пришёл с болью: 15 оттенков серого в проде. Мы разбили релиз на три волны: стабилизация данных, автоматизация рутины, персонализация. Через 14 недель токены и semantic colors сократили правки UI на 50%. Критично было не «переписать всё», а остановить утечку лидов на стыке каналов.

Кейс B (маркетплейс). Другая ситуация: команды шипили разные модалки. Здесь сработала обратная стратегия — сначала интеграция с CRM и нормализация справочников, затем редизайн витрины. Итог: единый Dialog + policy PR снизил UI-баги на 35%.

Что чинить первым

1. Старт с полной библиотеки компонентов вместо токенов и 10–15 базовых примитивов.
2. Отсутствие governance — любая команда добавляет «свою» кнопку в общий пакет.
3. Синхронизация Figma и кода вручную без codegen или единого источника токенов.
4. Игнорирование accessibility на старте — контраст и фокус потом чинят по всей системе разом.
5. Запуск DS без sponsor в инженерии — adoption остаётся на уровне «посмотрели и забыли».

Передача в разработку

• [ ] Токены (цвет, типографика, spacing) вынесены в переменные, а не хардкод в макетах
• [ ] Определены 15–25 базовых компонентов с правилами «when / when not»
• [ ] Настроен semver и changelog для breaking-изменений
• [ ] Есть council или owner для ревью новых паттернов
• [ ] Проверен контраст AA и фокус клавиатуры на базовых компонентах
• [ ] Выбраны 2–3 pilot-команды для первого adoption

Краткий итог

Governance важнее пикселей: RFC на новые компоненты и owner роли. Если нужна внешняя экспертиза — начните с брифа или оценки: так быстрее получить реалистичный план, чем спорить о стеке в вакууме.

• Semantic tokens вместо hex в макетах
• Контраст AA в палитре
• Changelog для breaking visual changes

Состав и governance

Design system — это токены, компоненты, паттерны и правила использования, а не только UI-kit в Figma. Минимальный набор: цвет и типографика как CSS variables, сетка и spacing scale, 15–25 базовых компонентов (button, input, modal, table), документация «when / when not». Для React-команд компоненты живут в monorepo рядом с Storybook; версioning semver, changelog, codemods при breaking changes.

Governance: council из design + front + product, SLA на review новых паттернов, запрет «локальных кнопок» в фичах. Метрики зрелости: coverage (% экранов на DS-компонентах), время сборки типовой страницы, количество расхождений с prod после релиза. Связка с design system как услугой — старт с audit текущего UI, затем MVP за 6–10 недель, не «всё сразу». Для мультбренда — theme layer поверх одной кодовой базы.

План adoption: 2–3 pilot-команды, office hours для дизайнеров и dev, backlog «компонент vs кастом» с прозрачным SLA. Не блокируйте релизы из-за мелких отступов — блокируйте из-за accessibility и broken patterns. Измеряйте time-to-ship типовой фичи до и через 6 месяцев после DS. Для мобильных продуктов нужны отдельные touch-паттерны, не только уменьшенный desktop.