1. Личный опыт конкретного рабочего кейса

2. 3 популярных подхода организации пространства

3. Декомпозиционный подход (алгоритм действий и дизайн‑процесс)

4. Выводы
   

Все дизайнеры пытаются организовать пространство фигмы для своего продукта как можно эффективнее, и все мы сталкиваемся из года в год с одними и теми же проблемами. Мой личный опыт и конкретный рабочий кейс подвигли меня начать искать самый эффективный подход в организации, хранении и поиске информации внутри фигма‑пространства.

С 2019 по 2021 я работала в ЦУМе. У нас каждый продукт лежал в своем файле и файл одного из продуктов перегрузился. Сначала он начал тормозить, когда заходили дизайнеры. Потом стал долго загружаться при открытии вообще, а в один день просто не открылся. Со мной случился страшный сон любого дизайнера. Следующую неделю я плакала вечерами и каждый день писала в поддержку Фигмы. Мне очень повезло, потому что ещё 6–7 лет назад техподдержка отвечала через реальных людей и достаточно быстро. Нам помогли с восстановлением файла. С того момента я стала постоянно искать подход, который бы пофиксил основные проблемы.

Сейчас на рынке есть три подхода организации пространства в Фигме. Я поработала в каждом из них и в каждом были свои плюсы и существенные минусы, поэтому я искала, как эти минусы можно нивелировать.

1 продукт = 1 фигма‑файл.

У нас есть продукт и он лежит в одном фигма‑файле. А все фичи разнесены по страницам этого файла.

Плюсы:

• Все лежит в одном месте.

Минусы:

• Продукт растет, масштабируется, макеты множатся, memory usage страниц увеличивается.

• Разработка не понимает, какой макет сейчас актуален.

• Изменения в дизайн‑системе проливаются на весь файл.

Фигма + софт для хранения.

• Все макеты в одном месте

• Разработка получает постоянно актуальный дизайн.

Минусы:

• Больше телодвижений с проливом макетов в сторонний софт из Фигмы.

• Memory usage в файле продолжает расти.

• Изменения в дизайн‑системе влияют на все макеты файла и мы снова теряем актуальность макетов по задачам, но уже для продактов и аналитиков.

Мастер и его бранчирование.

В фигме есть возможность создавать ветки (бранчи) от мастер‑файла и как и разработчики, использовать этот подход для актуальности макетов. 

Плюсы:

• Инструмент есть и он рабочий.

Минусы:

• Инструмент работает некорректно и можно получить проблем больше, чем пользы.

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

Как вывод по всем трём подходам — видно ряд потворяющихся проблем, с которыми сталкивается, как дизайн, так и продуктовая команда:

1. Неактуальность макетов для разработки (это очень влияет на процессы и затраты бизнеса).

2. Перегруженные фигма‑файлы, в которых растет memory usage, и они начинают тормозить или даже перестают открываться.

3. Поиск макетов по задачам для всей продуктовой команды (кроме дизайнеров, которые делают задачи) может быть затруднен и занимать много времени. Либо же продуктовая команда всё время отвлекает дизайнеров для поиска макетов.

Существуют три уровня иерархии в фигме: Пространство — Проект — Файл. Когда появились папки — это почему‑то запутало дизайнеров, хотя по факту папка — это визуализация проекта в фигме, а сама структура, как состояла из трёх уровней вложенности, так и состоит. Эту иерархию можно использовать для декомпозиционного подхода.

иерархия в Фигме

Алгоритм действий при работе в декомпозиционном подходе:

1. Заводим Пространство в фигме (Team) — это весь наш продукт.

2. Создаём проект для дизайн‑системы и там будут жить все файлы, в которых дизайн систематизирует: разные уровни переменных, базовый набор компонентов, кастомный набор компонентов (организмы), файл с мастер‑страницами. Сюда же могут уйти: файл с Сервисными компонентами, Редполитика, любые файлы со вспомогательными материалами (иллюстрации и 3D).

3. Создаём проект «Текущие задачи» — в нём будут лежать все наши текущие задачи. То есть, фигма‑файл = конкретная задача из Jira (или любой другой таск‑трекер), которую мы будем делать. В этом проекте можно сделать два шаблона: шаблон задачи и шаблон мастер‑файла, чтобы с помощью этих шаблонов автоматизировать и ускорить работу для дизайн‑команды.

