Як перейти зі стилів на змінні у Figma

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

Зазвичай наші дизайнери готують макети функцій для передачі розробникам у світлій та темній темах. Для цього в нас є дві окремі UI-бібліотеки в Figma з компонентами для світлої та темної тем. Усі ці компоненти побудовані на основі колірних стилів.

Такий підхід вимагає багато коригувань, які потрібно робити вручну, оскільки назви стилів для певного компонента для світлої та темної тем не завжди однакові. Наприклад, «primary-700» використовується для кольору фону кнопки у світлій темі, а «primary-500» — у темній. Тому після застосування функції Swap колір фону потрібно вручну змінити з «primary-700» на «primary-500». Крім того, у деяких випадках Figma неправильно замінює компоненти (навіть з ідентичними назвами стилів для обох тем), особливо якщо до інстансів були застосовані будь-які зміни.

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

Коли Figma представила змінні, ми одразу вирішили спробувати, чи допоможе це розв’язати нашу проблему з перемиканням тем для макетів. І спойлер — це спрацювало! І дуже ефективно!

Тож паралельно з нашими щоденними завданнями, ми почали дослідження змінних та переведення нашої бібліотеки компонентів зі стилів на змінні.

Цілі міграції:

1. Забезпечити можливість легко та швидко перемикати теми макетів у Figma для прискорення передачі їх в розробку.
2. Мінімізувати кількість UI-бібліотек Figma, які потрібно підтримувати при роботі з кількома колірними темами.

Дослідження

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

Що таке змінні

Змінні у Figma є аналогами дизайн-токенів. Вони зберігають значення, які можна повторно використовувати для різних властивостей дизайну, таких, як кольори, відступи чи розміри. Ми були особливо зацікавлені в збереженні кількох колірних значень. Змінна може зберігати різні колірні значення для різних колірних тем. Коли змінні застосовуються до компонента, вони дозволяють вибирати колірне значення для конкретної теми.

Корисні посилання про змінні у Figma:

• Посібник зі змінних у Figma (Figma Learn)
• Навчальний посібник Figma: Вступ до змінних (YouTube-канал Figma)

Підходи до структури дизайн-токенів

Ми дослідили, що різні дизайн-системи мають структури дизайн-токенів із різними рівнями токенів. Найпоширенішим підходом є ієрархія з 3 рівнями токенів:

1. Глобальні токени — низькорівневі значення. Ці токени зберігають колірні значення у форматах HEX або RGBA. Цей рівень дозволяє вносити зміни на глобальному рівні (наприклад, зміна колірних тем). Глобальні токени зазвичай не прив’язані до конкретного компонента.
2. Семантичні токени — зберігають глобальні токени, надаючи їм контексту використання. Семантичні токени допомагають підтримувати консистентність.
3. Токени компонентів — це більш специфічні токени, що призначені для окремих компонентів інтерфейсу користувача. Вони визначають дизайн-властивості для конкретних компонентів, посилаючись на глобальні або семантичні токени. 

Корисні посилання:

• Material Design 3
• Adobe Spectrum
• Atlassian Design System
• MEWS Design System
• Токени, змінні та стилі (Figma Learn)
• Різниця між змінними та стилями (Figma Learn)

Структура змінних

Для наших цілей ми вирішили використовувати дворівневу ієрархію, яка складається з глобальних токенів і токенів компонентів. Ми обрали цей підхід, тому що:

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

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

Ще одне рішення, яке ми прийняли, — це розділити змінні та компоненти на окремі бібліотеки.

Цей підхід допомагає:

• розділити доступ для редагування бібліотек змінних та UI (у нас велика команда дизайнерів із 9 спеціалістів із різними навичками володіння Figma);
• мати окремі історії файлів і легше відстежувати оновлення змінних і компонентів.

Ми створили нову бібліотеку змінних, яка повинна включати всі токени. Змінні публікуються для використання в компонентах UI-бібліотеки. Своєю чергою компоненти з UI-бібліотеки публікуються для використання в макетах.

Перетворення стилів на глобальні токени

