Governance дизайн-системи звучить як щось для великих корпорацій. Насправді проблема виникає набагато раніше — вже при команді з 5 людей, коли дизайнери починають незалежно вносити зміни до компонентів і система розпадається на несумісні версії.

Governance — це не бюрократія. Це набір домовленостей: хто може що змінювати, як погоджувати зміни і де живе джерело правди.

Три моделі governance для малих команд

Централізована: один DS Owner (зазвичай сеніор дизайнер або DSE) контролює всі зміни. Решта відкривають запити. Підходить для команд до 5 людей або коли система ще нестабільна.

Федеративна: є кілька contributors, кожен відповідає за свій домен (наприклад, один — за forms, інший — за navigation). Рішення ухвалюються спільно. Підходить для команд 5–10 людей.

Відкрита: будь-хто може пропонувати зміни через PR-процес. DS Owner тільки рев'ює. Підходить для зрілих систем з сильною культурою документування.

Що точно потрібно задокументувати

  • Contribution guide — як запропонувати новий компонент або зміну
  • Review checklist — що перевіряється перед мерджем
  • Breaking change policy — що робити, коли зміна ламає існуючі юзкейси
  • Deprecation process — як виводити компоненти з використання

Contribution process для маленької команди

Найпростіший робочий процес для команди 3–7 осіб:

  1. Дизайнер помічає відсутній компонент або потребу у зміні
  2. Відкриває issue в Figma/Notion/Linear з описом проблеми і пропозицією
  3. DS Owner або хтось із команди рев'ює і дає фідбек протягом 24–48 годин
  4. Після approval — дизайнер реалізує в Figma, розробник — в коді
  5. Зміна документується в changelog

Ключове правило: не вносьте зміни до спільних компонентів прямо у продуктовому Figma-файлі. Завжди — спочатку в систему, потім у продукт.

Версіонування: чи потрібне семантичне versioning?

Для маленьких команд строге semver (1.0.0, 1.1.0, 2.0.0) — зайве. Достатньо: changelog із датами і міткою BREAKING якщо зміна порушує зворотну сумісність. Коли команда зросте до 10+ — переходьте на повноцінне versioning.

Найчастіші помилки governance

  • Процес є, але ніхто не дотримується — немає enforcement
  • DS Owner стає вузьким місцем — рев'ю займає тижні
  • Зміни документуються постфактум або не документуються взагалі
  • Немає чіткого "де живе актуальна версія системи"

Налаштовуємо governance як частину побудови дизайн-системи — щоб через 6 місяців система не деградувала.