Как улучшить организацию проектов в Figma

Всем привет, меня зовут Артем Сафаров, я — дизайнер из веб-студии Pyrobyte. У нас существует корпоративный аккаунт в Figma, которым пользуются все дизайнеры и другие члены команды. Отсюда вытекает проблема: в нем зачастую творится хаос. В этой статье я расскажу, как мы привели проекты в фигме в порядок, а также поделюсь некоторыми советами.

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

Просто, например, твой коллега-дизайнер называет проекты по-другому, или арт-директор решил навести порядок и перенес его в другое место, а может и ты сам переименовал его, а теперь не можешь найти по поиску.

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

Мы тоже прошли все стадии от отрицания до принятия и привели все проекты в фигме в порядок. Сейчас расскажу как.

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

Фигма предлагает пользователю такие инструменты, как: компоненты, привязки, авто-лейауты, ассеты, создание стилей, корректный нейминг, и если этим всем не пользоваться, то увеличивается время создания дизайна.

Возможно, на небольших проектах, которые вы пилите в соло, это незаметно, и вы спросите себя “Зачем мне тратить время на создание дизайн-системы”, но когда дизайнер работает в команде, подобным отношением к проекту он создает дополнительные проблемы для других членов команды. Если в дальнейшем потребуется изменить, например, цвет кнопок в готовом проекте, придется делать все вручную.

Очень часто проблемы уже начинаются на этапе создания проекта. Все файлы, которые относятся к одному проекту мы формируем внутри одного проекта, и файлы фигмы называем в соответствии с их содержимым. Например, trainet/design, trainet/analytics и т.д. Это делается для легкого перехода к файлам нужного проекта.

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

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

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

- К ШРИФТАМ

В Material дизайн-системе их называют Headline 1...N, Subtitle 1...N, и т.д. Более подробно можно ознакомиться здесь. Мы придерживаемся этого гайдлайна.

- К ЦВЕТАМ

В Material Design цвета называют по четкой структуре, отталкиваясь от правила пропорций цвета 60/30/10. Если цвет используется как основной, то его называют primary, дополнительный цвет имеет название secondary, и третий по значению tertiary. Остальные стили называются по своему назначению, если цвет присвоен к какому-либо действию, то и получает название этого действия.

Часто встречал, когда стилям присваивали названия по их цвету black, blue, white и т.д. Мы считаем, что в этом случае подход Material'a более системный и правильный, потому что зачастую бывает так, что в проекте присутствуют несколько оттенков одного цвета, и такие названия, как blue, light blue, super light blue в дальнейшем усложнят работу, особенно если вы передадите такой проект другому дизайнеру.

- К ЭФФЕКТАМ

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

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

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

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

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

На проектах, как правило, используется большое количество иконок, и поэтому лучше выносить их и называть, начиная с icon /.

В UI-кит выносятся, как уже говорил, все элементы, которые повторяются больше одного раза, но и про разные состояния компонента также не стоит забывать. Их нужно тоже выносить в UI-кит, это состояния для всех возможных элементов (форм, кнопок, чекбоксов, радио-бтн и т.д.) (при наведении, дефолт, при клике, при дисейбле, при аллерте). Состояния кнопок, хедер, футер тоже выносятся в UI-кит.

При использовании в верстке Avocode и Zeplin всем векторным элементам на макетах в параметрах export необходимо выставить корректные настройки. По умолчанию указан формат файла png, желательно поставить svg там, где графика векторная.

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

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

С использованием Variants такой проблемы нет, так как дизайнерам теперь достаточно в UI-ките настроить связи между элементами, и это сильно облегчит задачу при создании прототипа.

Атомарный подход закладывает в себе создание на UI-ките всех состояний заранее, и это помогает не пропустить все валидации компонентов.

Более подробно с документацией Variants вы можете ознакомиться здесь.

Этот подход также помогает front-end разработчикам увидеть все состояния базовых элементов и иметь доступ к ним в одном месте, не прибегая к поиску конкретного по всему проекту. Важно отметить, что скорость внесения правок в проект влияет в том числе на отклик от front-end разработчиков, так как им не приходится ждать большое количество времени на внесение изменений в дизайн, что сокращает время ожидания начала правок в коде и позволяет вносить быстрые корректировки уже в процессе вёрстки/разработки.

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

Собрали для вас примеры некоторых UI-китов в фигме, с которыми стоит ознакомиться. Пользуйтесь :)

01. Paradigm

Paradigm — одна из первых дизайн-систем в России, в которой дизайнеры уделили много внимания системности.

02. Набор элементов для iOS & iPadOS 14

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

03. Material Design UI kit

UI-комплект Material Design основан на стилизованных рекомендациях, совместимых с официальными спецификациями. Он содержит в себе впечатляющее количество настраиваемых и готовых к использованию компонентов. Этот пак подойдет для использования в Android приложениях.

04. Lo-fi Wireframe Kit

Это интересный набор из прототипов рисованного типа. Если нужно красиво показать проектирование сайта, либо приложения, юзайте этот пак. Библиотека состоит из более чем 100 компонентов проектирования, которые помогут вам быстрее работать над проектами. В набор входят кнопки, текстовые поля, вкладки, изображения и множество вариантов их использования. А гибкие компоненты помогут использовать элементы как для мобильных экранов, так и для ПК.

05. Pegasus

Система дизайна Pegasus — это гибкий, удобный и доступный набор компонентов, сделанный в Figma. Этот набор создан с использованием компонентов Variants для увеличения скорости рабочего процесса. В библиотеку дизайн-системы входит: 300+ компонентов, 72+ оригинальных иконок.

06. Ant Design System

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

07. Taiga UI

Пользовательский интерфейс Taiga — это полностью настраиваемый Angular UI-кит, состоящий из нескольких базовых библиотек и нескольких надстроек. Дизайн-система получилась очень большой, она включается в себя более 130 компонентов, более 100 директив, десятки токенов, утилит и инструментов. Эта система будет очень полезной при изучении, и вы сможете много чего наследовать из неё.

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

Если у вас есть вопросы по организации проектов в фигме, пишите в комментариях, все обсудим :)

#веб_дизайн #figma #webdesign #design2022 #ui #ui_кит