4. Теперь создаём проекты под каждую фичу или микросервс в нашем продукте. В каждом проекте создадим специальный мастер‑файл, в котором будет отображён актуальный юзерфлоу фичи или микросервиса — сюда мы будем приносить все макеты по сделанным задачам и раскладывать в сценарии, чтобы продуктовая команда могла видеть актуальные флоу и быстро находить и использовать информацию в макетах.

как внутри может выглядеть проект «Текущие задачи»

Таким образом, у нас есть два основных проекта: дизайн‑система и текущие задачи, а все остальные проекты — это фичи (микросервисы), в которых уже лежат мастер‑файлы и хранятся все задачи по этой фиче (в виде файлов в архивном статусе).

организация пространства продукта в Фигме

Дизайнерский процесс выглядит следующим образом:

1. Дизайнер получает задачу в Jira.

2. Заходит в проект «Текущие задачи».

3. Создаёт в нем по шаблону новый фигма‑файл, подключает нужные файлы из ДС.

4. Оформляет задачный фигма‑файл и начинает в нём работу.

5. В названии фигма‑файла задачи указывает сначала её номер (точно также как он указан в Jira), а после номера — уже само название задачи.

6. Когда задача сделана, апрувлена вместе с постановщиком задачи, разработкой и другими участниками процесса — в задаче меняется статус на обложке, все макеты лежат на странице For Dev, а задача остается в проекте «Текущие задачи», пока разработка не реализует её на прод, а дизайн не подтвердит через дизайн‑ревью, что всё корректно исполнено разработкой.

7. Когда задача в разработке закрыта и наш дизайн в проде, то задача считается закрытой: дизайнер, ответственный за эту задачу меняет ей статус, переносит фигма‑файл с задачей в проект соответсвующей фичи или микросервиса, а макеты из задачного файла копирует и переносит в нужный флоу мастер‑файла. Статус задачи после переноса в нужный проект меняется в обложке на Archive.

ВАЖНО: статусная модель работы с задачными файлами не может смотреть в статусную модель доски отдела дизайна, потому что затрагивает итерации работы других отделов (например, разработки и QA).

Например, у нас статусная модель для задачных файлов была такая: In progress, Ready for Dev, Design review, Freeze, Closed, Archive.

• In progress — задача сейчас на дизайне.

• Ready for Dev — задача от дизайна передана в разработку.

• Design review — задача проверяется дизайном на предмет качества исполнения в разработке.

• Freeze — задача по какой‑то причине на «стопе» по требованию бизнеса.

• Closed — задача закрыта и пока ещё лежит в проекте «Текущие задачи», но готова к переносу в проект соответствующей фичи или микросервиса.

• Archive — задача перенесена в проект своей фичи и закрыта.

слева шаблон мастер‑файла, справа — шаблон файла‑задачи

Плюсы подхода:

• Актуальность всех макетов всегда идеально сохраняется для разрабоки, потому что когда дизайн закончил с задачей и передал дальше — в разработку, файл с задачей не открывается и никакие изменения в него не проливаются.

• Все задачи легко искать по номеру в поиске Фигмы и файлы с задачами всегда совпадают с номерами задач в Jira.

• Все мастер‑файлы максимально подробно, сразу на макетах, показывают все флоу продуктовой команде и эти флоу всегда актуальны.

• Вся продуктовая команда знает, куда в Фигме ходить — у команды есть «Текущие задачи» и мастер‑файл каждой фичи.

• Файлы не перегружаются и memory usage не улетает в стратосферу. Исключением может стать мастер‑файл фичи, но это случится не скоро, а когда файл начнёт перегружаться — разнесите юзерфлоу на несколько страниц — это увеличит жизнь мастер‑файлу и даст возможность с ним комфортно работать.

Минусы подхода:

• Требуется дополнительное время для поддержания порядка (примерно час работы каждого дизайнера раз в спринт).

• Требуется время команде дизайна, чтобы привыкнуть к такой системе: в среднем от 2 до 4 спринтов в новом подходе. Также поддержание порядка в Фигме нужно заложить отдельной задачей в спринт, чтобы контролировать время и напоминать дизайнерам про необходимость определённых действий в конце спринта.