{"id":13505,"url":"\/distributions\/13505\/click?bit=1&hash=ca3734639136826288c9056e5c8fa03a05e87c4060ae84df200f2c90f5262470","title":"\u0412\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a? \u0410 \u043f\u043e\u043d\u0438\u043c\u0430\u0435\u0442\u0435 \u0447\u0442\u043e-\u0442\u043e \u0432 \u0438\u0441\u043a\u0443\u0441\u0441\u0442\u0432\u0435 \u043a\u043e\u0434\u0430?","buttonText":"\u041f\u0440\u043e\u0432\u0435\u0440\u0438\u0442\u044c","imageUuid":"f5f0e11f-fefd-52f5-8712-82164a59b7ce","isPaidAndBannersEnabled":false}
Дизайн
Friflex

От дизайна к фронтенду: как передать макет в разработку

Чтобы все изображения и кнопки были на своих местах, анимации корректно работали, а шрифты на макете совпадали со шрифтами в интерфейсе, разработчику нужно больше, чем доступ к проекту в Figma. Мы в Friflex проектируем интерфейсы для миллионов пользователей, и, работая над проектами, очень внимательно следим, чтобы после программирования дизайн сохранял функциональность и внешний вид. В этой статье Светлана Моторкина, Head of Design, Friflex, опираясь на свой опыт, рассказывает, как подружить дизайнера и фронтендера и передать макет в разработку без потерь.

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

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

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

Шаг 1. Старт проекта

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

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

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

Шаг 2. Работа с макетами

Соблюдение структуры

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

Используйте Changelog (журнал изменений) – фрейм, который содержит поддерживаемый, упорядоченный в хронологическом порядке список изменений для каждой версии проекта. Так разработчик всегда будет в курсе всех изменений.

Компоненты

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

Описание компонента

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

Создавайте док-фрейм для каждого компонента, в котором будет:

  • Описание компонента.

Детально продумайте и опишите свой компонент, например, все виды и размеры компонента, возможные конфигурации, максимальную и минимальную ширину компонента и т. д.

  • Стейты (состояния).

Создавая компонент, закладывайте все состояния заранее. Все возможные загрузки, активное и неактивное состояние / при наведении / нажатии в пустом и заполненном виде / ошибки и т. д.

Лайфхак: ознакомиться с примером описания для компонента «Button» можно на сайте Carbon Design System.

Адаптивность и сетки

Адаптивность

Адаптивность – способность макета подстраиваться под разный формат разрешения экрана. Возьмите за правило отрисовывать несколько вариантов макетов под адаптив для разных устройств. Достаточно три – четыре версии (Например для веб: от 1280 – ∞, 1024, 768, 320).

Не забывайте отрисовывать макеты под минимальный размер, либо всегда проверять или закладывать размер на экранах 320px.

Показывайте отзывчивость с помощью Constraints в Figma, т.е. привязки. Если вы рисуете четыре макета, то для каждого из них обязательно нужно прописывать constraints.

Лайфхак: при отрисовке адаптива нужно учитывать Landscape (горизонтальное положение) состояние. Особенно если использование вашего продукта это предусматривает. Актуально для карт, навигаторов, воспроизведения видео.

Сетка

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

Для мобильных устройств обычно используется 4px или 8px сетка.

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

Для веба используется известная сетка Boostrap.

Существует два вида сетки:

  • Фиксированая сетка – сетка, в которой колонки зафиксированы по ширине.
  • Резиновая сетка – сетка, в которой колонки меняют свою ширину в зависимости от размера устройства.

Лайфхак: добавляйте в стиль созданные колонки/сетки. Чтобы применить колонки к монтажной области, достаточно ее выделить и выбрать на панели «Design» в разделе «Layout Grid» соответствующий разрешению макета стиль. Включить/выключить отображение колонок и сетки: Ctrl + G (для Mac),
Ctrl + Shift + 4» (для Windows).

Карты экранов

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