Ми намагалися знайти способи автоматизувати створення змінних, щоб зменшити трудомісткі ручні дії та прискорити процес переходу. Ми протестували різні плагіни для роботи зі змінними. Два з них виявилися особливо корисними й допомогли нам створити всі глобальні токени за кілька хвилин:

1. Styles to Variables Converter — цей плагін перетворює колірні стилі, що вже існують на змінні, зберігаючі їхні назви та структуру. Завдяки йому ми створили глобальні токени для світлої та темної тем з існуючих стилів у наших бібліотеках.
2. Export/Import Variables — за допомогою цього плагіна ми легко перенесли глобальні токени до нової бібліотеки змінних у два кроки:

• експортували глобальні змінні з UI-бібліотек для світлої та темної теми у файли.json;
• імпортували обидва файли.json до бібліотеки змінних.

Змінні у Figma організовані в колекції. У результаті цього етапу ми отримали 2 колекції у вікні змінних:

• «.Global Token [Light]» — усі глобальні токени для світлої теми.
• «.Global Token [Dark]» — те саме, але для темної теми.

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

Токени компонентів

Нашим наступним кроком стала робота з рівнем токенів компонентів і створення нової колекції. Ця колекція складалася зі змінних, які будуть призначені компонентам UI-бібліотеки. Щоб забезпечити можливість перемикання компонентів між світлою та темною темами, токени компонентів повинні включати 2 глобальні токени, розміщені в різних модах. Кожен мод відповідає певній колірній темі (світлій або темній). У майбутньому туди будуть додані додаткові моди для підтримки брендингів кількох клієнтів.

Коли змінна призначається компоненту, це дозволяє перемикати теми у два кліки на правій панелі Figma.

Структура токенів компонентів

Оскільки колекція токенів компонентів включає велику кількість токенів, ми також попрацювали над її структурою. Усі змінні згруповані за компонентами, яким вони мають бути призначені. Групи представлені на лівій панелі у вікні змінних. Для компонентів, які мають кілька типів (наприклад, Toast Alert, який має типи Danger, Info і Success), підготовлені додаткові правила:

• змінні для конкретних типів компонентів зберігаються в підгрупах всередині групи компонента; наприклад, змінні, що застосовуються до Toast Alert з типом Danger, розміщені в підгрупі «Danger» всередині групи «Toast Alert»;
• змінні, які є загальними для всіх типів певного компонента, зберігаються без підгруп; ці змінні просто розміщуються в групі «Toast Alert».

Найменування токенів компонентів

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

1. Component name — назва компонента, якому має бути призначена змінна (наприклад, кнопка, спливаюче сповіщення, картка тощо).
2. Type — конкретний тип цього компонента (наприклад, основний, вторинний, небезпека тощо).
3. Entity — атомарна частина компонента (наприклад, фон, обведення, іконка тощо).
4. State — інтерактивний стан компонента (наприклад, за замовчуванням, при наведенні, вимкнений тощо).

У випадку, якщо будь-яка із цих 4 частин не є релевантною для конкретного компонента, вона може бути пропущена. Наприклад, якщо компонент не є інтерактивним і має лише стан «Default» (наприклад, бейдж), частина «State» має бути упущена. Ось кілька прикладів найменування:

• dropdown_button-secondary-bg-default
• text_field-outline-border-focused
• badge-primary-bg

Підхід до тіней

Ми також попрацювали над підходом до тіней. Викликом для нас було те, що Figma не надає можливості створювати змінні для тіней. Figma дозволяє призначати тіні лише через стилі. Враховуючи, що в нас різні тіні для світлої та темної тем, і ми все ще повинні використовувати стилі, ми працювали над визначенням структури токенів тіней та узгодженням її з уже існуючою структурою токенів.

Зважаючи на те, що токени тіней уже реалізовані в нашій дизайн-системі й мають специфічні назви (наприклад, shadow-neutral-0), ми створили нові колекції токенів тіней (для світлої та темної тем) у бібліотеці змінних, щоб забезпечити узгодженість і відобразити ці назви. Токени тіней зберігають глобальні токени. Своєю чергою токени тіней призначаються токенам компонентів, тобто назви токенів тіней зберігаються в токенах компонентів, які призначаються UI-компонентам. Цей підхід забезпечує ясність для розробників і дозволяє їм переглядати, який токен тіні використовується при інспектуванні компонентів.

