На мой взгляд, никакой особой «передачи» быть не должно. Опытный дизайнер делает макет таким, чтобы в нём могли ориентироваться другие — дизайнеры, разработчики, редакторы. Даже если в макете бардак, а его уже пора показать разработчикам, покажите его и параллельно наведите порядок. Разработчики сами подскажут, что им мешает и что нужно исправить в первую очередь.

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

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

В наведении порядка здорово помогает плагин Clean Document.

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

Размеры и отступы должны быть заданы целыми числами, если вам не нужны именно дробные. Во‑первых, это хорошо с точки зрения порядка и аккуратности, а во‑вторых разработчику не придётся гадать, например отступ 27,56 пикселя — это 27 или 28?

Чтобы работать с целыми пикселями, включите функцию Snap to Pixel Grid в меню Preferences.

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

Если выбрать объект и зажать Alt, то можно измерять расстояния до соседних объектов. Для разработчика это самый удобный способ определения отступов. Чтобы отступ был очевиден, не делайте рамки текстов пересекающимися.

В этом помогает опция Auto Height, которая подгоняет нижнюю границу текста под интерлиньяж.

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

Выберите Master Component и введите текст в поле Description, которое появится в правой панели. Текст отобразится в виде комментария в ЦСС, который увидят разработчики.

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

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

Несложную анимацию можно сделать прямо в Фигме, например с помощью плагина Figmotion:

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

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

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

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