Организация пространства в фигме
В статье я расскажу, как мы организуем пространство в Figma в нашей компании "Бинет". Вы узнаете, как мы формируем файлы, управляем вкладками и обеспечиваем согласованное взаимодействие между дизайнерами, разработчиками и проектными менеджерами.
Всем привет! Меня зовут Лиля, и я старший дизайнер в компании по разработке мобильных приложений — Бинет. Мы работаем как с крупными приложениями (с более чем 500 экранами), так и с небольшими проектами.
В этой статье я поделюсь нашим опытом в создании общих правил по организации пространства в фигме для небольших приложений, поскольку именно таких у нас большинство.
Возможно, вы сталкивались с теми же трудностями, что и мы, и эта статья окажется вам полезной, учитывая особенности вашей компании.
Ну что, начнем!
ㅤ
С какими проблемами я столкнулась
Когда я только присоединилась к компании и открыла рабочее пространство в фигме, создалось впечатление, будто я оказалась в черной дыре или в Нарнии.
Все файлы, включая наши рабочие, клиентские и черновики, а также файлы из 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” - номер экрана в данном разделе, и третья цифра обозначает различные состояния этого экрана.
ㅤ
Заключение
В результате взаимодействие внутри команды стало гораздо удобнее.
- Теперь каждый знает, где найти нужные файлы и макеты;
- У папок, файлов и вкладок единая структура наименований;
- Если необходимо проверить дизайн-решения, то дизайнеры просто указывают номер макета, и разработчики могут быстро найти и оставить комментарии.
Казалось бы, мы внедрили всего несколько простых правил в наш рабочий процесс, но даже такие маленькие улучшения сделали нашу работу гораздо легче.
Мы надеемся, что наш опыт в использовании этих простых правил окажется полезным и для вас.
ㅤ