Как стать автором
Обновить

Как создавать библиотеки компонентов в Figma, экономя бюджет, на примере онлайн-аукциона

Время на прочтение8 мин
Количество просмотров21K


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

Это первая часть статьи, в которой будет много скучной, но конкретной практической информации по созданию компонентов в Figma, а также нюансы, подводные камни и реалии создания проектов с ограниченным бюджетом в провинциальной среде =)

Началу работ предшествовал длительный период переговоров и аналитической работы, на основе которой было написано детальное ТЗ с разбивкой на функциональные (динамические) и статические блоки. Подробно о нём можно почитать в этой статье. Если вы еще не работаете по такому ТЗ, то крайне рекомендуем. Исключительно положительный опыт для всей команды разработки и проекта в целом.

Но вернемся к дизайну


Стоит упомянуть, что Figma выкатила очень приятное обновление уже в самый разгар работ, поэтому тут не будет ни словечка о цветовых и текстовых стилях. Будем надеятся, что внимательный читатель и без этих нюансов почерпнет для себя что-то полезное. Также, если у вас нет базового представления о принципах организации компонентов в figma, рекомендуем поиск по habr.com (очень много отличных материалов по теме).

Прежде чем приступить к пиксельпёрфектному проектированию, мы в большинстве случаев делаем дизайн концепцию. Обычно она представляет из себя некий сырой (с визуальной стороны) макет, который должен быть основательно продуман с точки зрения поведения на разных экранах и учитывать основной функционал. Это необходимо чтобы в будущем избежать неприятных сюрпризов, когда забытый блок не встраивается в утверждённые лейауты. Поэтому, концепт — это скорее черновой макет реальных страниц, чем стайлборд, который, тем не менее, даёт базовый набор стилей и основные лейауты будущих страниц.

В данном случае концепция имела следующий вид:



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

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



Итак — все подготовлено. У нас есть ТЗ с прописанным функционалом для понимания работы компонентов; стайлборд в виде концепции для понимания стилистики элементов; стандарт именования компонентов для безболезненного переноса дизайна в вёрстку, и бесконечное множество транквилизаторов всех сортов и расцветок…

Можно начинать ковыряться в фигме


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



Текст


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



Montserrat medium как основной шрифт и Montserrat bold для заголовков и выделений.
Переходим к иконкам. Их мы надёргали из бесплатной библиотеки “Feather”



Иконки


Каждую иконку помещаем в контейнер 24х24 пикселя и выравниваем по центру по двум осям (на всякий случай). Все иконки обзываются по вкусу, но с добавлением префикса “i”, чтобы не возникало повторов в названиях, и группируем, чтобы не захламлять панель со слоями.



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

Далее переходим к более сложным компонентам. Их мы расположим правее, и соберём из элементов из первого столбца и палок.

Чекбоксы


Начнём с чего-нибудь попроще.

Чекбоксы и радиобаттоны в контейнерах 16х16 пикселей. Для каждого состояния создаём отдельный компонент. Это нужно для того, чтобы в дизайне страниц (собираемых из этих компонентов) мы могли заменить одно состояние на другое через панель INSTANCE.



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

Счетчик и слайдер


Еще нам понадобится счетчик для вывода количества чего-либо. Это будут разные данные в зависимости от его расположения. Делаем фрейм 20х20 и цифру по центру.

Кнопки для слайдера объектов нам тоже пригодятся. Делаем их 30х30 и помещаем иконки-шевроны условно по центру,. Создаём компоненты для разных состояний.



Дерево каталога


С недавних пор мы стали придерживаться принципа переиспользования одних и тех же компонентов на разных устройствах, чтобы не плодить лишних сущностей и поддерживать чистоту кода (насколько это возможно). Поэтому дерево каталога мы делаем, отталкиваясь от мобильного отображения. ТЗ говорит нам, что максимальный уровень вложенности дерева: 3.

Начинаем с первого уровня: фрейм высотой 60 пикселей и безразмерной шириной (будет подстраиваться под контейнер), иконка выравнивается по вертикали и отступает от левого края на 20 пикселей, название ветки будет из компонента h4. Все это приклеиваем к левой стороне в панели CONSTRAINS. К правой стороне приклеиваем количество лотов (тоже h4) и шеврон.

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



Далее идет череда сплошных компромиссов


Меню


Панель табов для всяких меню и вкладок мы поместили в контейнер 60px в высоту, а сами пункты разместили по центру. Забегая вперёд скажем, что такой подход не является верным, ибо, если вы хотите получить полностью резиновый макет, каждый таб нужно поместить в отдельный фрейм. Иначе не получится задать поведение табов относительно друг друга. Но мы, переговорив с разработчиками, со спокойным сердцем на это забили.



Списки


Вовремя вспомнилась такая мелочь как нумерованные и ненумерованные списки. Для добавления номера мы возвращаемся в первый столбец и создаем компонент с двузначным числом.

