Архітектура дизайну в Figma — допомога продуктовій команді

Привіт! Мене звати Олександр, працюю Senior Product Designer в українській продуктовій студії Railsware. Нещодавно був радий виступити на DOU Meetup та поділитись своїм десятирічним досвідом в дизайні. Та, щоб детальніше зануритися в тему і більше розповісти про наші особисті виклики та рішення, зібрав детальнішу інформацію тут.

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

На прикладі того, як ми в проєкті Coupler.io впорядкували архітектуру дизайну, поділюся знайденими рішеннями та підходами.

Детальніше про співпрацю при розробці продуктів

Продукт, над яким я працюю, по суті ціла екосистема — і застосунок, і розширення для G-Suite, і десятки різних дешбордів, і маркетинговий вебсайт, і чимало інших промоматеріалів. Щоб все це не перетворилося на зоопарк, потрібні колективні зусилля та спільне розуміння. Поєднання різних експертиз може працювати ефективно як у парних, так і у командних форматах. Як це зазвичай виглядає?

На початковому етапі маркетологи генерують ідеї для нових модулів продукту та лендингів. І вже зі сформульованою потребою надсилають запити дизайнерам для подальшої розробки. Іноді продакт-менеджери також можуть напряму передавати запити.
Отримавши реквест, дизайнери збирають флоу та готують компоненти для майбутньої реалізації, при цьому постійно підтримуючи цілісність дизайн-файлів.
Паралельно інженери разом з продакт-менеджерами планують розвиток модулів продукту. У нашому випадку, деякі автономні, а деякі взаємозалежні між собою. Тому команди користуються компонентами системи (токенами) для стандартизації та спрощення процесу.
Якщо залучені підрядники, то вони також активно взаємодіють, імплементуючи функції, розроблені дизайнерами, та використовуючи компоненти системи для забезпечення єдності та ефективності.

Коли спеціалістів багато — це класно, адже так ви можете створити справді крутий продукт. Утім, чим більше людей, тим важливіша структура та злагодженість. І на прикладі Figma легко побачити, як все може перетворитися на хаос. Ось, наприклад, як виглядала наша Figma на етапі «до». Купа файлів, названих як попало, чимало сміття Do-not-use, відсутність обкладинок...

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

До чого призводить хаос у Figma

Які проблеми ми побачили у себе?

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

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

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

Складно дати доступи третій стороні. Коли вся важлива інформація знаходиться в одному місці (pun intended), ділитись потрібною задачею з підрядником стає справжнім челенджем. Адже не до всіх матеріалів можете дати доступ.

У файлах збирається купу незрозумілих речей. Без чіткого регламенту, як працювати з файлами, починається плутанина. Маркетологи додають щось своє, а дизайнери — зовсім інше. Зрештою зорієнтуватися в такому документі надзвичайно важко. Особливо, коли повертаєшся з відпустки через декілька днів.

Неясно, як користуватись. Якщо файл створений незрозуміло, у колег (а тим паче новачків) забирає багато часу, щоб знайти конкретні елементи. А ще випадково чи ні можна накапостити у створеному матеріалі.

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

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

Як забезпечити співпрацю без стресу

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

До яких розв’язань кожної проблеми ми зрештою прийшли?

Виклик № 1: Що робити замість одного файлу

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

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

Виклик № 2: Різні документи = різні доступи

Коли вже є окремі теки та файли, час розібратися з доступами. Просте правило: «можна лише туди, куди треба». Умовно, якщо в команді є люди, які працюють лише над YouTube-контентом, — то і доступ їм необхідний лише на відповідну теку.

Тому почніть з того, щоб ретельно розподілити доступ до окремих тек серед колег, які насправді потребують цих матеріалів. Особливо важливо це враховувати у контексті різних планів використання Figma. Знаю, у вас може бути обмежена кількість користувачів, які можуть редагувати, тому раджу уважно переглянути права користувачів. Враховуючи потреби кожного учасника, надавайте відповідний рівень доступу (edit чи viewer), щоб кожен міг зручно працювати з матеріалами.

Опціонально, для менших бюджетів, можна створити спільний акаунт для команди, якщо немає потреби постійно користуватися Figma. Умовний юзер Your_product_marketing — і кому треба, входить, редагує і вилогінюється.

Виклик № 3: Як орієнтуватись команді

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

Що допомогло нам?

Ми часто додаємо лого багатьох сторонніх застосунків, тому створили окрему бібліотеку з ними. Швидко, зручно, уніфіковано.
Зробили окремий медіакіт з логотипами, кольорами, шрифтами та теку з шаблонами презентацій. Скоріш за все, ваші партнери не знатимуть про правильні шрифти чи кольори, тому допоможіть їм знайти це без зайвих зусиль.
Наш продукт — про дані, тож колеги часто працюють з PowerBI та Looker Studio. Для наших дата-аналітиків, які там створюють дешборди, розробили спеціальний UI-кіт, щоб вони знали, які елементи та яким чином використовувати.

Розширю останній пункт. Імовірно, з вашим продуктом працюють колеги, далекі від дизайну та Figma. Хорошою ідею буде не лише створити для них окрему добірку матеріалів, але й час від часу проводити мініворкшопи чи тренінги по їхньому використанню. Багато вашого часу не забере, а користі принесе чимало — як мінімум, краще порозуміння з колегами.

Виклик № 4: Як стандартизувати файл

Швидше за все, ваш основний процес змішується з ідеями та скриншотами референсів. Щоб уникнути цього, можна створити різні версії завдань в одному файлі. Кожна версія повинна мати відповідну назву, щоб кожен член команди міг легко знайти потрібне завдання. Також ми почали називати кожен процес відповідно до його епіків. Важливо стандартизувати формат, щоб будь-яка команда могла зрозуміти файл незалежно від етапу процесу.

Окремо можна винести «пісочниці», де фахівці експериментуватимуть — а творчість не буде змішуватися з іншими процесами.

Наводимо порядок

Пропишіть правила неймінгу та обкладинок: Наприклад, у вас є файл з дизайном вебсторінки. Ви встановлюєте правило, що кожен елемент має бути названий згідно з його функцією або місцем використання на сторінці. Також створюйте обкладинки для кожного проєкту з уніфікованим дизайном — так ви не загубитеся на головній сторінці.
За потреби, використовуйте кольорове кодування для різних частин продукту, а саме: аппки, маркетингу, аддону. Як я казав, наш проєкт складається з кількох сутностей, тому у нас це виглядає десь так:

Дайте інженерам можливість бачити взаємозалежність екранів: наприклад, через прототипи. Ви створюєте зв’язки між екранами, щоб інженери побачили взаємодію між ними. Також раджу регулярно оновлювати ці зв’язки під час внесення змін у дизайн.
Створіть окремі борди для маркетологів. Наприклад, окремий борд, де вони можуть зберігати свої ідеї, замітки та промоматеріали. Там само вони можуть обговорювати стратегії маркетингу та внесені зміни.
Проводьте регулярні зустрічі для синхронізації. Наприклад, регулярно мітинги дизайнерів з усією командою, щоб переглянути прогрес проєкту, розв’язати проблеми та спланувати наступні кроки. Це хороший час для питань та пропозицій, а також апдейтів по архітектурі дизайну.

Висновок

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