На встрече открыта главная страница будущего сайта. Директору нравится первый экран, маркетолог просит сделать кнопку ярче, менеджер молчит. Мы даём менеджеру простую задачу: «Найдите планировку двухкомнатной квартиры и отправьте вопрос». Он нажимает три раза, возвращается назад и спрашивает: «А где цена?» Так за две минуты обнаруживается проблема, которую статичная презентация скрывала.
Именно для этого мы используем интерактивный прототип в Figma. Не чтобы произвести впечатление движущимися экранами, а чтобы до разработки проверить логику переходов, меню, всплывающих окон и ключевых действий. В самом инструменте взаимодействие строится из понятной пары: что сделал человек и какой экран или состояние увидел дальше.
Что связываем обязательно
Не каждая ссылка в прототипе должна работать. Если пытаться оживить весь сайт, команда потратит время на декорацию. Мы выбираем несколько дорогих для бизнеса сценариев — тех, ошибка в которых приведёт к переделке структуры или логики.
- переход с первого экрана к целевому действию;
- открытие меню и возврат на нужное место страницы;
- выбор услуги, тарифа, квартиры или специалиста;
- появление формы и состояние после отправки;
- просмотр документов, галереи или подробного условия;
- мобильный путь, если он отличается порядком контента.
Для типового одностраничного сайта обычно достаточно трёх–пяти потоков. У сложного продукта их может быть больше, но каждый поток получает имя: «Холодный посетитель просит расчёт», «Постоянный клиент ищет документы», «Кандидат смотрит вакансии». Без имени связи быстро превращаются в паутину.
Согласование, на котором нельзя обсуждать всё сразу
Мы делим встречу на два прохода. Сначала смотрим только смысл и последовательность: хватает ли информации для решения, понятен ли следующий шаг, не появляется ли тупик. Цвет, тени и точные формулировки временно не обсуждаем. Во втором проходе фиксируем содержание конкретных экранов и ответственных за материалы.
| Роль на встрече | Задание | Что она замечает |
|---|---|---|
| Руководитель | Найти главное отличие предложения | Не растворилась ли стратегия в деталях |
| Менеджер | Ответить на частый вопрос клиента | Хватает ли аргументов до разговора |
| Маркетолог | Пройти путь из конкретного объявления | Совпадает ли обещание рекламы со страницей |
| Контент-менеджер | Изменить условие или документ | Какие элементы должны редактироваться |
Комментарии пишем не в мессенджер и не общим списком «поправить макет». Каждый комментарий закреплён за экраном и содержит причину: «После выбора тарифа пользователь не видит срок», а не «добавить срок куда-нибудь». Тогда дизайнер понимает задачу, а не угадывает решение.
Ранняя правка дешевле не потому, что Figma волшебная
Переставить два смысловых блока в прототипе — это изменить несколько экранов. Сделать то же после разработки означает проверить вёрстку на разных ширинах, анимацию, аналитику и редактирование в админке. Экономия появляется не из-за названия программы, а из-за момента, когда принято решение.
В проекте жилого комплекса «Флагман» сайт был частью более широкой системы: название, цвета, структура, планировки, ход строительства и дальнейшее обновление материалов. Подобный проект важно обсуждать как последовательность задач покупателя, а не как набор независимых картинок.
Чего прототип не доказывает
Кликабельная кнопка в Figma подтверждает переход между экранами. Она не подтверждает отправку письма, появление заявки в CRM, скорость страницы или удобство клавиатуры на телефоне.
Поэтому прототип нельзя принимать словами «всё нажимается». Он отвечает на вопросы о логике. Технические и браузерные проверки начинаются позже, уже на рабочей версии. Подробно место прототипа в процессе описано в материале о прототипировании до дизайна.
Что должно остаться после встречи
- Ссылка на утверждённую версию и дата фиксации — чтобы не спорить, какой вариант был финальным.
- Список проверенных потоков с начальной точкой и ожидаемым финалом.
- Комментарии, по которым принято решение: исправить, отклонить или отложить.
- Перечень материалов от клиента с владельцем и сроком.
- Границы следующего этапа: что уходит в дизайн, а что ещё требует ответа бизнеса.
Для промышленных и технически сложных продуктов особенно важно показать в прототипе не всю документацию, а путь к нужной характеристике или запросу. Такие задачи мы отдельно разбираем в решениях для промышленности. Хороший прототип не выглядит законченным сайтом — зато после него у команды существенно меньше дорогих сюрпризов.