Лайфхак: не обязательно рисовать пути вручную, для этого есть множество плагинов. Я использую AutoFlow, ArrowAuto.

Заметки разработчику

Оставляйте заметки разработчику. Такие, как описание действия компонента при нажатии на него. Выберите Master Component, нажмите на иконку настройки и в появившемся окне Documentation (документация) введите текст в поле «How to use this component». Текст отобразится в виде комментария в CCS.

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

Автоматически упорядочивайте и очищайте документ Figma с помощью плагина Clean Document. Он позволяет удалять скрытые слои, разгруппировывать однослойные группы и т.д.

Шаг 3 Передача в разработку

Статус готовности и версионность

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

  • Делить на отдельные пейджи. Разбивайте макеты на вкладки по готовности: готово для разработки / в процессе.
  • Указывать статус в самом макете. Маркируем статусы на каждой группе или на каждом макете.

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

Незначительные изменения, например, смену вида иконки в интерфейсе, можно фиксировать для разработчиков в Changelog (журнал изменений).

Прототипирование

Разработчик не всегда понимает, какой элемент с чем и как должен взаимодействовать в интерфейсе. Для этого нужно прототипирование. Переходы и простые прототипы можно собирать в Figma. Для более сложной анимации вам потребуются дополнительные инструменты: Principle, After Effects и т.д.

Лайфхак: если у вас не хватает навыков сложной анимации, прикрепляйте референсы анимации в виде скринов и ссылок.

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

Графические ассеты и шрифты

Разработчики могут обратиться с просьбой выгрузить графику для каждой платформы в своем формате. Чтобы не тратить на это время, можно сделать выгрузку автоматически с помощью плагина Export Presets. Плагин помогает формировать в один клик ассеты в нужном формате, включая пресеты по умолчанию для самых популярных платформ.

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

Анализ объема работ и общение с разработчиком

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

Если вы не работайте в Figma, а используете Sketch, можно передавать макеты в Zeplin.

Шаг 4 Дизайн-ревью

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

Фидбек от разработчиков

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

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

Правки

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

Лайфхак: возьмите скриншот сборки экрана и приложите рядом со своим макетом. Зафиксируете рядом с экранами правки и отправьте на доработку.

После того, как разработчик внес все правки, задача переходит на QA.

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

0
40 комментариев
Написать комментарий...
Ияза Гара

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

Ответить
Развернуть ветку
Артем Наумов

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

Ответить
Развернуть ветку
Max Pashkov

Боюсь дело не всегда только в оплате. Есть еще всякие "аааа нада срочнаа вот прям щас гориииим".

Ответить
Развернуть ветку
John Doe

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

Ответить
Развернуть ветку
Ияза Гара

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

Ответить
Развернуть ветку
Max Pashkov

Добавлю пару советов:

- Разберитесь как работают средства лейаутинга в выбранной технологии. Как происходит компоновка, как отрабатывается ресайзинг визуально. Хорошие разработчики не откажут ни в экскурсе, ни в наброске мини прототипа на поиграться. Зато вы будете с разрабами в одних системах координат, и не будет вопроса, почему нельзя 13.58 пикселя тут и 45.42 пикселя здесь.

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

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

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

Ответить
Развернуть ветку
Max Pashkov

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

Ответить
Развернуть ветку
Артем Наумов
и не будет вопроса, почему нельзя 13.58 пикселя тут и 45.42 пикселя здесь.

А почему вдруг нельзя? Современные движки вполне неплохо справляются с рендерингом любых размеров. Да и пиксели давно стали логическими, а не физическими. Иногда крайне удобно использовать 0.5 пикселя для лучшего выравнивания элементов. 🤷‍♂️

Ответить
Развернуть ветку
Max Pashkov

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

Ответить
Развернуть ветку
Гуд Дэй ту Йа

Я бы сказал, что не "нельзя", а "не нужно".

Ответить
Развернуть ветку
Max Pashkov

Быват, что нельзя как раз. Например, если фреймворк принимает параметры как целые числа.

