Прототип в Figma: как согласовать будущий сайт до дорогой разработки

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

икнока календаря икнока глаза47 икнока часов7 мин
Прототип в Figma: как согласовать будущий сайт до дорогой разработки

На встрече открыта главная страница будущего сайта. Директору нравится первый экран, маркетолог просит сделать кнопку ярче, менеджер молчит. Мы даём менеджеру простую задачу: «Найдите планировку двухкомнатной квартиры и отправьте вопрос». Он нажимает три раза, возвращается назад и спрашивает: «А где цена?» Так за две минуты обнаруживается проблема, которую статичная презентация скрывала.

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

Что связываем обязательно

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

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

Для типового одностраничного сайта обычно достаточно трёх–пяти потоков. У сложного продукта их может быть больше, но каждый поток получает имя: «Холодный посетитель просит расчёт», «Постоянный клиент ищет документы», «Кандидат смотрит вакансии». Без имени связи быстро превращаются в паутину.

Согласование, на котором нельзя обсуждать всё сразу

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

Роль на встречеЗаданиеЧто она замечает
РуководительНайти главное отличие предложенияНе растворилась ли стратегия в деталях
МенеджерОтветить на частый вопрос клиентаХватает ли аргументов до разговора
МаркетологПройти путь из конкретного объявленияСовпадает ли обещание рекламы со страницей
Контент-менеджерИзменить условие или документКакие элементы должны редактироваться

Комментарии пишем не в мессенджер и не общим списком «поправить макет». Каждый комментарий закреплён за экраном и содержит причину: «После выбора тарифа пользователь не видит срок», а не «добавить срок куда-нибудь». Тогда дизайнер понимает задачу, а не угадывает решение.

Ранняя правка дешевле не потому, что Figma волшебная

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

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

Чего прототип не доказывает

Кликабельная кнопка в Figma подтверждает переход между экранами. Она не подтверждает отправку письма, появление заявки в CRM, скорость страницы или удобство клавиатуры на телефоне.

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

Что должно остаться после встречи

  1. Ссылка на утверждённую версию и дата фиксации — чтобы не спорить, какой вариант был финальным.
  2. Список проверенных потоков с начальной точкой и ожидаемым финалом.
  3. Комментарии, по которым принято решение: исправить, отклонить или отложить.
  4. Перечень материалов от клиента с владельцем и сроком.
  5. Границы следующего этапа: что уходит в дизайн, а что ещё требует ответа бизнеса.

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

Узнайте сколько будет стоить продвижение вашего бизнеса

Оставьте заявку — менеджер ответит
в течение дня, уточнит задачи и пришлёт коммерческое предложение.

    Оставьте адрес электронной почты и мы пришлём вам коммерческое предложение или презентации

    человек на фоне