Плохой прототип легко спутать с плохим интерфейсом. Человек нажимает на кнопку, ничего не происходит, он замирает, модератор объясняет: "Тут ещё не собрано, представьте, что открылось окно". Через десять минут команда обсуждает уже не UX-риски, а то, что в макете не хватало пары экранов и нормального текста.
Такой тест не бесполезен, но он шумный. Он показывает не только проблемы будущего продукта, но и недоделки Figma-файла. Поэтому подготовка Figma-прототипа к юзабилити-тестированию — это не формальность перед созвоном. Нужно собрать один понятный путь, добавить важные состояния, заменить плейсхолдеры на реалистичные данные и проверить, как ссылка открывается у человека снаружи команды.
Это не статья о том, зачем вообще проверять макеты до разработки. Для этого есть отдельный разбор про тестирование интерфейса и прототипа до разработки. Здесь разбираем более приземлённый вопрос: что именно поправить в Figma, чтобы тест оценивал сценарий, а не вашу дизайнерскую кухню.
Что значит подготовить Figma-прототип
Готовый к тесту прототип не обязан быть полной копией продукта. Часто наоборот: чем уже путь, тем легче понять, где человек правда запутался.
Хороший тестовый прототип похож на маленькую рабочую модель. В нём есть стартовый экран, понятная задача, несколько ожидаемых кликов, ошибка или пустое состояние там, где оно влияет на решение, и финал, после которого ясно: человек прошёл сценарий или нет.
Figma даёт для этого всё нужное: отдельные маршруты, стартовые экраны, переходы, всплывающие слои, настройки устройства и поведение скролла. В официальном гайде Figma по прототипированию эти настройки описаны как способ собрать пользовательский путь и поделиться ссылкой на конкретный starting point — экран, с которого начинается проверка. Важно только помнить: кликабельность сама по себе ещё не делает прототип тестируемым. Можно связать десятки экранов и всё равно получить макет, который подсказывает ответ или ломается на втором шаге.
Начните с одного человеческого пути
Самая частая ошибка — пытаться проверить "весь интерфейс". В Figma это особенно соблазнительно: все фреймы рядом, всё вроде связано, можно открыть общий прототип и сказать человеку "попробуйте разобраться". Но дальше один уходит в настройки, второй кликает профиль, третий ищет отчёт, а команда получает мешок разрозненных наблюдений.
Лучше выбрать одну ситуацию. Например: продуктовый менеджер хочет быстро проверить Figma-прототип перед планированием разработки. Он открывает UXDog, добавляет ссылку на прототип, выбирает сценарий и запускает аудит. Всё. Это уже достаточно большой путь: тут есть ссылка, доступ, задача, ожидание результата и следующее действие команды.
В самом Figma-файле такой путь лучше собрать отдельным flow. Не оставляйте респондента в общем дизайнерском полотне, где видны старые варианты, эксперименты и соседние экраны. Назовите ключевые фреймы спокойно и понятно: start, access-error, task-setup, review, success. Это не для красоты. После теста команде будет проще понять, на каком шаге появилась проблема.
Не рисуйте весь продукт
Для проверки первого запуска аудита не нужен весь кабинет, биллинг, история отчётов и настройки команды. Нужны только экраны, без которых человек не сможет поверить в задачу: поле для Figma-ссылки, состояние ошибки доступа, экран с описанием сценария, подтверждение запуска, ожидание анализа и финал с первыми результатами.
Контекстные экраны тоже могут пригодиться. Иногда человек почти не трогает страницу проекта или пустой отчёт, но они помогают ему почувствовать, что он находится в настоящем продукте, а не в трёх карточках для презентации. Если контекста нет совсем, респондент начинает играть в угадайку: "что дизайнеры хотели показать?".
Обычно здесь достаточно одного простого правила: дорисовывайте не всё, что есть в продукте, а то, без чего человек не сможет принять решение в выбранном сценарии.
Сделайте рабочими ожидаемые клики
Люди редко идут ровно по маршруту дизайнера. Они нажимают не только большую жёлтую кнопку, но и карточку целиком, иконку, ссылку в тексте, стрелку назад, крестик, вторичное действие. Если всё это молчит, вы теряете часть поведения.
Не нужно прототипировать весь сервис. Но если элемент выглядит кликабельным в проверяемом пути, у него должно быть поведение. Иногда это переход. Иногда модальное окно. Иногда короткая заглушка: "Этот раздел в тесте не проверяем". С заглушками лучше не переборщить: каждая такая фраза напоминает человеку, что перед ним не продукт, а макет.
Перед тестом полезно пройти путь не глазами автора, а глазами человека, который видит экран впервые. Куда он нажмёт, если не понял основной CTA? Как вернётся назад? Что попробует открыть, если не доверяет следующему шагу? Эти клики часто и дают самые полезные UX-сигналы.
Добавьте состояния, где человек может сомневаться
Happy path почти всегда выглядит убедительнее реального продукта. Данные загрузились, доступ есть, форма заполнена, ошибок нет, всё быстро закончилось. Такой прототип удобно показывать на демо, но для теста он слишком гладкий.
В реальном сценарии человек встречает пустоту, лимиты, ошибки доступа, загрузку, предупреждения и подтверждения. Если этих состояний нет, тест становится добрее, чем будущий продукт.
Представьте экран, где PM вставляет ссылку на Figma. В идеальном прототипе он вставил URL и сразу попал дальше. В настоящей жизни ссылка может быть приватной, вести не на тот файл, не иметь view-доступа или открываться с тяжёлым прототипом. Если вы не покажете хотя бы одно такое состояние, вы не узнаете, понимает ли человек, что делать, когда путь перестал быть идеальным.
Замените плейсхолдеры на нормальные данные
Lorem ipsum ломает тест тихо. Человек вроде бы проходит сценарий, но не может принять настоящее решение: названия одинаковые, ошибки абстрактные, проект называется "Project name", а задача не связана с тем, что написано на экране.
Для тестового прототипа не нужен идеальный копирайтинг. Нужны данные, похожие на жизнь. Если в задании человек проверяет прототип лендинга, пусть в интерфейсе будет понятное название проекта, реальная роль, нормальная ссылка на Figma, живой текст ошибки и результат, который можно обсудить.
Самая неприятная ошибка здесь — несостыковка между заданием и экраном. В задаче написано "проверьте прототип для команды из пяти человек", а на экране всё говорит про одиночный проект без коллег. Человек застрянет, но это будет не UX-проблема будущего продукта, а шум из тестовых данных.
Уберите подсказки правильного пути
Прототип для презентации часто слегка помогает зрителю: активная зона подсвечена, нужная кнопка крупнее, стартовый экран ведёт прямо к правильному действию, а текст рядом объясняет то, что должен объяснять интерфейс.
Для теста это опасно. Если прототип уже показал, куда нажимать, вы больше не знаете, нашёл бы человек этот путь сам.
Плохое задание звучит так:
Нажмите кнопку Запустить аудит и дождитесь отчёта.Хорошее задание описывает ситуацию:
Вы отвечаете за продуктовую команду из пяти человек. Вам нужно понять, можно ли быстро проверить новый Figma-прототип перед разработкой. Откройте UXDog, добавьте ссылку на прототип, выберите сценарий и запустите проверку.
Во втором варианте нет названия кнопки и нет маршрута по шагам. Человек сам читает интерфейс и принимает решение. Именно это нам и нужно проверить.
Проверьте настройки Figma перед запуском
Технические настройки тоже влияют на результат. Если прототип открывается не с того экрана, не скроллится или показывает лишний фон, человек будет бороться с просмотрщиком, а не с интерфейсом.
Перед отправкой ссылки пройдитесь по короткому списку:
- starting point ведёт на начало нужного сценария;
- каждый flow проверяет одну задачу;
- финальный экран ясно показывает, что сценарий завершён;
- scroll, overflow, fixed и sticky элементы ведут себя как в реальном продукте;
- overlays не закрывают важные клики;
- ссылка открывается у человека с view-доступом;
- в Presentation view не видны лишние экраны и черновики.
Для мобильных прототипов это особенно важно. Масштаб, адресная строка браузера, скролл и жесты могут изменить ощущение от интерфейса сильнее, чем кажется на десктопе. Откройте ссылку не только у себя в Figma, но и в обычном браузере, примерно так, как её увидит респондент.
Пример: первый запуск UX-аудита
Допустим, команда хочет проверить onboarding UXDog. Пользователь должен вставить ссылку на Figma-прототип, описать сценарий и запустить аудит.
В сыром прототипе есть красивый экран с полем для ссылки и кнопкой "Далее". После клика сразу появляется успешный результат. Вроде бы путь есть, но тест почти ничего не покажет: нет ошибки доступа, нет ожидания, нет вопроса "какой сценарий я проверяю?", нет результата, по которому команда решает, что чинить.
В подготовленном прототипе путь становится честнее. Если ссылка приватная, появляется понятная ошибка. Если сценарий не описан, человек видит, что именно нужно дописать. После запуска есть состояние ожидания, а в конце — короткий список найденных UX-рисков. Теперь тест проверяет не то, заметит ли человек жёлтую кнопку, а понимает ли он смысл проверки и следующий шаг.
Как проверить подготовленный прототип через UXDog
Когда прототип готов, его можно показать команде, реальным пользователям или быстро прогнать через UXDog. Здесь важно не путать уровни доказательности: ИИ-респонденты не заменяют реальных людей, но помогают рано увидеть очевидные разрывы сценария.
В UXDog лучше передавать не просто ссылку на весь Figma-файл, а короткий пакет проверки: конкретный flow, задачу без подсказок, контекст аудитории, критерий успеха и ограничения. Например: "проверяем только первый запуск аудита; кабинет и биллинг не оцениваем".
На выходе команда получает не оценку красоты макета, а список вероятных UX-рисков по шагам: где смысл теряется, где человек ожидал бы другой клик, где текст читается неверно, где не хватает состояния или подтверждения. После этого можно исправить очевидные проблемы и уже более осмысленно идти к реальным пользователям, если решение дорогое или риск высок.
Чеклист перед тестированием
Оставьте этот список на финальный прогон перед тестом:
- выбран один сценарий;
- есть старт и понятный финал;
- ключевые клики работают;
- важные состояния добавлены;
- данные и тексты похожи на реальные;
- задание не называет конкретную кнопку;
- starting point, device, scroll и overlays проверены;
- ссылка открывается с view-доступом;
- понятно, какие наблюдения будут считаться UX-проблемой.
Если не работает старт, финал, доступ по ссылке или ключевые состояния, тест лучше перенести. Иначе вы потратите сессию на объяснения и получите список проблем, которые относятся не к UX-решению, а к недособранному макету.
FAQ
Как подготовить прототип к тестированию в Figma?
Выберите один сценарий, соберите для него отдельный flow, задайте starting point, добавьте ключевые клики и состояния, замените placeholder-данные на реалистичные, уберите подсказки правильного пути и проверьте ссылку с view-доступом в Presentation view.
Нужно ли делать Figma-прототип полностью интерактивным?
Нет. Нужна интерактивность, которая поддерживает проверяемый сценарий. Если человек должен добавить Figma-ссылку и запустить аудит, соберите этот путь и ожидаемые боковые действия. Не нужно прототипировать весь личный кабинет.
Можно ли тестировать low-fi прототип?
Можно, если вы проверяете концепцию, порядок шагов или базовую логику. Но чем ближе вопрос к текстам, визуальной иерархии, доверию, выбору и ошибкам, тем реалистичнее должен быть прототип.
Можно ли использовать ИИ-респондентов для проверки Figma-прототипа?
Да, как предварительный UX-аудит, если подготовлены flow, задача, состояния и реалистичный текст. Это быстрый способ увидеть очевидные риски: непонятный CTA, слабый текст, пропущенное состояние, неверную логику шага. Для важных решений выводы лучше подтверждать реальными пользователями.
Что в итоге
Figma-прототип для юзабилити-тестирования — это не набор красивых экранов. Это рабочая модель одного пользовательского пути. Она должна быть достаточно реалистичной, чтобы человек поверил в задачу, и достаточно сфокусированной, чтобы команда получила ответ на конкретный вопрос.
Перед тестом проверьте не только переходы, но и состояния, данные, тексты, масштаб, скролл, стартовый экран и само задание. Чем меньше вы объясняете прототип словами, тем честнее результат.
А если нужно быстро понять, где сценарий может сломаться, подготовленный Figma-прототип можно сначала прогнать через UXDog. Так команда получит не мнение о красоте макета, а список мест, где путь может сломаться: шаг, вероятную причину риска и то, что стоит исправить до разработки.