Организация пространства в фигме

В статье я расскажу, как мы организуем пространство в Figma в нашей компании "Бинет". Вы узнаете, как мы формируем файлы, управляем вкладками и обеспечиваем согласованное взаимодействие между дизайнерами, разработчиками и проектными менеджерами.

Всем привет! Меня зовут Лиля, и я старший дизайнер в компании по разработке мобильных приложений — Бинет. Мы работаем как с крупными приложениями (с более чем 500 экранами), так и с небольшими проектами.

bnet.su

Бинет мобильная разработка

Разработка мобильных приложений iOS | Android

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

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

Ну что, начнем!

ㅤ

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

Все файлы, включая наши рабочие, клиентские и черновики, а также файлы из Figma Community, были собраны в общей папке "Draft".

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

Но даже если вам удается найти нужный файл, при открытии вы сталкиваетесь с множеством вкладок и десятками макетов. Как же найти нужное?

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

ㅤ

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

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

В следующих разделах я более подробно поделюсь нашими решениями и принятыми мерами.

ㅤ

Создание проекта

Когда я приступила к наведению порядка, мой первый шаг заключался в создании отдельной папки для каждого проекта. Внутри каждой папки проекта у нас минимум два основных файла: “Work” и “Client”.

Файл “Work” служит рабочим пространством для дизайнеров, разработчиков и проджект-менеджеров. В нем мы храним:

Согласованные макеты для iOS и Android;
UI kit;
Экраны для релиза;
Черновики и т.п.

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

ㅤ

Файл “Client” предназначен для выгрузки черно-белых вайрфреймов, кликабельных прототипов, согласованных макетов, UI Kit и других элементов, требующих утверждения со стороны клиента или уже получивших его одобрение.

ㅤ

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

ㅤ

Обложки проектов

На следующем этапе улучшения наших процессов я создала общий шаблон для обложек проектов. Вот пример:

Цвет обложки соответствует корпоративному стилю проекта;
Название проекта выделено крупным шрифтом;
В папке проекта находятся два основных файла, а также дополнительные, при необходимости;
У каждого типа файлов есть своя иконка, чтобы легко ориентироваться в структуре папок.

ㅤ

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

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

ㅤ

Структура вкладок в файле

В файле “Work” дизайнер свободен в создании нужного количества вкладок, так как фигма – это его рабочая область.

Тем не менее, это пространство взаимодействует с рабочей средой разработчиков и менеджеров проектов. Чтобы облегчить доступ к нужным макетам для всех членов команды, мы выделили три основные вкладки: "Макеты (iOS)", "Макеты (Android)" и "UI Kit". Они всегда находятся в самом верху в каждом файле "Work" во всех проектах.

На этих трех основных вкладках мы размещаем только утвержденные клиентом макеты, исключая варианты и черновики. Вкладки iOS и Android содержат макеты со всеми сценариями и функционалом приложения.

Ниже пример структуры вкладок в файле проекта:

Расположение экранов

Экраны в проекте имеют определенную структуру.

Слева крупно пишется название раздела, справа – все экраны, относящиеся к конкретному разделу (даже если их будет 100 штук, они все равно идут горизонтальным списком).

ㅤ

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

ㅤ

Название макетов

Сами экраны должны иметь нумерацию и название в левом верхнем углу фрейма.

Номер экрану прописывается по следующему шаблону: хх.yy.zz., где xx – номер раздела, к которому относится экран (раздел то, что указано названием слева); yy – номер конкретного экрана данного раздела; zz – номер состояния конкретного экрана данного раздела.

Иногда в нумерацию можно добавлять еще одно число, и тогда алгоритм будет такой: хх.yy.zz.ww, где с помощью “ww” мы обозначаем состояние состояния.

Каждому экрану должны быть прорисованы и прописаны все возможные состояния.

ㅤ

Давайте разберемся, как мы пронумеровали экраны в нашем приложении.

Хотелось бы отметить, что приведен лишь пример для общего понимания, и не все состояния экранов представлены.

Первый раздел приложения - это “Онбординг”, поэтому самая первая цифра слева “01”.

Далее вторая цифра также “01”, так как это первый экран в этом разделе.

Поскольку у “Онбординга” по сути всего один экран с небольшими изменениями, то первые две цифры остаются прежними, меняется только третья цифра, указывающая на состояние данного экрана.

Далее идет раздел “Авторизации/Регистрации”, который является вторым разделом приложения, и поэтому самая первая цифра слева “02”. Первым экраном в этом разделе является экран приветствия и выбора способа входа, поэтому у него вторая цифра “01”.

Затем идет экран ввода номера телефона, который является вторым экраном в данном разделе, поэтому вторая цифра “02”.

Поскольку состояния экрана ввода номера телефона меняются, то третья цифра также изменяется.

И следующим шагом идет экран ввода кода подтверждения. Итак, “02” - номер раздела, “03” - номер экрана в данном разделе, и третья цифра обозначает различные состояния этого экрана.

ㅤ

В результате взаимодействие внутри команды стало гораздо удобнее.

Теперь каждый знает, где найти нужные файлы и макеты;
У папок, файлов и вкладок единая структура наименований;
Если необходимо проверить дизайн-решения, то дизайнеры просто указывают номер макета, и разработчики могут быстро найти и оставить комментарии.

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

Мы надеемся, что наш опыт в использовании этих простых правил окажется полезным и для вас.

ㅤ