Управление дизайн-системой: версии, вклад команд и внедрение
Продвинутое3 минРедакция Innovialabs
Коротко
Дизайн-система живёт, только если у неё есть владелец, понятный процесс вклада, версии по SemVer с changelog для Figma и кода, правила устаревания компонентов и метрики, которые показывают реальное использование в продуктах.
Что такое governance и зачем он нужен
Governance — набор правил о том, кто принимает решения в дизайн-системе, как в неё попадают изменения и как продукты переходят на новые версии. Без этих правил система быстро расходится с реальностью: команды делают локальные копии компонентов, Figma и код отличаются, а обновления ломают экраны без предупреждения.
Хороший governance отвечает на четыре вопроса: кто владелец, как предложить изменение, как выпускается версия и как убрать устаревшее.
Модели управления
| Модель | Как устроена | Когда подходит |
|---|---|---|
| Централизованная | Отдельная команда проектирует, разрабатывает и выпускает систему | Один-два продукта, нужна высокая согласованность, есть ресурсы на выделенную команду |
| Федеративная | Представители продуктовых команд вместе развивают систему, есть небольшое ядро координаторов | Много продуктов, у команд разный контекст, центральная команда стала бы узким местом |
| Гибридная | Ядро отвечает за основу (токены, базовые компоненты), продукты вносят паттерны | Самый частый вариант по мере роста |
В любой модели нужен явный владелец с правом сказать «нет» — иначе система превращается в склад всего подряд.
Процесс вклада
Чтобы команды приносили компоненты в систему, а не делали свои копии, процесс должен быть простым и предсказуемым:
- Запрос. Команда описывает задачу, а не готовое решение: какую проблему не закрывают существующие компоненты.
- Проверка на дубли. Можно ли решить вариантом существующего компонента.
- Оценка. Нужен ли компонент нескольким продуктам или это локальный кейс, который остаётся в продукте.
- Дизайн и код. Компонент проектируют с состояниями, адаптивом и доступностью, параллельно — реализация и документация.
- Ревью. Дизайн-ревью, код-ревью, проверка доступности.
- Выпуск. Попадает в релиз с записью в changelog.
Полезно ввести уровни: core (поддерживает ядро, строгие гарантии) и community или experimental (принесено командами, может меняться). Так вклад не блокируется долгими ревью.
Версионирование Figma и кода
Используйте семантическое версионирование MAJOR.MINOR.PATCH:
- PATCH — исправления без изменения API: поправили отступ, цвет фокуса.
- MINOR — новое без поломки: новый вариант, новый компонент, новое свойство.
- MAJOR — ломающие изменения: переименовали свойство, удалили вариант, изменили структуру токенов.
Практика для двух сторон:
- Код публикуется как пакет с версией, команды обновляются осознанно.
- Figma-библиотека публикуется с описанием изменений в каждом релизе. Для крупных изменений используют ветки и ревью перед мержем.
- Единый номер версии или хотя бы таблица соответствия, какая версия Figma соответствует какой версии кода.
- Changelog на понятном языке: что изменилось, кого затрагивает, что нужно сделать при обновлении.
Пример записи:
## 3.0.0
### Breaking
- Button: свойство `type` переименовано в `variant`.
### Added
- Toast: вариант `warning`.
### Fixed
- Input: контраст плейсхолдера.
Политика устаревания
Удалять компонент сразу нельзя — продукты на него завязаны. Нормальный цикл:
- Объявление. Компонент помечается deprecated в Figma и в коде (предупреждение в консоли или линтере), в документации — на что заменить.
- Период перехода. Заранее объявленный срок или число релизов, в течение которых компонент работает.
- Миграция. Гайд, а при возможности — codemod или автозамена.
- Удаление в следующей MAJOR-версии.
Метрики внедрения
Измеряйте то, что показывает реальное использование, а не количество компонентов в библиотеке:
- Покрытие: доля экранов или компонентов в продукте, собранных из системы, а не локальных копий. Для кода считается анализом импортов, для Figma — через аналитику библиотек.
- Отсоединённые инстансы (detached) в Figma — сигнал, что компонент чем-то не устраивает.
- Отставание версий: на какой версии сидит каждый продукт.
- Скорость вклада: сколько времени проходит от запроса до релиза.
- Обратная связь: регулярные опросы команд и разбор обращений.
Частые ошибки
- Нет владельца — решения принимает тот, кто громче.
- Figma и код живут по разным версиям без связи.
- Ломающие изменения в minor-релизе.
- Удаление компонентов без периода перехода.
- Метрика «сколько компонентов сделали» вместо «сколько используют».