Как не разводить бардак в дизайне: собираем UI-kit

Приходит дизайнер на проект и сразу берется за голову: там карточка едет, там цвет не соответствует ни Primary, ни Secondary, иконки в kit одни, а на страницах — другие. В общем, полный бардак. Как его избежать — рассказываем в статье от дизайнеров Purrweb.

Дизайнеры в Purrweb используют Figma. Но если вы работаете в Sketch или Adobe XD, ничего страшного — советы универсальные.

Давайте пойдем по порядку — разберемся, что такое UI-kit и зачем он нужен.

Что такое UI-kit

UI-kit иногда путают с дизайн-системой. Дизайн-система — это вообще вся информация по дизайну проекта. Туда входит даже редполитика, которая, казалось бы, не имеет отношения к дизайну. Отличный пример — Paradigm, дизайн-система VK.

А теперь сравните это с UI-kit.

Дизайн-система глобальна, UI-kit — узконаправленный инструмент
Дизайн-система глобальна, UI-kit — узконаправленный инструмент

UI-kit — это набор компонентов, из которых собирается интерфейс. Кроме визуала он включает в себя технические параметры: код цвета, размер, высота строки, поведение и пр. И самое главное — он используется только в разработке интерфейса и больше нигде.

UI-kit — это про разработку

Слово «компонент» отражает еще одну особенность UI-kit — он нужен разработчикам. Это слово как раз пришло в дизайн из разработки.

Раньше разработчики сами собирали компоненты и использовали их. Потом появился софт, который визуализирует эту функцию. Так Figma, Sketch и Adobe XD подружили дизайнеров с разработчиками.

UI-kit помогает быстро вносить изменения

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

UI-kit нужен любому проекту

Есть распространенное мнение, что UI-kit нужен только крупным платформам и приложениям. На деле UI-kit не нужен только микро-проектам, например, если у вас лендинг без планов на расширение.

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

Работа над UI-kit в Purrweb, поэтапно

Теперь, когда мы разобрались с тем, что такое UI-kit, покажем, как его делают в Purrweb. Начинаем собирать UI-kit, как только утвердили концепт — главную страницу приложения и еще 1-2 второстепенных. На них мы отрисовываем максимум деталей, чтобы дать клиенту четкое понимание того, как будет выглядеть готовый проект.

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

У нас концепт и UI-kit разрабатывает один дизайнер, как правило, middle или senior. Он подбирает цвета, шрифты, иконки и утверждает их с заказчиком. Это еще одна гарантия того, что дизайн интерфейса будет согласованным.

Пример дизайн-концепта Purrweb
Пример дизайн-концепта Purrweb

Первая итерация

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

  • цвета;
  • типографику;
  • иконки;
  • кнопки и контролы;
  • инпуты;
  • дропдауны.
Дизайн-концепт с подсвеченными UI-элементами
Дизайн-концепт с подсвеченными UI-элементами

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

Доработка

UI-kit обновляется на протяжении всей работы над проектом. Когда один из дизайнеров создает элемент, который будет повторяться, он действует следующим образом:

  • рисует элемент;
  • делает его компонентом;
  • собирает экран, используя экземпляр;
  • переносит мастер-компонент на страницу с UI-kit.
Создаем компонент

Если в процессе работы нужно отрисовать состояния компонента, они переносятся в UI-kit по тому же принципу. Таким образом все элементы, которые должны быть в UI-kit, 100% оказываются там.

Теперь, когда мы разобрались с порядком действий, давайте посмотрим на готовый UI-kit и как собирать каждый отдельный его блок.

UI-kit здорового человека: все компоненты и советы по работе с ними

Пройдемся отдельно по каждой разновидности компонентов.

Цвета и стили

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

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

Плагин <a href="https://api.vc.ru/v2.8/redirect?to=https%3A%2F%2Fwww.figma.com%2Fcommunity%2Fplugin%2F941680506965181089%2FColor-Styleguide&postId=491359" rel="nofollow noreferrer noopener" target="_blank">Color Styleguide</a> в Figma автоматически оформляет все ваши цветовые стили в виде блока
Плагин Color Styleguide в Figma автоматически оформляет все ваши цветовые стили в виде блока

Градация серого

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

Но если интерфейс ближе к монохромному, оттенков серого может быть несколько десятков. В таком случае их нужно назвать числами от 00 до 100 (или от 000 до 1000 — зависит от количества оттенков).

У каждого оттенка свой номер
У каждого оттенка свой номер

Тогда ваш коллега сможет выбрать отдельный компонент, посмотреть на номер цветового стиля и применить его для нового компонента. Если стили не называть, придется каждый раз прописывать HEX-код.

Темная тема

Если в приложении будет темная тема, важно правильно оформить градацию серого. Темная тема — это просто инверсия монохромных элементов.

Пример инверсии
Пример инверсии

Соответственно и оттенки серого мы называем с учетом инверсии. В светлой теме самый темный оттенок серого будет называться 100, а в темной — 00.

Типографика

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

