Designer

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

Начнём с простого

Нарисуем лист вью с иконкой, и сгенерируем вёрстку.

Так выглядит примерная структура нашего элемента списка - слева иконка, и далее текст.

Такую структуру будет иметь наш компонент - вертикальный набор элементов, который мы придумали выше.

Так, со структурой разобрались, поняли что нам примерно нужно сделать, теперь приступаем непосредственно к дизайну. Для этого мы возьмём один элемент, и сделаем его на основе компонентов Фигмы и применим к нему Auto layout. Сначала объединим текст и иконку, добавим отступы, сделаем выравнивание по высоте в середине, и по левому краю. Получится так

Далее нам нужно создать два элемента, расположить их друг под другом по высоте, и объединить их Auto layout. В целом всё кажется готовым, но на самом деле, если вы поменяете длинну текста, то элементы не будут гибко подстраиваться друг под друга.

Завершающим штрихом станет выставление автоматического растягивания элемента по ширине самого длинного элемента. Применяем это ко всем элементам списка, чтобы они могли адаптироваться к любой длине текста. Это делается при помощи вот этого инструмента.

В результате у нас должен получиться такой вот список.

Запускаем генератор кода.

Открывается плагин с генерацией кода. где мы можем выбрать необходимую нам технологию. Я буду использовать Tailwind 2. Далее выберем нужный нам элемент дизайна, и плагин выдаст нам готовую вёрстку.

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

Так, всё работает, кроме иконок, которые нам нужно копировать как SVG и вставить в наш код. Делается это вот так

Заменяем наши иконки в вёрстке (я вставил прям в разметку, но вы можете и так как вам удобно - по url на пример.).

Получаем результат, который идентичен нашему в Фигме.

Подробнее про Auto layout тут.

Результат тут.

Сложнее. Рисуем карточку товара.

Нашей целью будет сделать так, чтобы при генерации кода, наша карточка была выполнена на основе display: flex; - CSS модели, для построения гибких контейнеров.

Я нарисовал макет, как в прошлом примере, сделал дизайн, распределил блоки, и при помощи Auto layout выровнял всё так, как мне нужно. Сгенерировал код, подправил некоторые нюансы с картинками и иконками, в результате получил готовую карточку товара. Подробнее про Flexbox тут.

Моя сгенерированная разметка доступна по ссылке ниже. Вы можете посмотреть и попробовать сами.https://play.tailwindcss.com/2VhmQJIJDl

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

Меня зовут Илона, я Senior Experience Designer в EPAM. Работа для меня удачно совпадает с хоббив EPAM я проектирую интерфейсы для зарубежных заказчиков, читаю лекции для сотрудников и студентов лабы, менторю дизайнеров. В свободное время преподаю проектирование интерфейсов в магистратуре Университета ИТМО и ведуТелеграм-канал о UX-дизайне.

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

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

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

Проект, на котором мы работаем крупная e-commerce платформа с большой командой (80+ разработчиков, менеджеров, аналитиков, тестировщиков) и быстро меняющимися требованиями. На таком крупном проекте логично образовалась дизайн-команда из 4 ролей:

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

• UI-дизайнер (в EPAM эта роль также именуется Visual-дизайнер), который отвечает за то, чтобы интерфейс был красивым, эстетичным, хорошо смотрелся на разных разрешениях, соответствовал концепции бренда и возможностям разработки.

• Юзабилити-специалист, который регулярно проводит тестирования дизайна с настоящими пользователями системы, интерпретирует результаты и составляет список рекомендаций по улучшениям.

• Team Lead, который налаживает процессы и решает оргвопросы, обеспечивает команде комфортные условия работы и также занимается UX-дизайном.

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

В целом, задачи на дизайн сложно оценивать в силу нескольких причин:

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

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

• Каждую идею нужно проверить и утвердить с заказчиком. И не так просто понять, сколько времени это займёт и как результат обсуждения повлияет на работу дизайнера.

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

Вот некоторые цитаты из ретроспектив, которые мы проводили внутри дизайн-команды:

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

Относительная оценка сложности

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

Согласно Scrum, для оценки задач используется абстрактная единица Story point. В одной команде ею могут измеряться часы, в другой дни, в третьей что-то ещё. Кому как удобно.

В нашей команде 1 Story point был равен 4 часам. И нам, по перечисленным ранее причинам, было крайне тяжело оценивать работу в таких Story points. Поэтому я решила наделить Story point другой мерой сложность.

Сложность (complexity) количество усилий, необходимых для выполнения задачи.

В нашем случае оценка сложности в Story points оказалась гораздо эффективнее, чем оценка часов, потому что:

• Оценка сложности помогает сконцентрироваться на создании ценности, а не погоне за временем. Мы перестали пытаться успеть хоть что-то в заявленные сроки.

• Проще включить обсуждения, подтверждения и брейнштормы в итоговую оценку.

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

• Исключаются обсуждения в формате Я бы сделал эту работу быстрее.

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

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

Параметры сложности

Сложность комплексная мера, и трудно сходу сказать, что это значит. Для удобства дизайн-команды я разделила сложность на 4 параметра*:

1. Зависимости от других людей

2. Навыки дизайнера

3. Количество коммуникации в рамках задачи

4. Согласованность нового дизайн-решения с уже существующими

_{*хотя параметры описывают работу дизайнера, я думаю, они будут актуальны и для других специалистов.}

Для каждого параметра я подобрала шкалы от 1 до 4. Например, оценка параметра Зависимость (Dependency) выглядит так:

1 (нет сложности) никто кроме дизайнера не вовлечён в работу, нет зависимости от других людей;

2 (низкая сложность) 1 человек вовлечён и немного работы с стороны;

3 (средняя сложность) 2-3 человека и/или много работы со стороны;