Инпуты и фильтры


Настал тот момент, когда мы нарушили собственные правила иерархии и поместили компоненты и компоненты состоящие из этих компонентов ( *_______* ), в один столбец (напомним: правило было размещать их правее, вынося в отдельный). Можно было без этого обойтись, но мы решили что блок (фильтр или инпут) и его дропдаун будут составлять один компонент в разных состояниях. Как сказал Сэлвор Хардин: “Никогда не позволяйте морали удерживать вас от правильных поступков.”

На этот компромисс мы пошли по следующей причине: по своему составу инпуты и, например, чекбоксы должны принадлежать к одному уровню сложности (одному столбцу) но и выпадающий список в инпуте может содержать чекбоксы. Нам очень хотелось, чтобы выпадающие списки образовывали единый блок с инпутом — ради красивой тени.



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

Вернёмся в практическую плоскость.

Инпуты


Внутрь фрейма 60px в высоту мы помещаем компонент параграфа в качестве плейсхолдера. Когда инпут будет в фокусе, плейсхолдер будет отъезжать наверх. Задаём ему отступ в 20 пикселей и приклеиваем к левому краю. По нижней границе блока добавляем линию в 2 пикселя (используйте ректанглы!), приклеиваем по вертикали к Bottom. По горизонтали можно выбрать Scale. Далее в правой части у нас в разных ситуациях может быть либо единица измерения, либо шеврон дропдауна. Добавляем и то и другое и приклеиваем к правому краю. Теперь все аккуратно растягивается, и все копии этого компонента наследуют поведение родителя.



Добавляем компоненты для разных состояний: инпут по наведению курсора, фокус, открытый дропдаун, валид и инвалид. Один из способов быстрого создания состояний такой: клонируем компонент, нажимаем option+command+b, или “детач инстанс” — через контекстное меню. Редактируем что нужно и превращаем в новый компонент. Не забываем переименовать.



С фильтрами ситуация аналогичная и за исключением состояния по дефолту и добавления креста для сброса значений, они не отличаются от инпутов. Забыли — инпуты будут идти подряд друг за другом по горизонтали, поэтому по правому краю добавляем серую линию в 2px. Не забываем приклеить её к правому краю.



Кнопки


Кнопки в нашем проекте будут двух видов.

Первые: привычные кнопки которые будут использоваться везде кроме карточек превью лота. Их анатомия такая: фрейм высотой 30 пикселей с прозрачным фоном, ректанглом аналогичного размера со скруглением 15 пикселей (в панели CONSTRAINTS устанавливаем значение Scale в обеих осях) и компонента btn-txt который мы выравниваем во всех осях по центру (на всякий пожарный — вдруг решим увеличить высоту кнопки?) В отдельный компонент выделяем стиль кнопки по наведению и отдельный для нажатия.



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



Делаем их из прямоугольников 60px в высоту, ширина будет зависеть от контента. Вкладываем и центрируем по всем осям компонент иконки и btn-txt. На иконку накладываем компонент счётчика таким образом, чтобы его левый нижний угол совпадал с центром иконки. Кнопки у нас будут располагаться подряд друг за другом, поэтому добавляем с каждой стороны по серой полосе в 2 пикселя для визуального разделения. Ненужные потом отключим на месте. В данном случае в компоненте превью лота.

Мы еще вернёмся к этому уровню компонентов, а пока едем дальше.

Шапка


Переходим в новый столбец и начинаем собирать шапку.

За основу берём фрейм все тех же шестидесяти пикселей в высоту. По нижней границе добавляем серую линию в 2 пикселя. Ширину возьмём 1440px, т.к. все десктопные шаблоны будем собирать на этом разрешении. Следуем уже стандартной схеме: выравнивание по центру вертикали, горизонтальный отступ 20 пикселей, логотип, табы меню, поиск (был собран по аналогии с инпутом во втором столбце).



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



Чтобы на любом шаблоне посмотреть выпадающий список, вкладываем сразу два компонента (открытый и закрытый дропдаун). Один отключаем тыкнув в глаз на панели слоёв. Не забываем снять галку с Clip Content на панели BACKGROUND.



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

Настало время для настройки резиновости. Для этого выделяем наш компонент “Header-desktop” и идём в LAYOUT GRID. Переключаем на колонки. Количество колонок в данном случае не играет роли, главное чтобы сетка была (для разных задач пробуйте разные сетки) Маргины по 20 пикселей. Далее настраиваем поведение вложенных компонентов шапки.



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

Бургер


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



Превью лота


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



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



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

Мы уверены, что такой подход всё еще не является идеальным, поэтому будем рады любым замечаниям по теме (особенно если вы знаете как продуктивнее использовать фигму) — любой ваш опыт поможет нам усовершенствовать бизнес процессы. Раунд.
Теги:
Хабы:
Всего голосов 8: ↑8 и ↓0+8
Комментарии7

Публикации