Ответить
Развернуть ветку
Гуд Дэй ту Йа

Я понимаю. Но речь не о том, существует вероятность или нет. Просто не нужно этого делать.

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

Ответить
Развернуть ветку
Max Pashkov

По моему сугубо личному опыту чем мягче формулировка, тем меньше она работает на практике =) Те кто с опытом и понимают как, где и что можно, обычно сами такие статьи пишут, а неопытному читателю безопаснее давать четкие правила.

Ответить
Развернуть ветку
Пуганный Аноним

"Иногда крайне удобно"

Когда?

Ответить
Развернуть ветку
Артем Наумов

Иногда.

Ответить
Развернуть ветку
Пуганный Аноним

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

Ответить
Развернуть ветку
Артем Наумов

15+ лет разрабатываю интерфейсы. Двигаю. С повсеместным приходом 4-8к+ дисплеев все будем двигать.

Ответить
Развернуть ветку
Пуганный Аноним

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

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

Ответить
Развернуть ветку
Михаил Катовайс

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

Ответить
Развернуть ветку
Пуганный Аноним

Не нужно думать мозгом?

Ответить
Развернуть ветку
Михаил Катовайс

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

Ответить
Развернуть ветку
Артем Наумов
Знаю кучу дизайнеров, которые говорят, что перфект пиксель никому не нужен.

Он и не нужен 🤷‍♂️. Как раз "перфект пиксель" признак новичка. Мог бы привести в качестве пруфов разницу в рендере шрифтов и растрирования графики на разных платформах и девайсах, но лень, оппонент явно не поймет.

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

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

Хороший дизайнер адаптирует интерфейс к "окружению" и контексту использования ;).

Ответить
Развернуть ветку
Анна Гаврилова

Огонь, больше таких тем!

Ответить
Развернуть ветку
Диван Мягкий

Супер. Очень полезно

Ответить
Развернуть ветку
MXX

Интересно было почитать, вторая часть будет?

Ответить
Развернуть ветку
Максим Мещеряков

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

Ответить
Развернуть ветку
Гуд Дэй ту Йа

Давай, работавай, давай! Кнопку он двигает тут... Дармоед!

Ответить
Развернуть ветку
Пуганный Аноним

А потом разработчик сидит имена переменных придумывает вместо i, j, k
Уволеть

Ответить
Развернуть ветку
Абстрактный вентилятор

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

Ответить
Развернуть ветку
Artem Visotsky

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

Ответить
Развернуть ветку
Andrey Nitak

Ты особо одаренный выходит

Ответить
Развернуть ветку
Artem Visotsky

Ну вобщем как бы да

Ответить
Развернуть ветку
Artem Visotsky

а я забыл, и минусить еще...))))

Ответить
Развернуть ветку
Гуд Дэй ту Йа

Полезно! Даже, если не быть идеальным, а только стремиться.

Ответить
Развернуть ветку
Andrey Nitak

Дизайнер, что логику работы продукта проектирует?

Ответить
Развернуть ветку
Max Pashkov

В том числе. Как минимум принимает непосредственное и непоследнее участие в формировании UX, из которого могут вытекать изменения в бизнес логике и далее. Или вы думаете дизайнеры просто картинки рисуют как им сказали?) Это тогда художники, а не дизайнеры)

Ответить
Развернуть ветку
Andrey Nitak

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

Ответить
Развернуть ветку
Max Pashkov

То есть в вашей картине мира не дай бог кому-то кроме аналитика предложить изменения в логике?) Правильно, не жили хорошо, нечего и начинать) Еще раз: изменения в юзабилити могут порой сказываться на изменении бизнес логики. В этом мой поинт. А не в том, чтобы на одного человека повесить оркестр.

Ответить
Развернуть ветку
Andrey Nitak

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

Ответить
Развернуть ветку
Max Pashkov

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

Ответить
Развернуть ветку
Читать все 40 комментариев
null