Интерактивный прототип в Figma: как убедить заказчика с первого показа
Основной чат
Чат для вайбкодеров: новости, гайды, поиск исполнителей, маркетплейс и разбор реальных кейсов.
Заказчик садится напротив, открывает ноутбук, и через 40 секунд говорит: «А можно показать, как это будет работать?» Вы открываете Figma, кликаете по фрейму — и попадаете не туда. Потом ещё раз не туда. Потом объясняете словами, что вот тут будет анимация, а вот тут модалка. К концу встречи заказчик кивает, но решение отложено «на подумать».
Это не про дизайн. Это про то, что статичный макет проигрывает воображению заказчика. Он видит картинку, но не чувствует продукт. А пока он не почувствовал — он не покупает.
Интерактивный прототип решает ровно эту проблему. Но плохо собранный прототип хуже статики: он ломается на показе, путает заказчика и подрывает доверие к команде. Поэтому вопрос не «делать или нет», а «как собрать так, чтобы первый показ закрыл сделку».
Почему статичный макет почти всегда проигрывает
Заказчик — не дизайнер. Он не умеет в голове склеивать 12 экранов в флоу. Он не знает, что между экраном 3 и экраном 4 есть переход с тремя состояниями. Он смотрит на статику и видит ровно то, что видит: набор картинок.
Из этого вырастают три типичные проблемы первого показа:
- Вопросы не про продукт, а про артефакт. «А почему здесь кнопка такого цвета?» вместо «А справится ли пользователь с регистрацией?»
- Бесконечные правки по мелочам. Когда не виден сценарий, заказчик цепляется за детали — это единственное, что он может оценить.
- Сделка зависает. «Покажите ещё варианты», «давайте обсудим внутри», «вернёмся через неделю». Это не про макет — это про то, что заказчик не увидел работающий продукт.
Прототип переключает разговор. Заказчик кликает, проходит сценарий, ловит ощущение «о, это уже работает» — и обсуждает суть, а не цвета.
Что считается интерактивным прототипом, а что нет
Здесь часто путаются. «Я связал фреймы стрелочками» — это ещё не прототип в смысле, который убеждает заказчика. Это кликабельный макет.
Три уровня готовности
Уровень 1: кликабельный макет. Фреймы связаны переходами, кнопки ведут куда положено. Подходит для внутреннего ревью, не подходит для показа заказчику.
Уровень 2: сценарный прототип. Собран один-два ключевых пользовательских сценария от входа до результата. Есть состояния (hover, active, disabled), есть базовая анимация переходов, работает на мобильном устройстве, если продукт мобильный. Это минимум для показа.
Уровень 3: продуктовый прототип. Используются компоненты с вариантами, переменные для тем и состояний, smart animate для микро-взаимодействий, реалистичные данные. Заказчик не отличает от рабочего продукта в первые минуты.
Для первого показа целимся в уровень 2 с точечными элементами уровня 3 в самых заметных местах: главный CTA, ключевой переход, момент «вау».
Антипаттерн: прототип всего
Соблазн показать каждую страницу и каждое состояние. На практике это убивает показ: вы тратите время на сборку, прототип становится хрупким, заказчик теряется в количестве экранов.
Правило: один сценарий, который отвечает на главный вопрос заказчика. Всё остальное — статикой рядом.
С чего начать: выбор сценария под заказчика
До того как открыть Figma, нужно понять, что именно заказчик хочет увидеть в работе. Не «весь продукт», а конкретный путь, который для него важнее всего.
Вопросы перед сборкой
- Какое решение заказчик принимает по итогам показа? (запуск, бюджет, найм команды)
- Какой сценарий он или его пользователь повторит чаще всего?
- Где в текущем продукте или у конкурентов «больно»? Прототип должен показать, что у нас не больно.
- Что заказчик показывал предыдущим подрядчикам и чем остался недоволен?
Ответы на эти вопросы дают один-два сценария, вокруг которых строится прототип. Всё остальное — фон.
Чеклист выбора сценария
- Сценарий заканчивается измеримым результатом (заказ оформлен, отчёт построен, профиль создан)
- В сценарии есть момент, где продукт делает что-то заметно лучше альтернатив
- Сценарий проходится за 60–90 секунд без объяснений
- В сценарии не больше 6–8 экранов
- Сценарий работает на устройстве, с которого заказчик будет смотреть
Если сценарий не проходит по этим пунктам, прототип будет выглядеть громоздко даже при идеальной сборке.
Короткий итог первой части: прототип убеждает не объёмом, а точностью попадания в сценарий, который важен заказчику. Дальше разберём саму сборку — структуру файла, компоненты, переходы и подготовку к показу.
Сборка прототипа: структура файла, которая не развалится на показе
Главная ошибка на этом этапе — собирать прототип «как макет, только со стрелочками». Прототип — это отдельный артефакт со своей логикой файла, и если этого не учесть, на показе что-нибудь обязательно отвалится: ссылка не туда, состояние не подтянулось, на телефоне поехал layout.
Базовая структура страниц в Figma
Один файл — одна голова. Внутри файла развожу страницы по ролям, чтобы во время показа не лазить по случайным фреймам.
- Cover — обложка с названием, версией, ссылкой на сценарий
- Flow — [название сценария] — только те экраны, которые участвуют в кликабельном проходе
- Components — компоненты с вариантами и состояниями
- Library / Tokens — переменные цвета, типографики, отступов
- Archive — всё, что не вошло в показ, но жалко удалять
Страница Flow — это сцена показа. На ней не должно быть ничего лишнего: ни параллельных версий, ни «а давайте ещё так попробуем». Параллельные варианты — в Archive, иначе на показе случайно кликнете не туда.
Компоненты и варианты: где экономить, где нет
Соблазн собрать прототип «из плоских фреймов» большой — кажется, что быстрее. На втором изменении вы пожалеете.
Что обязательно делать компонентом с вариантами:
- Кнопки (default / hover / pressed / disabled / loading)
- Поля ввода (empty / focused / filled / error)
- Карточки сущностей, которых на экране больше одной
- Навигация (active / inactive состояния пунктов)
Что компонентом делать не нужно для прототипа на показ:
- Уникальные экраны-«герои» (главная, success-страница)
- Декоративные блоки, которые встречаются один раз
- Состояния, которые не участвуют в сценарии показа
Правило: компонент оправдан, если состояние меняется по ходу сценария или элемент встречается больше двух раз.
Переходы: где Smart Animate помогает, а где мешает
Smart Animate выглядит магически, но на показе именно он чаще всего создаёт ощущение «глючит». Причина обычно одна — несовпадение имён слоёв между фреймами.
Когда использовать Smart Animate
- Переход внутри одного экрана: открытие шторки, разворот карточки, появление списка
- Изменение состояния элемента: чекбокс, тоггл, индикатор загрузки
- Переход между шагами одного флоу, где экраны похожи на 80%
Когда не использовать
- Полная смена экрана с разной структурой — лучше Instant или Dissolve
- Длинные списки с динамическим контентом
- Переходы, где разработчик потом не сможет это повторить (а значит, вы продаёте то, чего не будет в продукте — отдельная этическая ловушка)
Чеклист стабильного перехода
- Слои, которые должны «перетекать», имеют одинаковые имена в обоих фреймах
- Они лежат в одинаковой иерархии (фрейм → группа → элемент)
- Длительность 200–400 мс, ease out для появлений, ease in-out для движения
- На медленном устройстве переход всё ещё читается, не дёргается
- Если убрать анимацию — сценарий остаётся понятным
Последний пункт — самый важный. Анимация подчёркивает логику, а не заменяет её.
Диагностика: что обычно ломается за час до показа
Сценарии, с которыми сталкиваешься регулярно.
Симптом: «прототип тормозит на телефоне заказчика». Причина почти всегда — тяжёлые картинки в исходном разрешении или избыточные эффекты блюра. Прогоните изображения через сжатие, отключите блюр там, где он декоративный.
Симптом: «кликнул не туда — и прототип сломался». Нет дефолтного перехода из «тупиков». На каждом экране должен быть либо явный CTA, либо способ вернуться. Добавьте overlay-подсказку на первый клик мимо.
Симптом: «на ревью выглядело иначе». Просмотр в редакторе и в режиме Present — разные миры. Финальную проверку всегда делайте в Present, с того устройства, с которого будет смотреть заказчик.
Симптом: «заказчик не нашёл, куда кликать». Hotspot слишком маленький или в неожиданном месте. Расширьте hit area невидимым фреймом поверх — это нормальная практика.
Антипаттерны, которые видно сразу
- Прототип показывают с ноутбука дизайнера, а продукт мобильный
- В сценарии есть шаг «представьте, что здесь будет…» — значит, сценарий не готов
- Заказчик за время показа ни разу не кликнул сам
- Дизайнер комментирует каждый экран вслух — прототип должен говорить сам
Вопросы для внутреннего ревью перед показом
Прогоните прототип на коллеге, который не видел проект. Он должен ответить «да» на каждое:
- Понятно, что это за продукт, без объяснений?
- Понятно, какой сценарий мы проходим?
- Получилось дойти до конца без помощи?
- Был момент, который запомнился?
- Если бы это был рабочий продукт — что бы первым делом сломалось?
Последний вопрос — золотой. Он вытаскивает дыры, которые дизайнер уже не видит.
Короткий итог сборки: структура файла защищает от случайностей, компоненты — от хрупкости, Smart Animate работает только при чистых именах слоёв, а финальная проверка всегда идёт в Present и на устройстве заказчика. Дальше — сам показ: как вести встречу, чтобы прототип сработал, а не превратился в очередное «обсуждение макетов».
Продвинутые сценарии: когда обычного клика не хватает
Базовый прототип проводит по линейному флоу. Но заказчик чаще всего хочет увидеть не идеальный сценарий, а развилку: «а что будет, если у пользователя пустая корзина», «а если он уже подписан», «а если ошибка оплаты». Здесь линейная схема рассыпается.
Переменные и условия: зачем и когда
Variables в Figma превращают прототип из слайдшоу в простую логику. Полезно ровно в трёх случаях:
- Состояние, которое нужно протащить через несколько экранов (логин, выбранный план, тема оформления)
- Счётчики и формы, где значение влияет на следующий шаг (количество товаров, валидация)
- Развилка по роли пользователя на одном демо: админ, обычный пользователь, гость
Если переменная используется один раз — она не нужна, хватит дублирующего фрейма. Variables оправданы, когда альтернатива — десять почти одинаковых экранов.
Анти-паттерн: «прототип-приложение»
Соблазн собрать в Figma маленькое работающее приложение возникает у каждого, кто разобрался с переменными. Это ловушка. Прототип — инструмент проверки гипотезы, а не замена фронтенду. Признаки, что вы зашли слишком далеко:
- Файл открывается дольше пяти секунд
- Логика держится в голове только у автора
- Изменить копирайт занимает пятнадцать минут
- Разработчик смотрит и говорит «мы так не сделаем»
Последнее — главное. Если прототип демонстрирует поведение, которое команда не возьмётся повторить, вы продаёте обещание, которое нельзя сдержать.
AI и Figma: где это реально ускоряет, где мешает
Сейчас в любом обсуждении прототипа всплывает «а давайте сгенерим через AI». Где это работает на пользу:
- Черновая заливка контента: реалистичные имена, описания, цены вместо Lorem Ipsum
- Генерация вариантов копирайта для CTA и эмпти-стейтов
- Быстрая сборка декоративных иллюстраций для разовых экранов
- MCP-интеграции, которые поднимают из дизайн-системы нужные компоненты по описанию
Где AI стабильно подводит:
- Структура флоу — модель собирает «среднестатистический» сценарий, а не ваш
- Логика состояний — пропускает edge-кейсы, которые как раз важны заказчику
- Соответствие дизайн-системе — компоненты выглядят похоже, но это не ваши компоненты
Правила для AI-ассистированного прототипа
- AI работает на этапе наполнения, не на этапе архитектуры
- Любой сгенерированный экран проходит через ту же проверку, что и нарисованный руками
- Перед показом — отдельный проход «найди следы генерации»: одинаковые фразы, неработающие переходы, чужие компоненты
- Не показывайте заказчику то, что не понимаете сами; если AI собрал переход, а вы не знаете, как он работает — выкиньте
Главный риск — не качество, а ответственность. На вопрос «почему здесь так?» ответ «AI предложил» не принимается ни заказчиком, ни командой.
Как объяснить прототип команде
Заказчик кивает — это полдела. Дальше прототип уходит в разработку, аналитику, контент. Если команда не понимает, что именно показано, на этапе реализации начнётся «творческая интерпретация».
Что приложить к файлу
- Карта экранов: список с одним предложением про каждый («это экран после успешной оплаты»)
- Список переменных и что они означают
- Явная пометка «прототип, не финальный дизайн» там, где это правда
- Список того, чего в прототипе нет, но это сознательно (пустые состояния, ошибки сети, оффлайн)
Вопросы, на которые должен ответить разработчик после ревью
- Понятно, какие переходы — анимация, а какие — продуктовое поведение?
- Понятно, что здесь моковые данные, а что — реальная логика?
- Видно, где использован компонент из дизайн-системы, а где разовый вариант?
- Есть ли в прототипе поведение, которое нельзя реализовать на текущем стеке?
Если хоть один ответ — «нет», прототип ещё не готов уходить в работу, даже если заказчик его уже принял.
Проверка качества: финальный проход
Перед тем как отправить ссылку, прогоните файл по трём срезам.
Срез скорости. Откройте Present с холодного старта на устройстве заказчика. Если первый экран появляется дольше трёх секунд — оптимизируйте картинки и эффекты.
Срез логики. Пройдите основной сценарий два раза подряд, не глядя в редактор. На втором проходе обращайте внимание только на моменты, где вы сами на секунду задумались — это места, где задумается и заказчик.
Срез честности. Пройдитесь по экранам и задайте один вопрос: «это поведение реально появится в продукте в обозримом будущем?». Если ответ «вряд ли» — пометьте экран как иллюстративный или уберите.
Короткий итог: продвинутые сценарии оправданы, когда без них теряется суть; AI ускоряет наполнение, но не отвечает за решения; команде нужен не только файл, но и карта того, что в нём моковое, а что — продуктовое. Дальше остаётся самая нервная часть — сам показ.
Чеклист готовности прототипа к показу
Финальная сверка перед тем, как открыть Zoom и нажать Present. Если хоть один пункт не закрыт — отложите показ на пару часов, доделайте, потом возвращайтесь.
Содержание
- Главный сценарий проходится от начала до конца без объяснений с моей стороны
- Все CTA ведут хоть куда-то — нет «мёртвых» кнопок в основном флоу
- Тексты, цифры и имена выглядят как настоящие данные продукта, а не как заглушки
- Состояния загрузки и ошибки показаны хотя бы для ключевых экранов
- Есть один «вау-момент», ради которого заказчик и пришёл
Техника
- Present открывается на устройстве заказчика за разумное время
- Прототип проверен и на ноутбуке, и на телефоне, если оба сценария обсуждаются
- Шрифты и иконки не уехали — нет «квадратиков» вместо глифов
- Компоненты из дизайн-системы — это реально компоненты из системы, а не их визуальные копии
- Файл переименован и лежит в той папке, ссылку на которую не стыдно отправить
Коммуникация
- Знаю, с какого экрана начну и каким закончу
- Готов один-два вопроса, которые задам сам — чтобы вести обсуждение, а не отвечать на случайные
- Понимаю, что моковое, а что — настоящее обещание, и могу это разделить вслух
- Есть план Б, если кто-то скажет «а покажите вот этот другой сценарий»
Анти-паттерны, которые ломают показ
Прототип-портфолио
Симптом: пять вариантов главного экрана, три темы оформления, анимация на каждое нажатие. Заказчик не понимает, что обсуждать, и уходит в обсуждение цвета кнопки.
Лечение: один основной флоу, остальное — в отдельную страницу «исследования», открывать по запросу.
Демо-волшебник
Симптом: прототип работает только в руках автора. Автор знает, куда тапнуть, чтобы переход сработал, и в каком порядке открывать экраны.
Лечение: дайте ссылку коллеге, который вообще не в контексте. Если он застрял — застрянет и заказчик, просто молча.
Прототип-обещание
Симптом: показаны взаимодействия, которые красиво смотрятся, но команда честно говорит «мы это не вытянем в спринт». Заказчик уже мысленно «купил» это поведение.
Лечение: до показа согласовать с разработкой, что в прототипе реализуемо в обозримом релизе. Всё остальное — либо убрать, либо явно пометить как «направление, не обязательство».
Слишком много моков под видом продукта
Симптом: на экране 12 карточек, у всех разные данные, всё выглядит как готовый продукт. На вопрос «откуда берутся эти данные?» ответа нет.
Лечение: либо честно показать пустое состояние и одну заполненную карточку, либо проговорить, какие источники данных предполагаются.
Анимация ради анимации
Симптом: каждый переход — Smart Animate с пружинкой. Через пять минут заказчик начинает уставать, через десять — раздражаться.
Лечение: анимация только там, где она объясняет связь между состояниями. Везде остальное — мгновенный переход.
Вопросы для ревью прототипа
Если есть возможность прогнать прототип через коллегу до показа — дайте ему этот список. Если нет — задайте вопросы себе, честно.
От лица заказчика
- Я понимаю, что это за продукт, после первого экрана?
- Я вижу, как решается моя задача, ради которой я заказывал работу?
- Есть ли момент, где я не понимаю, что произойдёт после нажатия?
- Есть ли экран, который меня удивил в плохом смысле — «а это зачем»?
От лица разработчика
- Я могу собрать это на текущем стеке без героизма?
- Я понимаю, какие данные приходят с бэка, а какие генерируются на клиенте?
- Анимации описаны достаточно, чтобы я их повторил, или мне придётся импровизировать?
От лица дизайнера в команде
- Я бы смог открыть этот файл через полгода и понять, как им пользоваться?
- Компоненты названы так, что их можно найти поиском?
- Если меня завтра не будет — кто-то сможет продолжить с этого файла?
Короткий практический итог
Хороший показ прототипа — это не магия и не харизма. Это сумма скучных решений, принятых до встречи: выбран один сценарий вместо пяти, моковые данные похожи на настоящие, переходы согласованы с разработкой, анимации работают на смысл, а не на эффект. Заказчик соглашается не потому, что вы красиво продали, а потому, что ему нечего возразить — всё, что он видит, выглядит как продукт, который реально будет жить. Остальное — спокойствие на самом показе и готовность услышать «а давайте вот это переделаем» без обиды.
