Волшебная организация файлов в Figma

Всем салют, меня зовут Филипп Пронь, я Head of Design в Кошельке. В статье я поделюсь тем, как было реорганизовано пространство в фигме Кошелька. Это не пилюля от всех возможных проблем, но базовые принципы, которые помогут сформировать пространство и навести порядок в файлах так, как будет удобно именно вашей команде. Поехали!

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

• Где лежит макет?
• Кто ответственный?
• Этот макет актуальный?
• Этот компонент на проде?
• О чём эта задача?

Мы провели исследования, выделили основные проблемы и начали оптимизировать пространство. Давайте посмотрим, что у нас получилось.

У Кошелька несколько продуктовых команд и команда платформенной разработки. При этом у нас используется погружённый способ организации команды, когда дизайнер находится внутри продуктовой команды. Вследствие чего у каждого дизайнера было всего два файла: файл с песочницей, где он экспериментировал и хранил драфты, и мастер-файл с финальными фичами. Это было похоже на олдскульное хранение макетов в Скетче, где внутри одного файла хранилось абсолютно всё. Из этого вытекало много проблем:

• сложно найти нужную фичу;
• обновление библиотеки компонентов могло поломать целые куски флоу;
• не было возможности поделиться ссылкой на конкретную фичу, ведь в одном файле лежало абсолютно всё.

Первым делом у каждой команды появилась своя папка с проектами в общем пространстве фигмы. Выглядит это так:

На каждую задачу — отдельный файл с понятным названием.

Мы перестали хранить в одном файле макеты разных фичей, даже на разных страницах файла. Это плохая история, потому что со временем файл начинает дольше грузиться и медленнее работать. Мы достали из мастер-файла фичи и разбили их на отдельные файлы с понятными и логичными названиями, например: «модуль защиты входа» или «управления картами». Это упростило поиск по фичам в папке команды. Конечно, могут быть задачи, где по итогу добавляется всего пара-тройка экранов, в таком случае они включаются в уже существующий флоу фичи. Тут главное знать меру.

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

Для того чтобы дизайнер другой команды, менеджер или разработчик понимали, о чём речь, в задаче мы добавили карточку проекта. Она помогает погрузиться в проблематику и условия задачи, а также пройти дизайн-чек (проверка решения другими дизайнерами с получением апрувов для передачи в разработку).

Карточка состоит из следующих основных пунктов:

• Задача — какую проблему решаем для бизнеса, а какую — для клиента
• Метрики — как поймём, что решили задачу
• Гипотезы — как будем решать задачу и проверять свои гипотезы
• Компоненты — какие компоненты появились впервые, а какие нуждаются в доработке

Чтобы дизайнер мог проверять себя перед выходом на дизайн-чек, мы составили чеклист. Заполнив его можно, например, понять: добавлены ли крайние состояния, верно ли использованы цвета, настроены ли констрейнты с автолейаутами и так далее.

У всех файлов должна присутствовать обложка с информацией:

• Название фичи или задачи
• Ответственный дизайнер
• Команда, которая будет разрабатывать фичу

Статус фичи:

• В работе — в процессе проектирования
• Дизайн-чек — фича спроектирована и передана на проверку дизам
• Ожидает разработки — макеты прошли дизайн-чек и ожидают разработки
• В разработке — макеты переданы в разработку
• Реализовано — фича реализована
• Не актуально — разная архивная ветошь

Информативная обложка (как и файл с понятным названием) упрощает поиск:

Это самая дискуссионная тема и предмет частых холиваров, тем не менее нам удалось зафиксировать правила, которые работают для нас:

• По горизонтали размещаем главные переходы между экранами, по вертикали — переходы внутри экранов либо корнер-кейсы;
• Отступы между экранами по горизонтали и вертикали — 160 px (этого достаточно даже чтобы уместить карточки с комментариями);
• Каждый новый флоу размещаем ниже, отступы между флоу — 480px;
• Нумеруем экраны согласно их порядку во флоу (1.1, 1.2, 2.1.1, 2.1.2 и так далее).

Для наглядного примера даю ссылку на наш шаблон в Figma. Его можно использовать как отправную точку для любого проекта.

Есть отличная статья на тему нумерации макетов — 5 иксов или как удобнее вести дизайн макет. Суть в том, что все экраны нумеруются уникальным кодом и существуют, как правило, в единичном экземпляре. Так проще идентифицировать экран, что упрощает жизнь всем, в том числе аналитикам и разработчикам. Можно просто назвать номер экрана, и все будут понимать, о чём конкретно идёт речь.

Переходы между экранами и состояниями добавляем, используя плагин Autoflow. Он позволяет быстро отобразить необходимые связи между макетами. Стрелки с переходами помогают без использования прототипа понять принцип работы интерфейса.

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

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

Для легкой ориентации в слоях следим за их названиями, например: «Content», «Text», «Description», а не «Frame 1532». Также следим, чтобы в макете не было ничего лишнего — никаких скрытых или лишних папок и слоёв, которые могли бы мешать при работе с компонентами.

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

Нам еще есть куда стремиться, но уже сейчас такая реорганизация пространства и файлов помогла оптимизировать работу команды. Файлы ищутся без проблем, в любой момент можно узнать все нужные подробности по задаче. В целом выросли уровень дизайн-гигиены и аккуратность сборки макетов.

Это базовые принципы формирования структуры, которые помогают поддерживать порядок в рабочем пространстве фигмы и дизайн-макетах. В зависимости от процессов в вашей компании структура пространства может различаться. Например, могут появиться подпространства под каждую продуктовую команду, а внутри — разбивка дизайн-процесса по папкам («в работе», «на чеке», «в разработке»). Или, может, вам захочется класть рядом с карточкой проекта интерактивную карту разделов при работе с большими фичами. Если есть еще идеи по оптимизации, делитесь в комментариях ✌🏻