<p>Пользователям Figma существенно упростит жизнь плагин <a href="https://api.vc.ru/v2.8/redirect?to=https%3A%2F%2Fwww.figma.com%2Fcommunity%2Fplugin%2F965313760136371738%2FTypography-Styleguide&postId=491359" rel="nofollow noreferrer noopener" target="_blank">Typography Styleguide</a>, который красиво оформит текстовые стили</p>

Пользователям Figma существенно упростит жизнь плагин Typography Styleguide, который красиво оформит текстовые стили

Сетка

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

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

Иконки

Просто переносим в UI-kit все иконки из интерфейса. К векторной иконке обязательно нужно делать подложку размером с контейнер иконки. Только в таком виде их можно использовать в интерфейсе. Иконка без подложки — это векторное изображение, которое в коде будет выглядеть как огромный кусок текста. А огромные куски текста — это грязный код. Разработчики будут ругаться.

Если у иконки на какой-то странице специально меняется цвет и размер — нужно занести этот вариант иконки в UI-kit как новый элемент.

Каждая иконка должна быть компонентом
Каждая иконка должна быть компонентом

Кнопки и контроллеры

Эти компоненты мы объединяем в одну большую группу, так как они выполняют примерно похожие функции. Маст-хэв компоненты это:

  • Основная кнопка
  • Второстепенная
  • Текстовая
  • Кнопка-иконка
  • Радио баттон
  • Чекбоксы
  • Переключатели
  • Табы
  • Кликабельные ссылки
Чем больше кнопок отрисуете вначале, тем меньше придется дорисовывать в процессе сборки экранов
Чем больше кнопок отрисуете вначале, тем меньше придется дорисовывать в процессе сборки экранов

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

Не забудьте также про состояния кнопок:

  • Initial — начальное состояние кнопки
  • Hover — состояние при наведении мыши
  • Focus — при выборе кнопки с клавиши Tab
  • Loading — состояние загрузки
  • Disabled — кнопка неактивна
И так для каждой кнопки
И так для каждой кнопки

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

Инпуты

Каждый инпут, в который вводят определенный тип данных, становится компонентом. Например, если вместо текста пользователь вводит пароль или номер телефона. Поле для ввода номера платежной карты и поле «прикрепить файл» — это отдельные компоненты. Такое разделение нужно для разработчиков: в коде у этих данных разные свойства и описываются их инпуты по-разному.

Все виды инпутов добавляем в UI-kit
Все виды инпутов добавляем в UI-kit

Состояния инпутов:

  • Initial — начальное состояние
  • Active — поле выбрано
  • Typing — заполнение поля
  • Filled — поле заполнено
  • Disabled — поле неактивно
  • Success — заполнено верно
  • Error — ошибка
Все состояния используем во всех версиях интерфейса
Все состояния используем во всех версиях интерфейса

Дропдауны

Работаем так же, как с инпутами — делаем новый компонент из каждого уникального дропдауна.

Чем больше компонентов, тем лучше
Чем больше компонентов, тем лучше

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

Карточки

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

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

Все состояния карточки нужно отрисовать

В Figma это достигается благодаря использованию фреймов и автолейаутов. В других редакторах есть свои аналоги.

Хедер

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

Например, после регистрации/авторизации пользователя, в хедере должны появиться элементы управления профилем. Изменения выпадающих меню в хедере — тоже состояния сложносоставного компонента.

Состояния хедера для десктопа
Состояния хедера для десктопа

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

При этом, если в хедере есть кнопка, она будет отдельным компонентом.

Резюмируем

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

  • Все, что встречается больше 1-го раза — компонент (не устанем это повторять). Чем больше компонентов вы занесете в UI-kit, тем больше времени себе сэкономите.
  • Главная характеристика для всех компонентов — универсальность. Если компонент ломается после незначительных изменений — это плохой компонент.

Только эти 2 совета серьезно облегчают жизнь нашим дизайнерам.

Как передавать UI-kit разработчику/дизайнеру/заказчику?

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

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

Названия компонентов: поймет и дизайнер, и разработчик
Названия компонентов: поймет и дизайнер, и разработчик

Также важно прописать комментарии к невидимому поведению компонентов. Например, текстовое поле. Чем больше там текста, тем больше оно растягивается. При этом, когда количество текста превысит 6 строк, он начнет скролиться внутри текстового поля.

Отрисовать такое нереально. Поэтому такие моменты лучше прописать текстом. Причем комментарии нужно оставлять непосредственно рядом с компонентом в UI-kit. Так вы исключите возможность того, что ваш комментарий кто-то не заметит/удалит/закроет.

Комментарий к полю
Комментарий к полю

На этом, пожалуй, все. По ссылке можно рассмотреть наш внутренний образец UI-kit.

Понравилась статья? Больше материалов для дизайнеров в нашем блоге:

Халяльный дизайн: как делать приложения на арабском

9191
22 комментария

Что такое бекдроп?
А экшен меню?

3
Ответить

Это слова чтобы по больше бабла срубить

9
Ответить

Лайк за то, что поделились фигмой

4
Ответить

😉

Ответить

Спасибо

2
Ответить

Очень полезно, сохранил.

2
Ответить

👍🏻

Ответить