Архівний матеріал: розбір публікації від 2019-09-02. Назви функцій, інтерфейс, можливості плагінів і умови доступу наведені в контексті того часу.
У матеріалі розбирається підхід Buzz Usborne і команди Help Scout до міграції великої дизайн-системи зі Sketch у Figma. Це не історія про «кращий інструмент», а розбір реальної ціни переходу, технічних обмежень і кроків, які допомогли вкластися приблизно в один тиждень роботи над системою.
Коли перехід у Figma здається занадто дорогим
У Help Scout дизайн-система була побудована як кілька взаємопов'язаних Sketch Libraries, які синхронізували через GitHub. До них були прив'язані:
- активні продукти і макети,
- процеси розробки і передачі у розробку,
- документація, навчальні матеріали і онбординг.
Перехід на новий інструмент означав не просто «експортувати файли», а:
- переробити бібліотеки компонентів,
- оновити документацію,
- навчити всю розподілену команду,
- якийсь час підтримувати два середовища паралельно.
Buzz Usborne підкреслює, що це прямі витрати часу конкретних людей, які тимчасово відволікаються від «звичайної» роботи. Для стабільних команд це нагадує переїзд в інший офіс: теоретично можливо, але точно не «по дорозі».
Чому простий імпорт зі Sketch у Figma не спрацював
Перші два дні дослідження Figma були присвячені саме перевірці: чи можна обійтися простим відкриттям .sketch-файлів у Figma. Виявилось, що ключова проблема — різна модель роботи з компонентами і їхніми оверрайдами.
Схематично:
- Sketch дозволяє переважно наперед визначені оверрайди. Через це дизайн-система Help Scout будувалася на складній схемі з масками і дрібними «цеглинками»-символами, які давали гнучкість.
- Figma дозволяє змінювати колір, типографіку, ефекти напряму в інстансах компонентів, без проміжних символів.
У результаті будь-який складний символ зі Sketch (з кількома рівнями вкладеності) при імпорті у Figma перетворювався на надмірно складну структуру, яку незручно підтримувати.
Автор описує приклад картки в Sketch, зібраної з п'яти вкладених символів, яка давала потрібну свободу оверрайдів. Саме такі штуки переносяться в Figma особливо погано.
Висновок команди: щоб реально скористатися можливостями Figma, доведеться перебудувати бібліотеку з нуля, очищаючи компоненти від зайвої складності, яка була змушеним рішенням у Sketch.
Як рішення «не переходимо» перетворилося на «переходимо зараз»
Після перших оцінок Buzz Usborne дійшов до доволі прагматичного висновку: Figma виглядає сильніше як продукт і компанія, але вартість переходу здається надто високою. Тобто продукт подобається, але повна міграція лякає обсягом робіт.
Ситуація змінилася після запланованої розмови з продуктовою командою Figma (Figma була клієнтом Help Scout). Поки готувався до цієї розмови і глибше попрацював у Figma ще кілька днів, стало видно інше: потенційний приріст продуктивності і колаборації для всієї команди перекриває витрати на перехід.
Голова дизайну Help Scout сформулювала аргумент, який став вирішальним: якщо команда все одно майже напевно перейде у Figma «колись потім», то логічніше робити це зараз, а не через рік, коли дизайн-система стане ще більшою і складнішою.
Крок 1 — розділити бібліотеки на зрозумілі модулі
Перший практичний крок міграції Help Scout — налаштувати структуру бібліотек так, щоб переносити їх частинами. Дизайн-систему розбили на суб-бібліотеки, кожна з яких покривала свій домен.
Схема виглядала так:
- Core — загальні активи для будь-якого дизайнера (логотипи, бренд-гайд, іконки, ілюстрації, базові токени).
- Окремі бібліотеки під продуктові чи командні домени (наприклад, компоненти конкретного продукту).
Міграцію почали саме з Core — на його базі потім будувалися всі інші бібліотеки у Figma. Це дало порядок і відчуття прогресу: замість «перенести все і одразу» команда рухалася блоками.
Крок 2 — опора на Styles і вбудовану документацію
Ключова можливість Figma, яку команда активно використала під час міграції, — це Styles. Вони працюють подібно до Type Styles у Sketch, але поширюються не лише на текст, а й на кольори та ефекти (тіні тощо).
Практичний підхід Buzz Usborne:
- усі базові кольори, тіні, текстові стилі визначити як Styles в одній бібліотеці (зазвичай у тій самій Core),
- у кожній бібліотеці робити сторінку-документацію, де ці стилі показані у використанні.
Такий підхід дає дві переваги під час міграції:
- коли компоненти перебудовуються, дизайнери посилаються не на локальні значення, а на спільні Styles — легше оновлювати систему;
- новим людям простіше розібратися: вони бачать не лише список змінних, а й візуальні приклади, де і як який стиль застосовується.
Крок 3 — показати, як компоненти можуть розширюватися
Оскільки Figma дозволяє ширші оверрайди, у ній часто достатньо меншої кількості базових компонентів. Те, що в Sketch існувало як окремі символи (наприклад, «button solid» і «button outlined»), у Figma стає варіацією одного «button».
Це економить час дизайнерів, але створює іншу проблему: людина, яка не будувала бібліотеку, може не здогадатися, як саме з одного базового компонента отримати потрібну варіацію.
Щоб уникнути цього, команда Help Scout:
- розміщувала поруч з компонентом приклади його використання,
- збирала з одного й того ж компонента кілька сценаріїв — наприклад, повноцінну діалогову розмову на базі одного Фігма-компонента повідомлення.
Так новий дизайнер бачить не лише «матрицю пропсів», а реальні патерни застосування.
Крок 4 — організувати структуру Figma під її власну логіку
Коли команда спробувала зберегти колишню структуру назв зі Sketch, це виявилося неефективним. Причина — у відмінностях файлової моделі Figma (Pages, Frames, Components, панель Assets).
У підсумку Buzz Usborne перейшов до схеми, яка працює за трьома рівнями:
- Pages — великі категорії (наприклад, Forms),
- Frames — логічні групи всередині категорії (наприклад, Inputs),
- Components — окремі елементи на кшталт Error, Success, Label, Helper text.
За рахунок послідовної, досить конкретної системи найменувань компоненти стають легко знайти в панелі Assets навіть тим, хто не брав участі у побудові бібліотеки. І це особливо важливо при переході команди на новий інструмент: половина спротиву зазвичай у тому, що люди просто не можуть нічого швидко знайти.
Крок 5 — коли імпорт можна використовувати, а коли краще намалювати з нуля
Buzz Usborne розділяє всі елементи на дві групи:
- Прості елементи — іконки, нескладні фігури, базова графіка. Їх можна безболісно імпортувати зі Sketch у Figma, і все працює більш-менш із коробки.
- Складні компоненти — з масками, вкладеними символами, великою кількістю умовних варіацій. Для них імпорт дає надто захаращену структуру.
Для другої групи в Help Scout свідомо обрали болючий, але продуктивний шлях: повне перевідтворення у Figma. Робочий прийом був максимально простий:
- зробити скріншот старого компонента в Sketch,
- розмістити його у Figma як референс,
- «обвести» заново, створюючи чисту структуру Figma-компонента без спадкових артефактів.
Автор зазначає, що це звучить дивно, але на практиці виявилося швидше, ніж імпортувати складні символи зі Sketch і потім вручну вичищати зайві групи і маски. Паралельно це прискорює освоєння самого інструмента: поки ви «трейсите» десятки компонентів, неминуче починаєте дуже добре відчувати Figma.
Крок 6 — підготувати команду до зміни інструмента
Help Scout — повністю віддалена команда, тому будь-які зміни потребують продуманих комунікацій. Перехід у Figma не став винятком.
Підхід, який описує автор:
- команда заздалегідь знала, що перехід розглядається, але чіткий «старт» дали лише тоді, коли основна частина дизайн-системи у Figma вже була готова;
- для всіх підготували приблизно 20-хвилинне демо-відео: бази роботи у Figma, ключові відмінності від Sketch, реальні покращення у роботі з компонентами;
- це зняло частину напруги у тих, хто не любить раптові зміни робочих інструментів.
Важливий момент цього кроку — перейти від «ми, можливо, колись...» до чіткої дати й пояснення, що вже готово і як цим користуватися.
Крок 7 — зробити чистий розрив замість вічного «гібриду»
На етапі дослідження команда Help Scout розглядала варіант підтримувати дизайн-систему одночасно у Sketch і Figma. Теоретично це можливо, але на практиці для невеликої команди без окремої ролі «сторожа бібліотек» це швидко стає некерованим.
Тому було прийнято рішення повністю сфокусуватися на Figma:
- усю актуальну документацію й онбординг оновили під Figma,
- процеси розробки та дизайнерський handoff переробили з урахуванням нового інструмента,
- старі Sketch-бібліотеки залишили в архіві: вони фізично існують, але більше не документуються і не оновлюються.
При цьому перехід для проєктів зробили м'яким:
- проєкти «в роботі» продовжують жити у Sketch (деякі дизайнери за бажанням переносять їх у Figma);
- усі нові проєкти стартують вже у Figma.
Такий підхід не змушує зупиняти поточну роботу, але водночас не дає нескінченно відкладати адаптацію під новий інструмент.
Що можна взяти з кейсу Help Scout для власної міграції
Buzz Usborne не подає цей досвід як універсальний рецепт, але з кейсу можна винести кілька практичних орієнтирів:
- спочатку чесно порахувати вартість переходу (час, документація, навчання), а потім вже вирішувати, чи виправданий виграш;
- розбити дизайн-систему на логічні бібліотеки й переносити їх чергою, починаючи з Core;
- використовувати Styles і вбудовану документацію у Figma як «кістяк», на який спирається все інше;
- для складних, насичених масками компонентів планувати саме перевідтворення, а не імпорт;
- закладати час на комунікацію з командою — демо, гайдлайни, відповіді на запитання;
- вирішити, чи тягнете ви гібридну підтримку двох інструментів — і якщо ні, робити свідомий clean break.
Цей кейс показує, як команда з уже вибудуваною дизайн-системою і процесами підійшла до переходу не як до «перевстановлення софту», а як до окремого проєкту зі своїми ризиками, планом і дедлайнами.
Джерело: Buzz Usborne – Smashing Magazine. Дата оригіналу: 2019-09-02.