Декомпозиционный подход (алгоритм действий и дизайн‑процесс)
Все дизайнеры пытаются организовать пространство фигмы для своего продукта как можно эффективнее, и все мы сталкиваемся из года в год с одними и теми же проблемами. Мой личный опыт и конкретный рабочий кейс подвигли меня начать искать самый эффективный подход в организации, хранении и поиске информации внутри фигма‑пространства.
Личный опыт и конкретный рабочий кейс
С 2019 по 2021 я работала в ЦУМе. У нас каждый продукт лежал в своем файле и файл одного из продуктов перегрузился. Сначала он начал тормозить, когда заходили дизайнеры. Потом стал долго загружаться при открытии вообще, а в один день просто не открылся. Со мной случился страшный сон любого дизайнера. Следующую неделю я плакала вечерами и каждый день писала в поддержку Фигмы. Мне очень повезло, потому что ещё 6–7 лет назад техподдержка отвечала через реальных людей и достаточно быстро. Нам помогли с восстановлением файла. С того момента я стала постоянно искать подход, который бы пофиксил основные проблемы.
3 популярных подхода организации пространства
Сейчас на рынке есть три подхода организации пространства в Фигме. Я поработала в каждом из них и в каждом были свои плюсы и существенные минусы, поэтому я искала, как эти минусы можно нивелировать.
1 подход
1 продукт = 1 фигма‑файл.
У нас есть продукт и он лежит в одном фигма‑файле. А все фичи разнесены по страницам этого файла.
Плюсы:
Все лежит в одном месте.
Минусы:
Продукт растет, масштабируется, макеты множатся, memory usage страниц увеличивается.
Разработка не понимает, какой макет сейчас актуален.
Изменения в дизайн‑системе проливаются на весь файл.
2 подход
Фигма + софт для хранения.
Продукт может жить в одном фигма‑файле, как и в 1 подходе, но к нему прикрепляется софт для хранения макетов в виде картинок, например, Zeplin. Дизайн выливает макеты в Цеплин из Фигмы, разработка смотрит только в Цеплин.
Плюсы:
Все макеты в одном месте
Разработка получает постоянно актуальный дизайн.
Минусы:
Больше телодвижений с проливом макетов в сторонний софт из Фигмы.
Memory usage в файле продолжает расти.
Изменения в дизайн‑системе влияют на все макеты файла и мы снова теряем актуальность макетов по задачам, но уже для продактов и аналитиков.
3 подход
Мастер и его бранчирование.
В фигме есть возможность создавать ветки (бранчи) от мастер‑файла и как и разработчики, использовать этот подход для актуальности макетов.
Плюсы:
Инструмент есть и он рабочий.
Минусы:
Инструмент работает некорректно и можно получить проблем больше, чем пользы.
Дизайнеры могут путаться в бранчировании и допускать ошибки в рабочем процессе, а потому терять часть данных и соответвенно — время на их восстановление.
Как вывод по всем трём подходам — видно ряд потворяющихся проблем, с которыми сталкивается, как дизайн, так и продуктовая команда:
Неактуальность макетов для разработки (это очень влияет на процессы и затраты бизнеса).
Перегруженные фигма‑файлы, в которых растет memory usage, и они начинают тормозить или даже перестают открываться.
Поиск макетов по задачам для всей продуктовой команды (кроме дизайнеров, которые делают задачи) может быть затруднен и занимать много времени. Либо же продуктовая команда всё время отвлекает дизайнеров для поиска макетов.
Декомпозиционный подход
Иерархия в Фигме
Существуют три уровня иерархии в фигме: Пространство — Проект — Файл. Когда появились папки — это почему‑то запутало дизайнеров, хотя по факту папка — это визуализация проекта в фигме, а сама структура, как состояла из трёх уровней вложенности, так и состоит. Эту иерархию можно использовать для декомпозиционного подхода.
Алгоритм действий при работе в декомпозиционном подходе:
Заводим Пространство в фигме (Team) — это весь наш продукт.
Создаём проект для дизайн‑системы и там будут жить все файлы, в которых дизайн систематизирует: разные уровни переменных, базовый набор компонентов, кастомный набор компонентов (организмы), файл с мастер‑страницами. Сюда же могут уйти: файл с Сервисными компонентами, Редполитика, любые файлы со вспомогательными материалами (иллюстрации и 3D).
Создаём проект «Текущие задачи» — в нём будут лежать все наши текущие задачи. То есть, фигма‑файл = конкретная задача из Jira (или любой другой таск‑трекер), которую мы будем делать. В этом проекте можно сделать два шаблона: шаблон задачи и шаблон мастер‑файла, чтобы с помощью этих шаблонов автоматизировать и ускорить работу для дизайн‑команды.
Теперь создаём проекты под каждую фичу или микросервс в нашем продукте. В каждом проекте создадим специальный мастер‑файл, в котором будет отображён актуальный юзерфлоу фичи или микросервиса — сюда мы будем приносить все макеты по сделанным задачам и раскладывать в сценарии, чтобы продуктовая команда могла видеть актуальные флоу и быстро находить и использовать информацию в макетах.
Таким образом, у нас есть два основных проекта: дизайн‑система и текущие задачи, а все остальные проекты — это фичи (микросервисы), в которых уже лежат мастер‑файлы и хранятся все задачи по этой фиче (в виде файлов в архивном статусе).
Дизайнерский процесс выглядит следующим образом:
Дизайнер получает задачу в Jira.
Заходит в проект «Текущие задачи».
Создаёт в нем по шаблону новый фигма‑файл, подключает нужные файлы из ДС.
Оформляет задачный фигма‑файл и начинает в нём работу.
В названии фигма‑файла задачи указывает сначала её номер (точно также как он указан в Jira), а после номера — уже само название задачи.
Когда задача сделана, апрувлена вместе с постановщиком задачи, разработкой и другими участниками процесса — в задаче меняется статус на обложке, все макеты лежат на странице For Dev, а задача остается в проекте «Текущие задачи», пока разработка не реализует её на прод, а дизайн не подтвердит через дизайн‑ревью, что всё корректно исполнено разработкой.
Когда задача в разработке закрыта и наш дизайн в проде, то задача считается закрытой: дизайнер, ответственный за эту задачу меняет ей статус, переносит фигма‑файл с задачей в проект соответсвующей фичи или микросервиса, а макеты из задачного файла копирует и переносит в нужный флоу мастер‑файла. Статус задачи после переноса в нужный проект меняется в обложке на 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 спринтов в новом подходе. Также поддержание порядка в Фигме нужно заложить отдельной задачей в спринт, чтобы контролировать время и напоминать дизайнерам про необходимость определённых действий в конце спринта.
Выводы
Описанный выше декомпозиционный подход был опробован мной на практике в VK и доказал свою продуктивность: обратная связь от разработки и QA была не просто положительной, вся команда смогла зафиксировать в своих процессах увеличение эффективности и скорости работы. Подход повлиял, как на скорость коммуникации в команде продукта, так и на ускорение поставки задач дизайна и разработки. Вся продуктовая команда дала максимально положительный фидбек. Также этим подходом пользуются некоторые команды из других компаний, где я проводила лекторий и рассказывала про декомпозиционный подход — обратная связь также была положительной, коллеги говорят про увеличение скорости в процессах и в поставке задач.
Отдельные благодарности хочу выразить Насте Харитоновой за полезный ликбез по проблеме в 2020-м году, а Богдане Кибза — за мини‑консультацию в 2022-м году.
