Архівний матеріал: розбір публікації від 2019-04-15. Назви функцій, інтерфейс, можливості плагінів і умови доступу наведені в контексті того часу.
У статті розбирається досвід команди Liferay Design, яку очолює автор матеріалу Paul Hanaoka: як понад 20 дизайнерів поступово перейшли на Figma, перебудували бібліотеки, хендов до розробників і спільну роботу з продактами.
Вихідна точка 2015 року: розрізнений стек інструментів
У 2015 році основним інструментом команди був Sketch, але далі схожість закінчувалася. Для кожного етапу процесу використовувалися різні сервіси:
- для прототипів і демонстрацій стейкхолдерам: InVision, Axure, Marvel, Google Slides, PDF;
- для хендову розробникам: Avocode, Zeplin, різні Sketch-плагіни без окремих застосунків;
- рідше — прямий обмін Sketch файлами з розробниками, але тільки ті, хто мав Mac і ліцензію Sketch.
Коли вийшов плагін Craft для Sketch, це частково розв'язало проблему: стало легше завантажувати екрани в InVision, ділитися компонентами та стилями між файлами.
Поступово команда об'єдналася навколо InVision: задокументувала процеси, полегшила обговорення з бізнесом та хендов. Але з'явилися нові проблеми:
- складні права доступу — для не-дизайнерів аккаунт отримати важко, плюс потрібно додавати в правильні групи;
- ручний менеджмент версій і файлів у спільному сховищі;
- конфлікти синхронізації та хаос у структурах папок.
На цьому фоні питання «чи можна мати один інструмент замість трьох — для макетів, прототипування та хендову» стало ключовим. Власне, так у полі зору команди з'явилася Figma.
Перші експерименти з Figma і стратегія «почати з малого»
Перші дизайнери Liferay почали тестувати Figma ще з бети 2016 року. Інструмент закривав приблизно 80 % потреб: дозволяв робити більшість дизайну в одному місці, хоча імпорт зі Sketch працював нестабільно. Важливі виграші, які одразу відчули:
- справжня робота в реальному часі декількох людей в одному файлі;
- збір фідбеку від стейкхолдерів прямо у файлі;
- простий хендов розробникам з одного джерела істини.
До 2017 року частина дизайнерів робила у Figma більшість задач, а один з дизайнерів Lexicon (дизайн системи Liferay) — Emiliano Cicero — став активним «євангелістом» всередині команди. Це істотно допомогло переконати решту.
Запуск Figma 2.0 влітку 2017 року з підтримкою прототипування та кращим хендовом зробив інструмент реальним кандидатом для всієї глобальної команди. Питання стало не «чи переходити», а «як перевести більше 20 дизайнерів, не зламавши процес».
Пілотний проєкт: розподілена команда США — Бразилія
Восени 2017 року запустили першу пілотну команду: продуктова група, розподілена між США та Бразилією. Вони мали тижневий офлайн-кік-оф у Лос-Анджелесі, де одразу будували флоу та вайрфрейми у Figma.
Практичні ефекти пілоту:
- значне прискорення спільної роботи над флоу;
- можливість ділити задачі між дизайнерами без танців із синком бібліотек;
- мінімум турбот про версіювання окремих локальних файлів.
На глобальному зібранні у січні 2018 команда сформувала план поступового переходу на Figma. Але пілот також виявив обмеження:
- жорсткий дедлайн великого проєкту з кількома командами розробки по світу — повністю ламати вже налагоджений процес рев'ю та хендову було надто ризиковано;
- нестабільний офлайн-режим Figma (важливо для розподіленої команди).
У результаті команда пішла на компроміс: Sketch і Figma для вайрфреймів та макетів, але прототипування й офіційний рев'ю залишили в InVision. Це показовий приклад: навіть якщо новий інструмент загалом кращий, іноді час і масштаб проєкту диктують гібридну схему.
Як команда вибудувала структуру у Figma
Коли стало ясно, що перехід буде масштабним, команда зосередилася на тому, щоб одразу задати порядок: як організовувати проєкти, файли та компоненти.
Роль молодших дизайнерів і «чисті» звички
Початкову систему організації запропонували два тодішніх джуніор-дизайнери — Abel Hancock і Naoki Hisamoto. Вони не встигли перейняти «погані» звички з Photoshop на кшталт хаотичних назв шарів, тому відразу закладали акуратну, передбачувану структуру.
За рік до старту масової міграції вони вже будували невелику, але структуровану бібліотеку компонентів для проєктів Liferay.com. Це стало зачатком майбутньої глобальної бібліотеки.
Система обкладинок для файлів
Одне з перших помітних покращень — система covers для Figma-проєктів, яку створив дизайнер Liferay.com під впливом твітів Ben Fry.
Суть прийому:
- На першій сторінці файлу створюється один фрейм розміром 620×320.
- Усередині розміщується візуальний дизайн «обкладинки» (текст від 24 pt, заголовки в прикладі — 48 pt).
- Figma використовує цей фрейм як прев'ю файлу в проєкті.
Автори зауважують, що по краю все одно буде невелике поле, але його можна візуально сховати, якщо пофарбувати фон сторінки в той самий колір, що й картка.
Ефекти від впровадження:
- швидший пошук потрібного файлу не тільки для дизайнерів, а й для продактів, проджектів та розробників;
- можливість кодувати статуси файлів в обкладинці (наприклад, робочий, у рев'ю, зафіксований тощо);
- візуально впорядкована бібліотека, замість хаотичного списку.
Файл з шаблонами команда Liferay виклала у відкритий доступ: https://liferay.design/resources/figma.
Утиліти всередині Figma замість сторонніх сервісів
До Figma більшість дизайнерів тримали в себе «базові» Sketch файли: елементи для вайрфреймів, прості патерни. При переході вони почали:
- об'єднувати ці напрацювання в єдину бібліотеку;
- відмовлятися від окремих інструментів на кшталт Lucidchart, створивши власні компоненти для user/task flows прямо у Figma;
- нарощувати набір утиліт всередині одного файлу-бібліотеки.
Серед внутрішніх утиліт, які команда зробила і виклала:
- redline компоненти для детальної специфікації інтерфейсів;
- «стікери» для affinity-діаграм та фасилітації;
- вузли для побудови flow-діаграм.
Ключовий плюс такого підходу: будь-яке покращення компонента в бібліотеці легко доходить до всієї команди. Централізований файл з редлайнами й утилітами спрощує підтримку: будь-хто з команди може запропонувати правки, а зміни розповсюджуються через оновлення бібліотеки.
Принципи створення компонентів
Команда сформулювала кілька практичних рекомендацій для роботи з компонентами у Figma:
- Активно використовувати overrides і «мастер»-компоненти для побудови потужних базових елементів (детальний розбір є в їхній статті про атомарні компоненти у Figma).
- Домовитися про єдину схему найменування — Liferay спирається на atomic design.
- Документувати та підписувати все, особливо шари: зрозумілі імена полегшують життя й розробникам, і іншим дизайнерам.
Після виходу розширених стилів у Figma на початку червня 2017 року системна команда завершила повну версію бібліотеки Lexicon між великими релізами продукту. Це стало критичною умовою для підтримки глобальної міграції.
Як Figma замінила хаос з версіями: робота з історією файлів
Окремий блок змін стосується версіонування. Раніше дизайнери рятувалися звичними патернами з Photoshop/Sketch:
- нові сторінки всередині файлу для кожної ітерації;
- дублювання файлу з суфіксом «_B», «_final2» тощо;
- окремі файли під радикальні зміни.
Figma ввела іменування і нотатки в історії версій, і це різко спростило життя команді.
Підхід, який Liferay застосовує до history, близький до Git:
- версія Figma розглядається як «коміт»;
- точки в історії називають імперативом на кшталт «update button colors»;
- опис версії використовують для «що і чому» замість «як».
Важливий нюанс: коли ви «відкочуєтеся» до старої версії, Figma не стирає історію — вона просто копіює той стан як нову вершину таймлайну. Тобто можна прийти до «final 3.0», почавши з «final 1.1», і все одно бачити повний ланцюжок.
Якщо потрібні радикальні зміни чи новий проєкт на базі старого, команда «форкає» файл: дублює його з поточного стану. Важливе обмеження: історія версій при цьому не копіюється.
Практичні поради щодо версій від команди Liferay
Команда сформулювала кілька простих правил, які виявилися корисними в повсякденній роботі:
- Заголовок версії — до 25 символів.
Довші заголовки обрізаються в списку, щоб їх прочитати повністю, доводиться відкривати модальне вікно редагування. - Опис — до 140 символів.
Короткі тексти підтримують читабельність історії. - Імператив у заголовку.
Це дає майбутньому читачу чіткішу підказку: «що станеться, якщо перейти до цієї версії». - У описі — «що» і «чому».
Це фіксує контекст рішень і допомагає майбутнім авторам розуміти логіку змін.
За аналогією з Git команда посилається на два класичні тексти для глибшого розуміння підходу: «Commit Often, Perfect Later, Publish Once: Git Best Practices» від Seth Robertson та «How to Write a Git Commit Message» від Chris Beams.
Робота офлайн: обмеження та обхідні шляхи
Окрема тема кейсу — робота без підключення. Liferay прямо зазначає, що висновки базуються на власному досвіді і частково на припущеннях.
З того, що команда спостерігала:
- якщо файл відкритий до втрати зв'язку, можна продовжувати працювати;
- здається, Figma ставить часові мітки на кожну зміну;
- якщо інша людина редагує той самий файл онлайн, а ви паралельно працюєте офлайн, при поверненні у мережу останні зміни перемагають — можливі конфлікти і накладання фреймів.
Практичний робочий патерн, який виробила команда:
- перед виходом офлайн (або відразу після повернення) дублювати сторінку;
- працювати тільки в копії;
- після повернення в онлайн вручну зводити зміни з «основною» сторінкою.
Такий підхід не ідеальний, але мінімізує ризик випадково стерти чи перекрити чужу роботу.
Що команда виграла і які обмеження лишилися
За підсумком кількох років міграції й шліфування процесів більшість продуктових дизайнерів Liferay працюють тільки у Figma. Частина все ще тримає старі складні Sketch прототипи, які не вигідно переносити, а окремі дизайнери іноді використовують Principle, Adobe After Effects або Framer X для задач з просунутою анімацією чи прототипів з даними.
Основні покращення для великої команди
Liferay виділяє кілька головних зон виграшу:
- Співпраця — легше ділитися напрацюваннями всередині команди і ззовні.
- Прозорість — проєкти «за замовчуванням відкриті», тож продакти, розробники й інші ролі можуть бачити прогрес без додаткових бар'єрів.
- Еволюція процесу — зменшення дистанції між дизайнерами й інженерами, перехід до більш зрілої спільної роботи.
- Операційні вигоди — один інструмент для вайрфреймів, макетів, прототипів і хендову спрощує життя фінансам, IT та менеджменту.
Для Liferay скорочення кількості підписок було суттєвим фактором, але автор прямо вказує: з огляду на те, що вартість інструментів може коливатись від «free» до понад 500 доларів на рік, економіка повинна рахуватися під конкретний контекст. Детальні ціни — на сторінці тарифів Figma.
Що залишалося слабким місцем на момент опису кейсу
Автор чесно фіксує низку недоліків Figma відносно попередніх інструментів (на момент написання статті):
- Відсутність екосистеми плагінів.
У той момент Sketch був явним лідером за розширеннями; у Figma існував web API, але без «write» можливостей. - Немає імпорту веб чи JSON даних у прототипи.
Команді бракувало аналогів до Craft або Sketch Data для роботи з реальними даними без ручного наповнення тексту. - Обмежені можливості анімації.
Інтеграція з Principle корисна, якщо є сам Principle, але базової анімації й просунутого прототипування всередині Figma не вистачало. - Недостатньо плавний офлайн-досвід.
Якщо файл не відкритий до відключення, працювати над ним офлайн не вийде — незручно для тих, хто, наприклад, вимикає ноутбук на ніч і працює в дорозі.
Відкритий підхід до дизайну: спільні Figma-ресурси
Ліферай орієнтується на open-source підхід, і цей принцип команда розширила на дизайн. Вони створили публічний Figma-проєкт з ресурсами для спільноти:
Доступ до файлів — через https://liferay.design/resources/figma. Автори планують поступово доповнювати цей набір.
Що варто взяти з кейсу Liferay для своєї команди
З досвіду Liferay можна виокремити кілька практичних висновків, корисних для великих команд:
- починати міграцію з пілоту на одній продукт-команді й паралельно документувати інфраструктуру — структуру файлів, бібліотек, naming;
- приділити увагу навігації в Figma: covers, зрозумілі назви, стандартизовані сторінки;
- виносити утиліти (редлайни, стікери, флоу-елементи) у спільні бібліотеки, а не множити сторонні інструменти;
- використовувати history Figma як простий контроль версій із короткими, осмисленими описами;
- бути реалістичними щодо обмежень офлайн-режиму та планувати обхідні шляхи на рівні процесу.
Це не універсальний рецепт для кожної організації, але послідовність кроків і зафіксовані обмеження дають реалістичну картину, як перехід на Figma може виглядати в живій великій команді.
Джерело: Paul Hanaoka – Smashing Magazine. Дата оригіналу: 2019-04-15.