Figma-макет или готовый сайт: где на самом деле удобнее собирать фидбек

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

Два разных вопроса на двух разных этапах

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

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

Что хорошо получается в Figma

У статичного макета есть реальные преимущества именно на ранней стадии. Комментарий можно привязать к точной точке на холсте — не «кнопка где-то сверху», а конкретный пиксель конкретного элемента. У каждого замечания есть статус: открыто, решено, требует уточнения — и видно, что уже разобрано, а что ещё нет. А версии макета можно сравнивать side-by-side до того, как решение вообще попало в код: это дешёвый способ проверить гипотезу, не тратя часы разработчика на вёрстку варианта, который в итоге отклонят.

Чего Figma не может показать, даже самый детальный макет

Как бы подробно ни был собран макет, часть реальности в нём физически отсутствует. Брейкпоинты и то, как блоки на самом деле перестраиваются между ними, видны только в браузере — макет показывает три-четыре зафиксированных состояния, а не непрерывный переход. Системные шрифты рендерятся по-разному в разных браузерах и операционных системах, и в Figma это не воспроизвести, как бы точно ни был указан шрифт. Интерактивные состояния — hover, focus, индикатор загрузки — в статичном кадре просто не существуют, их можно описать словами, но нельзя пощупать. То же касается реальной скорости и ощущения от скролла: оно складывается из физики браузера, а не из прототипных анимаций. Разница между «выглядит отзывчиво на макете» и «ощущается отзывчиво в браузере» хорошо описана в материале web.dev про основы адаптивной вёрстки — и это ровно тот зазор, который Figma закрыть не может.

Как выбрать: что сейчас важнее — концепция или поведение?

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

Что теряется при ревью на сайте без инструмента

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

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

Один процесс ревью на оба этапа

Вывод не в том, чтобы выбрать одну площадку навсегда, а в том, чтобы процесс ревью не зависел от того, где именно сейчас находится страница. Клик по элементу → комментарий → статус → история версий — этот цикл должен работать одинаково, что по ссылке на Figma-файл, что по ссылке на живой сайт. Тогда переход от макета к вёрстке не стоит команде заново выстроенного workflow: меняется объект обсуждения, но не способ его вести.

На практике это снимает ещё один скрытый вопрос — кого звать на ревью готового сайта. Если участники уже привыкли кликать и комментировать в одном и том же интерфейсе, не важно, работают они с макетом или с живой страницей: заказчик, маркетолог или QA-инженер подключаются к обсуждению без дополнительного объяснения «как у нас тут устроен фидбек на этом конкретном этапе». Единый процесс избавляет от необходимости каждый раз договариваться о формате заново.