Як змінити дизайн-систему, не порушуючи її: поради Ігоря Наконечного

30 вересня •

4918 читачів

Дизайн-система постійно змінюється разом із продуктом. З’являються нові сценарії, компоненти й значення, команда переглядає правила та вдосконалює рішення. Складнощі виникають, коли ці зміни відбуваються без спільного процесу.

Новий стиль може з’явитися в макеті, але не потрапити до системи. Компонент оновлять в одному місці, а в іншому залишать стару версію. Назву токена можуть змінити так, що розробникам доведеться уточнювати, як його використовувати. А через кілька тижнів уже складно пригадати, що саме змінили та з якої причини.

Ігор Наконечний, шефдизайнер в àbank, поділився порадами про те, як вносити зміни в дизайн-систему, зберігати її послідовність і не створювати плутанини для команди. Ці думки Ігор озвучив під час попереднього воркшопу «Як створити дизайн-систему з нуля». Уже 3 жовтня воркшоп відбудеться знову, а в цій статті ми зібрали кілька ключових тез із минулої зустрічі.

Домовляйтеся з розробниками до внесення змін

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

Розробники можуть одразу підказати, які технічні обмеження потрібно врахувати. Наприклад, у JavaScript і Swift є свої правила для назв змінних, тому формат токенів варто узгодити з розробниками ще до їх створення.

Зберігайте одне джерело актуальної інформації

У команди має бути чітке місце, де зберігається актуальна версія дизайн-системи. Якщо новий компонент спочатку створили в робочому макеті, а до бібліотеки перенесли пізніше, виникають дві версії одного рішення. Те саме відбувається зі стилями, токенами та іншими елементами.

Тому зміни варто спочатку вносити до дизайн-системи. Після цього команда може оновлювати бібліотеки у своїх робочих файлах. Так значно простіше зрозуміти, яка версія компонента або правила зараз актуальна.

Фіксуйте зміни коротко й зрозуміло

Сам факт зміни мало що пояснює. Команді потрібно знати, що змінилося, чому це сталося та як тепер використовувати нове рішення. Для цього не потрібна велика документація. Часто достатньо кількох речень із конкретним поясненням і прикладом.

Документація має відповідати на робочі запитання команди. Якщо дизайнер або розробник може самостійно знайти потрібну інформацію, система виконує свою функцію.

Узгоджуйте послідовність оновлень

Навіть невелика зміна потребує зрозумілого порядку дій. Наприклад, якщо дизайнеру знадобився радіус, якого поки немає в системі, не варто одразу додавати його лише у свій макет.

Спочатку потрібно перевірити, чи справді нове значення потрібне продукту. Потім додати його до дизайн-системи та узгодити з командою розробки. І лише після цього оновити бібліотеку в робочих файлах. Так нові рішення не накопичуються хаотично, а дизайн-система залишається керованою навіть у великому продукті.

Спілкуйтеся з усіма, хто працює із системою

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

Дизайн-система стає справді корисною тоді, коли команда однаково розуміє, як її змінювати. Це зменшує кількість помилок, пришвидшує роботу й допомагає зберігати послідовність у продукті.

Уже цієї суботи відбудеться онлайн-воркшоп «Як створити дизайн-систему з нуля» разом із Ігорем Наконечним. За 4 години практики ми детально розберемо, як оновлювати дизайн-систему й не порушувати те, що вже працює. Встигніть зареєструватись — кількість місць обмежена 😌