Грамотна організація файлів у Figma – більше, ніж просто гарна звичка. Вона допомагає зробити спільну роботу ефективнішою, оптимізувати робочі процеси та підвищити загальну продуктивність команди. У цій статті дизайнер компанії Bolt ділиться своїми спостереженнями та порадами з цього приводу.
Основні труднощі між дизайнерами і розробниками
- Висока деталізація vs функціональність. Дизайнери часто намагаються зробити все ідеально: ретельно вибудовують лейаут, вирівнюють елементи – важливий кожен піксель! Розробники ж ставлять в основу функціональний код, який легко буде підтримувати. Розбіжність пріоритетів може стати причиною непорозуміння.
- Технічні обмеження. Дизайнери не завжди знають про технічні обмеження (і не завжди цікавляться цим питанням, хоча мають), тому розробники можуть або відхилити макет, або спробувати знайти компроміс.
- Термінологія. Іноді дизайнери та розробники використовують різний професійний сленг. Наприклад, слово «компонент» може означати для кожного щось своє, і це призводить до плутанини.
- Петлі зворотного зв'язку. У таких інструментах, як Figma, комунікація не завжди є синхронною (миттєвий зворотний зв'язок), що призводить до затримок та непорозуміння.
- Контроль версії. У Figma над одним і тим самим дизайном можуть одночасно працювати кілька людей. Така гнучкість може спричинити неузгодженість.
- Специфікації та процес передачі файлів. Перевести дизайн на код не так просто. Важливо пам'ятати про анімацію, переходи та чуйність.
- Узгодження та затвердження. Іноді неясно, хто повинен затверджувати конкретні функції чи елементи дизайну.
Наша команда у Bolt не була винятком. Під час роботи над Bolt Business (сервіс для організації корпоративних поїздок) мені стало очевидним, що подібні розбіжності викликають головний біль у розробників, продакт-менеджерів і самого дизайнера. Щоб зробити нашу взаємодію більш плідною та приємною, я почав вивчати, як інші команди вирішують аналогічні проблеми.
В результаті я створив це коротке керівництво.
Моя головна мета – допомогти дизайнерам ефективно взаємодіяти з усіма стейкхолдерами, які беруть участь у процесі проєктування, а також:
- Підвищити видимість статусу проєкту та внесених змін;
- Поліпшити комунікацію усередині команди.
Як організувати проєкти, файли та сторінки у Figma
Декілька порад про те, як групувати проєкти, оптимізувати структуру файлів і організувати робочий процес, щоб спростити спільну роботу в Figma.
Проєкти
У Bolt ми розподіляємо файли за проєктами. Кожен із них присвячений певному продукту чи напрямку діяльності. Наприклад, Bolt Business (корпоративні поїздки), Ride-Hailing (таксі), Food (їжа), Marketing (маркетинг) тощо.
Що нам дає такий підхід:
- Простіша навігація у Figma. Коли всі файли розміщені всередині окремих проєктів, їх легко знайти.
- Контрольований доступ. У всіх, хто бере участь у роботі над продуктом чи напрямком, можуть бути різні ролі та обов'язки. Коли файли сегментовані, простіше контролювати, хто матиме доступ до них.
- Гнучкість. Кожен продукт або напрямок може мати свій UI-набір або дизайн-систему, що відображають його специфіку.
- Паралельна розробка. Команди можуть працювати над окремими проєктами одночасно, не чекаючи один одного. Це великий плюс для будь-якої великої організації.
Однак я виявив і кілька недоліків такого підходу:
- Розрізненість. Коли одна команда нічого не знає про роботу іншої, це може призвести до дублювання завдань та неузгодженості різних напрямків чи продуктів.
- Відсутність консистентності — як у дизайні, і у досвіді взаємодії.
- Додаткові витрати. Одночасне використання елементів дизайну в декількох проєктах вимагає додаткових зусиль і часу.
- Проблеми з версіонуванням. Коли компонент використовується у кількох проєктах, підтримувати його у актуальному стані може бути непросто.
- Онбординг. Крос-функціональним командам та новим членам команди буває важко знайти файли, які відносяться до кількох напрямків, і отримати загальне уявлення про всі проєкти.
- Управління ресурсами (асетами). Глобальні ресурси (іконки, ілюстрації тощо) вимагають централізованого управління.
Файли
Figma-файли знаходяться всередині проєктів і зазвичай відносяться до конкретних користувачів сценаріїв, наприклад, Вхід до системи, Реєстрація, Пошук, Замовлення, Налаштування і т.д.
Такий підхід дозволяє розмістити матеріали досить компактно, але показати загальну картину. Він також прискорює завантаження за рахунок зменшення кількості сторінок та шарів у кожному файлі. Дизайнери та розробники можуть сфокусуватись на конкретному сценарії, не відволікаючись на інші макети.
✏️ Набір шаблонів — додатковий файл
Хайко, керівник відділу дизайну продуктів, довірив мені та моєму колезі Олександру розробку нашого дизайн-набору під назвою Kalep.
Основна мета – створити єдину мову дизайну та централізоване сховище компонентів, які можна буде використовувати у різних веб-проєктах Bolt.
Взявшись до роботи, ми помітили, що нам потрібна якась проміжна ланка між Kalep та дизайн-файлами, які ми використовуємо на щоденній основі. Продукти та напрямки діяльності Bolt настільки різноманітні, що Kalep просто не зможе охопити їх усі. Тому ми додали до своїх Figma-проєктів набори шаблонів.
Набори шаблонів містять усі загальні шаблони та окремі компоненти для конкретного продукту чи напрямку, наприклад панелі навігації, бічні меню тощо. Вони забезпечують однаковість та актуальність усіх макетів усередині проєкту.
🏖️ «Пісочниця» - додатковий файл
«Пісочниця» – простір, де дизайнери можуть вільно експериментувати, тестувати нові ідеї, працювати над окремими завданнями та досліджувати компоненти дизайну перед тим, як передати їх у розробку. Завдяки «пісочниці» інші файли залишаються організованими і акуратними.
Такий підхід дозволяє швидко ділитися своїми начерками та ідеями із стейкхолдерами та отримувати від них зворотний зв'язок. Крім того, вона запобігає випадковому видаленню або зміні елементів в основних файлах.
Сторінки
Як правило, файли складаються з кількох сторінок. Нині ми не маємо спільних рекомендацій щодо їхньої структури. Її визначає сам дизайнер.
Головне, дотримуватись єдиного шаблону іменування. Ось кілька хороших варіантів:
- Послідовне найменування. Допомагає організувати сторінки в хронологічному порядку або відповідно до сценарію користувача. Наприклад, 01_Home, 02_About, 03_Contact / 01_Головна, 02_Про_нас, 03_Контакти.
- За сценаріями чи модулями. Наприклад: Onboarding, Search, Settings/Онбординг, Пошук, Налаштування.
- За алфавітом. Це ефективний спосіб підвищити зручність пошуку.
- Папки забезпечують ієрархічну організацію, що є особливо важливим для складних проєктів. Приклад: Портал підтримки/..., Реєстрація/Мобільна версія тощо.
- Закріплені сторінки. Важливі сторінки можна зафіксувати у верхній частині списку.
- Мета-сторінка. Ви можете додати до файлу сторінку з посиланнями (наприклад, Readme) на всі інші сторінки.
Фрейми
Щоб спільна робота була ефективною, робочий простір має залишатися чистим та зручним. Правильно організований файл легше зрозуміти, що прискорює проєктування та розробку.
Ці прийоми допомагають підтримувати порядок на сторінках:
- Описові назви та нумерація. Ідентифікуйте кожен кадр відповідно до його призначення або змісту. Наприклад, «Оформлення замовлення / Зміна адреси», «Оплата / Додавання способу оплати» тощо. Уникайте заголовків на кшталт Frame 1251, Frame 1347813.
- Розділи та підрозділи. Групуйте зв'язані кадри всередині секцій під назвою, наприклад, «Обліковий запис користувача».
- Теги, колірне кодування, емодзі. Ви також можете використовувати кольори, теги та емодзі для позначення поточного статусу кадру, наприклад «На розгляді», «Затверджено», «У роботі» тощо.
Ось які статуси я використовую у Figma найчастіше:
- Експерименти: Малюнки та ідеї, які не йдуть у розробку.
- Дослідження: Будь-які матеріали, пов'язані з дослідженнями, проведеними у рамках проєкту: діаграми, схеми, скриншоти тощо.
Порада: Якщо зображень дуже багато, краще розмістити їх в окремому файлі або стиснути. Наприклад, плагін TinyImage Compressor від Hypermatic дозволяє стискати зображення прямо у Figma. Якщо ви все ж таки вирішили перенести їх в окремий файл, дотримуйтесь тих же правил іменування, але додайте в кінці "-Research".
- Прототип: Якщо ви хочете протестувати складну взаємодію або кілька сценаріїв, краще розмістити прототипи на окремій сторінцію.
- У роботі: Те, над чим ви зараз працюєте. Ці макети змінюватимуться.
- A/B тестування: Дизайн готовий. Він знаходиться на стадії розробки або вже розроблений та проходить A/B-тестування. Після того, як тестування закінчиться, його слід перемістити до секції «Архів» або «Готово» залежно від отриманих результатів.
- Архів: Cюди потрапляє дизайн, який не виправдав очікувань.
- Готово: Тут розміщуються макети, які вже реалізовані або готові до розробки (якщо не потрібно тестування).
Анотації
Примітки або анотації – чудовий спосіб підвищити ефективність комунікації всередині команди. Їх можна додавати до окремих елементів, кадрів або сценаріїв, щоб надіслати додаткову корисну інформацію.
Переваги анотацій:
- Більш зрозумілий контекст. Ми можемо пояснити, чому вибрали те чи інше рішення/як мають функціонувати певні елементи.
- Оптимізований цикл зворотного зв'язку. Завдяки анотаціям зворотний зв'язок зберігається безпосередньо у файлі Figma, а не у зовнішніх джерелах. Це дозволяє прискорити ітерацію.
- Менше непорозуміння. Розробники відразу бачать наші інструкції/вимоги до конкретних компонентів.
- Централізована комунікація. Скорочується обсяг зовнішньої документації, розкиданої різними платформами.
- Спрощується процес передачі файлів розробникам. Розробники можуть швидко повернутися до приміток та пояснень, якщо у них виникнуть будь-які питання.
- Документування проектних рішен. Можна посилатися на інструкції при подальшому обговоренні дизайну.
Ви можете знайти відмінні набори анотацій (Annotation Kits) в спільноті Figma, а можете скачати наш - Note Figma Kit .
Висновок
Я на власному досвіді переконався, який величезний вплив на успіх проєкту може зробити продумана структура файлів. Чим краще організований наш робочий простір, тим більше часу та енергії ми можемо присвятити тому, що справді важливо: створенню естетичного, зручного дизайну.