Стилі тіней зберігаються в бібліотеці змінних, щоб забезпечити можливість керувати як стилями, так і змінними в одному місці. Вони мають такі ж назви, як і токени компонентів для кольору тіні. Стилі публікуються для використання в UI-бібліотеці.

Далі опишемо зв’язок між токенами та стилем.

У бібліотеці змінних:

• токен тіні містить глобальні токени для світлої та темної тем;
• токени компонентів містять токени тіней для світлої та темної тем, а також токени для напрямків X/Y, Blur і/або Spread, створені як змінна типу «Number» у випадку, якщо вони повинні мати різні значення для світлої та темної тем;
• стиль тіні включає токени компонентів для властивостей тіні (колір, напрямок, Blur, Spread).

В UI-бібліотеці:

• стиль тіні з бібліотеки змінних застосовується до компонента в UI-бібліотеці.

Процес переходу

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

Процес переходу складався з двох глобальних фаз:

1. «Підготовча робота» включає визначення структур токенів і правил найменування, підготовку рекомендацій та пріоритизацію компонентів.
2. «Створення та призначення токенів компонентів» передбачає ручне створення токенів компонентів та їх призначення компонентам в UI-бібліотеці.

Ця фаза орієнтована на дві ролі — Variables Creator та Variables Assigner:

• Variables Creator готує змінні компонентів для конкретного компонента в бібліотеці змінних і публікує оновлення бібліотеки. Також він описує завдання в Jira для призначення змінних, використовуючи шаблон.
• Variables Assigner створює нову гілку в UI-бібліотеці та пов’язує нові змінні з компонентом, використовуючи підготовлені рекомендації. Під час цієї роботи він також проводить перевірку якості створених змінних і спілкується з Variables Creator, якщо щось потрібно покращити чи виправити. Після завершення призначення посилання на гілку надсилається назад Variables Creator для проведення експертної оцінки.
• Variables Creator проводить перевірку. Якщо всі змінні призначені, а компонент правильно перемикається між темами, він об’єднує (мерджить) гілку та публікує оновлення UI-бібліотеки.

Ці кроки передбачають, що всі учасники команди можуть брати участь у проєкті переходу, що прискорює його реалізацію. Крім того, розподіл процесу між двома спеціалістами забезпечує двоетапну перевірку, що мінімізує кількість помилок і будь-яких проблем з існуючою бібліотекою, яка активно використовується для дизайну функціоналу додатка.

Управління проєктом

Для ефективного управління проєктом міграції та моніторингу прогресу ми створили новий епік в Jira. Епік включає численні завдання для створення та призначення токенів компонентів для всіх елементів у UI-бібліотеці.

Ці завдання пріоритизовані на основі:

• атомарної структури компонентів — спочатку атоми (наприклад, кольори, типографіка, іконки);
• використання компонентів — спочатку часто використовувані компоненти, визначені на основі досвіду команди та аналітики використання компонентів Figma (аналітика доступна в планах Organization та Enterprise).

Рекомендації

Для документування процесу ми підготували рекомендації з усією інформацією про процес переходу, структуру змінних, найменування та правила створення/призначення. Вони включають приклади, а також рекомендації для різних випадків. Це єдине джерело правди для всіх учасників, щоб успішно мігрувати компоненти та досягти консистентних результатів. Рекомендації розділені на дві частини, орієнтовані на ролі (для Variables Creator та Variables Assigner).

Висновок

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

Для нашої команди цей перехід дозволив легко та швидко перемикати теми для макетів в декілька кліків у Figma. Ми зменшили час і зусилля на підготовку передачі макетів у розробку та підтримку UI-бібліотек. На додаток, тепер ми готові впроваджувати кілька нових колірних тем і брендингів.

Першоджерело