Макеты сайта в Figma: что проверить перед передачей разработчику

Красивый экран ещё требуется превратить в понятное задание

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

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

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

Доступ: откройте файл под учётной записью исполнителя

Возможность посмотреть изображение не равна доступу ко всему материалу. Figma различает «Can view» и «Can edit»: просмотр позволяет читать свойства и комментировать, редактирование — менять файл. Заказчику полезно заранее определить нужный уровень. Давать право изменения каждому участнику только ради удобства чтения неразумно, если случайная правка может затронуть уже принятую версию и останется незамеченной до начала разработки. Полезно сохранить ссылку и роль доступа в записи передачи, чтобы при смене состава команды новый участник получил тот же принятый материал и не начинал оценку по случайной копии, которую ему переслали без пояснения о её назначении.

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

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

Версия: отделите принятые экраны от поиска вариантов

Большой файл часто содержит черновики рядом с готовым решением. Разработчику нужен однозначный список того, что принято. В Dev Mode Figma используется отметка «Ready for dev» для готовых к разработке объектов. Её наличие удобно для навигации, но внутреннее принятие компанией описывают отдельно: кто подтвердил содержание и какие замечания остались открытыми, чтобы технический статус не подменял решение заказчика.

Сам Dev Mode имеет условия доступа. В руководстве указаны места «Full» или «Dev» на поддерживаемых планах, поэтому команда сначала уточняет доступный ей способ просмотра и не строит передачу на функции, которой у исполнителя фактически нет. Для заказчика главное — получить читаемый состав и свойства принятого материала.

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

Размеры: покажите поведение между крайними экранами

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

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

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

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

Состояния: ошибки и ожидание входят в состав

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

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

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

Содержание и изображения передают отдельно от внешнего вида

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

Скачивание тоже требуется проверить. В справке Figma раздел «Export» задаёт получение материалов, а доступ на просмотр позволяет экспорт, если владелец не ограничил копирование и передачу. Поэтому ссылка на макет и возможность получить нужное изображение — отдельные пункты: исполнитель показывает оба на своём доступе.

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

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

Комментарии: зафиксируйте принятое решение

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

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

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

Запись передачи, которую можно приложить к задаче

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

Передаём в разработку перечисленные страницы и состояния по ссылкам. Принятая версия: указать место в файле. Размеры экранов и правила перестроения: приложить. Тексты и изображения: перечислить готовые и ожидаемые. Открытые вопросы: назвать ответственных. Исполнитель подтвердил доступ, чтение свойств и получение нужных материалов.

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

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