Новий розробник виходить на проєкт. Через годину він вже запитує: "А де документація по компонентах?", "Яким шрифтом треба писати кнопки?", "Де зберігаються токени?". Якщо у вас немає відповідей — він напише так, як здається правильним. І зламає консистентність системи з першого PR.

Хороший онбординг в дизайн-систему займає 2–3 години і економить тижні потенційних проблем.

Що має знати розробник після першого дня

  • Де живе дизайн-система (Figma, Storybook, GitHub)
  • Як підключити токени до свого проєкту
  • Як знайти і використати компонент
  • Що робити, якщо компонента немає (contribution process)
  • До кого звертатися з питаннями

Структура онбординг-документа

Оптимальна структура onboarding doc для розробника:

  1. Overview — навіщо є дизайн-система і яка її структура
  2. Getting started — як встановити і підключити токени/пакет компонентів
  3. Component library — де знайти список компонентів, їх Props API
  4. Design tokens — де живуть токени, як генеруються, як оновлюються
  5. Contribution guide — як запропонувати новий компонент
  6. FAQ — типові питання (де взяти ікони, як зробити темну тему тощо)

Головне правило онбордингу: розробник має знайти відповідь на 80% питань самостійно, без звернення до дизайнера або DS-менеджера. Якщо це не так — документація неповна.

Quick start: перший компонент за 5 хвилин

Найкращий онбординг починається з дії, а не читання. Після вступного огляду дайте розробнику конкретне завдання: "Зроби сторінку з Button, Input і Card, використовуючи тільки компоненти з нашої системи".

Це одразу виявляє: чи зрозуміле підключення, чи є потрібні компоненти, чи зрозуміло як їх використовувати. І це краще за будь-яку лекцію.

Storybook як точка входу

Якщо у вас є Storybook — він має бути першим місцем, куди відправляєте нового розробника. Stories показують компонент у всіх станах, Controls дозволяють погратись з пропами, Docs пояснюють коли і як використовувати.

Без Storybook — ок, але тоді потрібна детальна документація в Notion або README з прикладами коду для кожного компонента.

Типові помилки онбордингу

  • Документація є, але не оновлювалась пів року
  • Розробника онбордять усно — через тиждень половина інформації забута
  • Немає чіткого "першого завдання" — розробник занурюється в продакшн код без системного розуміння
  • Немає FAQ — одні й ті самі питання задаються знову і знову

Чеклист після першого тижня

  • Розробник зробив хоча б один PR з використанням компонентів системи?
  • Він знає, де знайти будь-який компонент самостійно?
  • Він знає contribution process?
  • Він залишив фідбек по онбординг-документу (що не зрозуміло)?

Онбординг і документація — частина дизайн-системи, яку ми будуємо разом з токенами і компонентами у нашому 7-денному спринті.