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

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

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

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

Команда теряет 20–40% спринтов на переделки, потому что не согласовала критерии готовности: что считается лидом, какая атрибуция в CRM, какой latency API допустим для витрины. Без этих договорённостей любая архитектура — лотерея.

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

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

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

Наблюдаемость — не «логи на сервере», а корреляция user_id → trace_id → заказ. Без этого невозможно честно считать ROI и оптимизировать воронку. Добавьте дашборды для продуктовых и инженерных метрик в одном timezone и с единым справочником статусов.

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

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

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

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

1. Выбор технологии до описания доменных границ.
2. Отсутствие каталога событий аналитики — спор о цифрах вместо роста.
3. «Временный» монолит без модульных контрактов, который нельзя резать на сервисы.
4. Игнорирование non-functional requirements: RPO/RTO, лимиты PII, требования 152-ФЗ.
5. Параллельный редизайн и миграция данных без feature flags.

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

• [ ] Есть единый glossary для бизнеса и разработки
• [ ] KPI привязаны к измеримым событиям в продукте
• [ ] Описаны интеграции и владельцы данных
• [ ] План релизов с rollback и мониторингом
• [ ] Оценён TCO на 3 года, а не только CAPEX первого спринта
• [ ] Согласованы критерии приёмки с заказчиком и поддержкой

Краткий итог

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.