4 (высокая сложность) более 3 человек и/или невозможно определить количество работы со стороны.

Подробные шкалы по всем четырём параметрам сложности можно найти в моём докладе для конференции Design Z Day:

Как понять, что сложно, а что нет

Всё познается в сравнении.

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

Секрет относительная оценка. Задачи оцениваются не в вакууме, а относительно друг друга, в сравнении.

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

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

Процесс сравнения всегда основан на опыте конкретной команды. Поэтому оценки каждой команды уникальны.

Как наша команда начала использовать относительную оценку сложности

Нам было сложно перестроиться с абсолютной оценки часов на относительную оценку сложности.

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

Из прошлого спринта, который мы оценивали в часах, взяли 3 задачи. Мы их уже выполнили, поэтому всё про них знали. Для каждой задачи мы последовательно прошлись по 4 параметрам сложности (зависимости, навыки, коммуникация, согласованность) и дали новые оценки в относительных Story Points. Это было непросто, мы долго обсуждали каждую оценку и приходили к единой цифре. Вот что у нас получилось:

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

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

Результаты перехода на относительную оценку сложности

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

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

Важные результаты для нашей дизайн-команды:

• прозрачность задач;

• более точные оценки с меньшими усилиями;

• команда дизайнеров понимает, что мы должны знать перед выполнением задачи;

• лучшая декомпозиция задач;

• учитывается вся работа, включая согласования, генерацию идей и обсуждения;

• мы постоянно сравниваем задачи и видим общую картину.

Как итог, меньше стрессов, переутомления и неприятных сюрпризов.

Больше о проектировании интерфейсов и UX можно почитать в моём телеграм-канале Поясни за UX.

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

Файл с примерами:тут

Мануал:тут

Поле с Auto Layout теперь выглядит так:

Теперь с легкостью можно настраивать разное поведение вложенных компонентов, а так же разные отступы в компонентах, сделать их можно с помощью новых настроек:

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

Новые настройки по ресайзам компонентов:

Уже завтра (20 ноября) Фигма проводит разбор Фичи и использование нового Auto Layout Регистрация на мероприятие от Фигмы тут

Привет, мы дизайнеры экосистемы Своё для фермеров и банковских сервисов Россельхозбанка. Рассказываем, зачем нам понадобился SVGator.

Как мы пришли к SVGator.com

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

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

Что за зверь и какие задачи решает

SVGator.com это web-платформа для создания svg-анимаций, то есть svg-файлов со встроенными анимациями, которые без каких-либо проблем интегрируются в html. Можно задать последовательную обработку таких анимаций. Возможен экспорт как js, так и чистым CSS. Возможности js немного шире, но разница не существенная.

В рамках продуктов группы Своё мы создавали различные анимации для лоадеров, микроэлементов (таких как стрелка дропдауна), логотипов и элементов оформления. Мы ещё находимся на стадии экспериментов с SVGator, но уже чётко понимаем, в каких моментах он имеет преимущества и что можно создать с его помощью:

Небольшие функциональные элементы интерфейса. Например, интерактивные состояния компонентов и вытекающая микроанимация

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

Элементы дизайна. Например, иллюстрации

Интерфейс и функционал

На данный момент SVGator располагает исключительно веб-платформой, но весь необходимый функционал присутствует. Интерфейс напоминает классическое решение канувшего в Лету Flash и взявшего бразды правления After Effects. Слева слои файла. Сверху панель инструментов. Снизу таймлайн, а по центру сама рабочая область. Если есть навыки работы с АЕ, совершенно точно SVGator покажется очень простым. Но в этом и его преимущество порог входа значительно ниже.

Инструмент включает в себя следующие функции: работа с размером, положением, поворотом, наклоном, цветом, прозрачностью, а также богатый функционал для работы с обводкой. Помимо этого, поддерживается работа с масками и векторами движения. Этого достаточно для работы с классическими решениями анимации. Ещё один важный момент работа с easing, которые также встраиваются в svg-файл. Это упрощает работу на этапе front-end, и дизайнеру не приходится тревожить разработчика скоростью анимации.

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

Чем svg отличается от sequence, gif, video? А также основные конкуренты:
Lottie и Keyshape

Ключевые преимущества svg вес, отсутствие api и возможность давать плавную анимацию. Разберём каждую из альтернатив.

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

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

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

Lottie. Это один из ключевых конкурентов SVGator. Компания раньше вышла на рынок и имеет значительно больше почитателей. Плюс возможности анимации значительно больше, поскольку базовая анимация собирается в Аfter Еffects, а lottie является своего рода оболочкой для такой анимации. Но для работы с данным решением необходимо предустановить api на платформу, что не всегда хорошо для продакшена больших нагруженных систем.

Keyshape. Очень близкая по возможностям платформа, различия лишь в деталях. Текущий функционал Keyshape несколько выше и позволяет делать экспорт чистым svg + css. К недостаткам можно отнести её стационарность и возможность работать исключительно на macOS.

Вот поэтому и стоит обратить внимание на SVGator. Плавные анимации, реализованные кодом, кроссплатформенные, без каких-либо api и с нормальным весом.

SVGator в экосистеме Своё

На наших продуктах Своё Фермерство, Своё Жильё, Своё Родное, Монеты, Подбор персонала, Своё Село и т.д. уже присутствуют наработки в SVGator: лоадер, интерактивные состояния компонентов, логотипы, а также иллюстрации для оформления разделов. Мы планируем увеличивать их долю и продолжать экспериментировать.

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

Перспективы

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

Объёмные решения склонны к излишней нагрузке системы и могут стать камнем преткновения. Поэтому в наших планах использовать этот инструмент поступательно, небольшими шагами, анимируя поначалу небольшие элементы.

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