Когда команда уже собрала прототип в Figma, очень легко попасть в ловушку внутренней уверенности. Дизайнер понимает логику экранов, продуктовый менеджер знает, зачем нужна каждая функция, разработчики видят привычные паттерны интерфейса. Внутри команды сценарий кажется очевидным — но для человека, который впервые открыл продукт, все может выглядеть иначе.
Именно поэтому я обычно рекомендую проверять ключевые пользовательские сценарии еще на этапе прототипа, до начала полноценной разработки. В работе с исследованиями мы регулярно сталкиваемся с ситуациями, когда проблема обнаруживается не в визуальном оформлении, а в самой логике: пользователь не понимает название раздела, не замечает нужное действие, выбирает неожиданный путь или иначе интерпретирует последовательность шагов. Исправить такой сценарий в Figma значительно проще, чем после того, как интерфейс уже сверстан, связан с бизнес-логикой и включен в релизный план.
Удаленное тестирование позволяет проверить прототип на реальных пользователях без организации очной лаборатории. Респондент получает задачу, открывает интерактивный Figma-прототип и пытается выполнить конкретный сценарий: оформить заказ, найти настройку, зарегистрироваться, выбрать тариф, отправить заявку или выполнить другое целевое действие. Исследователь при этом оценивает не только итоговый ответ пользователя, но и то, как человек пришел к результату.
Это принципиальное отличие UX-тестирования от обычного сбора мнений. Вопрос «Нравится ли вам этот интерфейс?» почти ничего не говорит о том, сможет ли человек им пользоваться. Пользователь может высоко оценить дизайн и при этом не найти нужную кнопку. Или, наоборот, назвать интерфейс непривычным, но быстро и без ошибок выполнить все задания.
Поэтому перед тестированием я советую формулировать не вопрос «хороший ли получился дизайн», а конкретную исследовательскую задачу. Например: понимают ли пользователи, где изменить способ доставки; могут ли они самостоятельно найти историю платежей; замечают ли функцию экспорта; правильно ли интерпретируют название нового раздела. Чем точнее определена проверяемая гипотеза, тем полезнее будут результаты.
Удаленный формат особенно удобен для продуктовых команд, UX/UI-дизайнеров, исследователей и менеджеров, которым нужно быстро проверить решение на нескольких участниках, сравнить варианты прототипа или собрать обратную связь перед следующей итерацией. При этом само наличие Figma-прототипа еще не делает исследование качественным. Нужно правильно подготовить сценарии, подобрать респондентов, сформулировать задания без подсказок и заранее определить, какие данные будут использоваться при принятии решения.
В этой статье я разберу именно такой рабочий подход: от подготовки Figma-прототипа и исследовательских заданий до проведения удаленного теста и анализа результатов. Отдельно покажу, как можно сочетать интерактивный прототип с онлайн-опросом, чтобы собирать не только свободные комментарии пользователей, но и структурированные данные, которые удобно сравнивать между участниками и итерациями продукта.
Figma-прототип позволяет проверить не только отдельные экраны, но и логику взаимодействия с продуктом. Однако перед исследованием важно определить, что именно мы хотим узнать. Чем шире задача в духе «посмотрим, как пользователи отреагируют», тем сложнее потом интерпретировать результаты.
В своей работе я стараюсь начинать с конкретного пользовательского сценария и связанной с ним гипотезы. Например, команда предполагает, что пользователь без дополнительных инструкций сможет найти функцию повторного заказа. Тогда предметом тестирования становится не весь интерфейс, а конкретный путь: где человек начинает поиск, какие элементы замечает, куда переходит и в какой момент понимает, что нашел нужное действие.
Какие задачи хорошо подходят для тестирования прототипа
На интерактивном прототипе можно проверить несколько типов продуктовых гипотез:
Например, команда проектирует личный кабинет сервиса и сомневается, куда поместить управление подпиской. Вместо прямого вопроса «Где вам удобнее видеть управление подпиской?» я бы предложил дать участнику задачу: «Представьте, что вы хотите изменить текущий тариф. Покажите, как бы вы это сделали».
Так мы получаем данные о поведении, а не только мнение о предложенных вариантах.
Не спрашивать там, где можно наблюдать
Это один из принципов, который особенно полезен при работе с прототипами.
Представим, что после демонстрации нового меню мы спрашиваем: «Вам понятно, где находится история заказов?» Респондент отвечает «да». Кажется, что решение работает.
Но если дать ему задание самостоятельно найти заказ, сделанный три месяца назад, может оказаться, что сначала он открывает «Профиль», затем «Платежи», возвращается назад и только после этого замечает раздел «Заказы».
Формально пользователь нашел нужный экран. Но его путь показывает проблему, которую мы не обнаружили бы прямым вопросом.
Поэтому я разделяю декларируемые ответы и наблюдаемое поведение. Первые помогают понять восприятие пользователя, второе — увидеть, насколько интерфейс действительно поддерживает выполнение задачи. Для полноценного анализа нужны оба источника.
В удаленном исследовании их можно сочетать. Участник проходит сценарий в Figma, а после него отвечает на несколько вопросов: удалось ли выполнить задачу, насколько сложным показался процесс, в каком месте возникло затруднение и чего не хватило. Для структурированного сбора таких ответов можно использовать Тестограф, связывая этапы исследования с переходами к прототипу.
Что Figma-прототип проверить не сможет
У метода есть ограничения, которые стоит учитывать еще при планировании исследования. Прототип имитирует продукт, но не является самим продуктом. Поэтому поведение участника в нем нельзя автоматически переносить на все ситуации использования готового сервиса.
Например, кликабельный макет плохо подходит для оценки реальной скорости загрузки, производительности, стабильности сложных взаимодействий или поведения интерфейса при нестандартных данных. Ограниченная интерактивность также способна сама создавать искусственные затруднения: пользователь нажимает туда, куда логично было бы нажать в настоящем продукте, но дизайнер просто не предусмотрел этот переход.
Это важный сигнал для исследователя. Не каждое затруднение респондента является UX-проблемой. Иногда проблема находится в самом прототипе.
Есть и другое ограничение: прототип не воспроизводит реальную мотивацию пользователя. Человек, которому мы дали задание «выберите подходящий тариф», находится в другой ситуации, чем клиент, который действительно собирается заплатить за подписку. Поэтому вывод «участники выбрали тариф Pro» еще не означает, что реальные покупатели будут выбирать его с такой же частотой.
По этой же причине я осторожно отношусь к попыткам измерять конверсию на Figma-прототипах. Мы можем сравнивать успешность прохождения сценариев, фиксировать затруднения и находить проблемные места, но прогнозировать реальную коммерческую конверсию только на основании такого теста было бы некорректно.
Главный вопрос перед началом исследования
До подготовки анкеты и поиска респондентов полезно закончить одну фразу:
«После этого тестирования мы хотим понять, смогут ли пользователи…»
Например: «…самостоятельно изменить тариф», «…найти результаты предыдущего заказа», «…понять назначение новой функции».
Если продолжение получается конкретным, исследование уже имеет хорошую основу. Если вместо этого возникает формулировка вроде «узнать мнение о новом дизайне», задачу стоит сузить.
Практическая ценность тестирования появляется тогда, когда результат способен повлиять на решение команды. Поэтому еще до первого респондента желательно понимать: какой результат подтвердит гипотезу, какой заставит ее пересмотреть и что именно мы будем менять в прототипе в каждом случае.
Одна из частых ошибок при подготовке UX-теста — стремление сделать прототип максимально похожим на готовый продукт. Команда добавляет дополнительные экраны, прорабатывает все состояния, исправляет тексты и неделями доводит визуальные детали. Для исследования такая глубина нужна далеко не всегда.
Я обычно предлагаю идти от сценария: сначала определить, какое поведение мы проверяем, и только после этого решать, какие экраны и переходы действительно нужны. Если задача исследования — понять, сможет ли пользователь изменить способ доставки уже оформленного заказа, нам не обязательно полностью прототипировать каталог, регистрацию, оплату и личный кабинет.
Прототип должен быть достаточно реалистичным, чтобы участник мог воспринимать сценарий естественно, но не обязательно полностью функциональным.
Определяем границы сценария
Перед сборкой прототипа полезно зафиксировать три точки: где пользователь начинает, какую задачу он получает и какое состояние интерфейса считается успешным завершением.
Допустим, мы тестируем изменение тарифа. Пользователь начинает с главной страницы личного кабинета. Его задача — перейти на другой тариф. Успешное завершение — экран подтверждения выбранного тарифа. Все, что находится за пределами этого пути и не влияет на решение пользователя, можно не прорабатывать настолько же подробно.
При этом нельзя оставлять кликабельной только «правильную» кнопку. Если на экране есть несколько элементов, которые пользователь вполне может выбрать в рамках поставленной задачи, желательно предусмотреть хотя бы базовую реакцию на эти действия. Иначе мы рискуем принять техническое ограничение макета за проблему интерфейса.
Проверяем прототип глазами участника
Перед запуском исследования я рекомендую самостоятельно пройти весь сценарий не из редактора Figma, а по той же ссылке, которую получат респонденты. Еще лучше — попросить это сделать коллегу, который не участвовал в создании прототипа.
Проверить стоит несколько вещей:
Последний пункт особенно важен. Если мы проверяем мобильный интерфейс, прохождение прототипа на ноутбуке и смартфоне может давать разный опыт. Это необходимо учитывать и при подготовке макета, и при анализе результатов.
Не превращаем прототип в подсказку
Иногда команда специально делает исследуемый элемент заметнее перед тестированием: увеличивает кнопку, добавляет контраст или сокращает количество соседних элементов. Формально сценарий после этого становится проще, но исследование уже отвечает на другой вопрос.
Если мы хотим проверить, сможет ли пользователь найти функцию в предполагаемом интерфейсе, прототип должен максимально точно воспроизводить контекст, в котором эта функция появится. Особенно это касается навигации, расположения элементов, названий разделов и визуальных акцентов.
Не стоит также объяснять устройство интерфейса перед выполнением задания. Фраза «В верхнем меню есть раздел управления подпиской» практически уничтожает возможность проверить, сможет ли человек найти этот раздел самостоятельно.
Используем реалистичные данные
Абстрактные подписи вроде «Товар 1», «Название услуги» или «Текст здесь» могут менять поведение участника. Человек начинает воспринимать интерфейс как макет и меньше опирается на содержание.
По возможности я использую реалистичные, но вымышленные данные: названия товаров, суммы, даты, статусы заказов, описания услуг. Они должны помогать погрузиться в ситуацию, но не создавать дополнительные подсказки.
Особенно внимательно стоит относиться к данным, связанным с заданием. Если мы проверяем поиск нужной операции в истории платежей, один единственный платеж на экране сделает сценарий искусственно простым. Лучше создать контекст, в котором пользователю действительно придется принять решение.
Проведите пилот до приглашения основной выборки
Даже тщательно подготовленный сценарий желательно сначала проверить на одном-двух пилотных участниках. Здесь нас интересует не столько сам интерфейс, сколько качество исследования.
На пилоте часто обнаруживается, что формулировка задания подсказывает решение, участники неправильно понимают исходную ситуацию, ссылка открывается не на том экране или после определенного действия невозможно вернуться к сценарию. Исправлять такие проблемы после десятков полученных ответов значительно неприятнее.
Если исследование строится как последовательность «инструкция → задание → Figma → вопросы после выполнения», эту логику удобно предварительно собрать в Тестографе и пройти самостоятельно от первого до последнего экрана именно так, как это сделает респондент.
Для меня такой технический прогон — обязательная часть подготовки. Его задача проста: отделить будущие проблемы пользователей от проблем исследовательского инструмента. Если человек не смог пройти сценарий, мы должны быть уверены, что причиной был исследуемый интерфейс, а не неработающая ссылка или пропущенный переход в прототипе.
После этого можно переходить к наиболее чувствительной части подготовки — формулировке заданий. Даже хороший Figma-прототип даст мало полезных данных, если само задание заранее подсказывает пользователю нужное действие.
Качество удаленного тестирования сильно зависит от формулировки задания. Можно подготовить реалистичный Figma-прототип, правильно подобрать участников, но получить искаженные результаты из-за одной фразы, которая невольно подсказывает нужный путь.
На практике я проверяю задания простым способом: смотрю, не повторяют ли они названия кнопок, разделов и других элементов прототипа. Если пользователь видит в задании те же слова, что и в интерфейсе, исследователь фактически дает ему поисковую подсказку.
Предположим, мы хотим проверить, смогут ли пользователи найти управление подпиской. Формулировка «Перейдите в раздел “Подписка” и измените тариф» для UX-теста практически бесполезна. Мы уже сообщили человеку, где находится нужная функция.
Гораздо полезнее поставить задачу через жизненную ситуацию: «Представьте, что текущих возможностей сервиса вам стало недостаточно и вы решили перейти на другой тариф. Покажите, как бы вы это сделали».
Во втором случае участнику приходится самостоятельно интерпретировать интерфейс и выбирать путь. Именно это поведение нам и нужно увидеть.
Цель пользователя вместо инструкции
Хорошее задание описывает не интерфейс, а ситуацию и намерение человека. Пользователь должен понимать, чего ему необходимо добиться, но не получать инструкцию, как именно это сделать.
Я обычно строю формулировку из трех элементов:
Например: «Вы недавно сделали заказ и хотите, чтобы следующую доставку курьер привез по другому адресу. Используя этот интерфейс, попробуйте изменить адрес доставки».
Здесь нет слов «откройте профиль», «перейдите в настройки» или «нажмите “Адреса”». Если участники самостоятельно выбирают один и тот же путь, мы получаем полезный сигнал о понятности структуры. Если начинают искать функцию в совершенно разных местах, это тоже результат, который стоит анализировать.
Не проверяйте память вместо интерфейса
Еще одна проблема возникает, когда задание перегружено условиями. Например: «Найдите заказ от 14 августа стоимостью 3 490 рублей, откройте его, выберите третий товар и попробуйте оформить возврат на банковскую карту».
В такой ситуации часть ошибок может быть связана не с интерфейсом, а с тем, что участник забыл одно из условий. Чем больше информации человеку приходится удерживать в памяти, тем сложнее понять причину затруднения.
Если детали необходимы для сценария, их лучше сделать доступными участнику на протяжении всего задания или разбить длинный сценарий на несколько последовательных этапов.
Не спрашивайте заранее о том, что собираетесь проверить
Порядок вопросов тоже способен повлиять на поведение.
Допустим, перед работой с прототипом мы спрашиваем: «Где бы вы искали возможность отменить подписку?» После этого даем Figma-прототип и просим отменить подписку. Первый вопрос уже заставил человека задуматься о расположении функции и сформировать гипотезу. Его последующее поведение нельзя считать полностью спонтанным.
Поэтому вопросы о понятности, сложности и причинах выбора обычно лучше задавать после выполнения задания.
Сначала пользователь действует. Затем мы выясняем, как он интерпретировал интерфейс.
Какие вопросы задавать после сценария
После взаимодействия с прототипом не стоит превращать исследование в длинную анкету. Каждый вопрос должен помогать объяснить наблюдаемое поведение или сравнить результаты разных участников.
Например, можно спросить, насколько легко или сложно было выполнить задачу, насколько участник уверен, что достиг нужного результата, и что вызвало наибольшее затруднение. Если человек не завершил сценарий, полезно выяснить, чего он ожидал увидеть и в какой момент понял, что не знает, как продолжить.
Для немодерируемого исследования такую последовательность удобно собрать в Тестографе: сначала показать контекст и задание, затем направить участника в Figma-прототип, а после прохождения сценария собрать ответы на закрытые и открытые вопросы.
При этом я не советую полагаться только на шкалу вроде «Насколько легко было выполнить задачу — от 1 до 10». Число удобно сравнивать между респондентами, но оно не объясняет причину оценки. Поэтому количественный вопрос полезно дополнить коротким открытым: «Что в этом задании показалось вам наиболее сложным?»
Проверяем формулировки до запуска
Перед основным исследованием я перечитываю каждое задание, одновременно глядя на прототип. Это помогает заметить совпадения между словами в задании и названиями элементов интерфейса.
Есть простой контрольный вопрос: сможет ли участник выполнить задание только потому, что мы употребили в нем название нужной кнопки или раздела?
Если да, формулировку стоит изменить.
Хорошее задание оставляет пользователю свободу выбора пути, но не создает неопределенности относительно цели. Человек должен понимать, что ему нужно получить, а исследователь — наблюдать, как именно он попытается этого добиться.
Именно здесь тестирование начинает показывать реальную ценность прототипа. Мы перестаем проверять, умеет ли респондент следовать инструкции, и начинаем проверять, способен ли интерфейс сам направить его к нужному действию.
После подготовки прототипа и заданий нужно выбрать формат исследования. Удаленное тестирование не обязательно означает, что респондент остается один на один с Figma. Исследователь может присутствовать на сессии и наблюдать за действиями пользователя либо полностью автоматизировать прохождение сценария.
Выбор между модерируемым и немодерируемым форматом я обычно связываю не с размером команды или бюджетом, а с тем, какие данные необходимо получить. Если нам важно разобраться в причинах поведения пользователя, полезнее живое общение. Если нужно одинаково провести один сценарий через большее число участников и сравнить результаты, удобнее автоматизированный подход.
Модерируемое тестирование
В этом формате исследователь и участник подключаются к видеозвонку. Респондент получает ссылку на Figma-прототип, демонстрирует экран и выполняет задания, а исследователь наблюдает за его действиями.
Главное преимущество — возможность разобраться в неожиданном поведении непосредственно во время сессии. Например, пользователь несколько секунд смотрит на экран, открывает один раздел, возвращается и выбирает другой. В немодерируемом тесте мы можем увидеть сам факт затруднения, но не всегда поймем его причину. Во время интервью можно аккуратно уточнить, что человек ожидал найти или почему выбрал определенный путь.
Однако модератор сам способен повлиять на результат. Если участник долго не может продолжить, возникает естественное желание помочь: «Посмотрите еще в верхней части страницы» или «А этот раздел вы уже открывали?» После такой подсказки мы уже не можем считать дальнейшее прохождение самостоятельным.
Поэтому во время модерируемых сессий я стараюсь не объяснять интерфейс. Лучше попросить участника проговаривать ожидания: «Что вы сейчас пытаетесь найти?» или «Что вы ожидаете увидеть после этого действия?» Такие вопросы дают дополнительный контекст, но не указывают правильный путь.
Немодерируемое тестирование
Здесь участник самостоятельно получает инструкцию, открывает прототип, выполняет задание и отвечает на вопросы. Исследователь не присутствует во время прохождения.
Такой подход удобен, когда сценарий уже достаточно хорошо отработан и его можно описать без дополнительных пояснений. Еще одно преимущество — стандартизация: все респонденты получают одинаковые инструкции и вопросы, поэтому влияние модератора снижается.
Для организации такого сценария можно использовать онлайн-опрос Тестографа. В нем участнику можно последовательно дать вводную информацию и исследовательское задание, направить его к Figma-прототипу, а затем собрать оценки и развернутые комментарии после выполнения.
При немодерируемом формате особенно важен пилот. Исследователя рядом не будет, поэтому любая двусмысленная инструкция или техническая проблема может привести к ответу, который невозможно корректно интерпретировать.
Когда имеет смысл объединить два подхода
На практике я часто предпочитаю не выбирать один формат для всего исследования, а использовать их последовательно.
Например, первые несколько сессий можно провести с модератором. Они помогают увидеть неожиданные стратегии поведения, обнаружить слабые места прототипа и проверить сами задания. После корректировки сценария его можно запустить в немодерируемом формате на более широкой выборке.
Получается полезная комбинация: модерируемая часть отвечает преимущественно на вопрос «почему это происходит?», а стандартизированная часть помогает понять, насколько регулярно мы наблюдаем конкретную проблему среди участников исследования.
Но здесь важно не смешивать данные механически. Пять подробных интервью и 30 ответов в анкете — не «35 одинаковых наблюдений». У этих источников разная глубина и условия получения данных, поэтому анализировать их лучше как взаимодополняющие части исследования.
Как выглядит гибридный сценарий Figma + Тестограф
Сам Figma-прототип отвечает за взаимодействие с интерфейсом, а анкета — за структуру исследования. Например, респондент сначала проходит скрининг и получает описание ситуации, затем выполняет задание в прототипе и возвращается к вопросам о своем опыте.
Через Тестограф можно собирать ответы в едином формате, что особенно полезно при нескольких сценариях или версиях прототипа. Исследователь получает не набор разрозненных комментариев, а данные, которые можно сопоставлять между участниками.
При этом инструменты не заменяют методологию. Можно идеально настроить переходы между анкетой и Figma и все равно получить слабые результаты, если участники не соответствуют целевой аудитории.
Поэтому после выбора формата следующий вопрос — кого именно приглашать на тестирование и сколько респондентов действительно потребуется для поставленной исследовательской задачи.
Даже хорошо подготовленный Figma-прототип и аккуратно сформулированные задания не помогут, если исследование проводится не с той аудиторией. Поэтому при планировании тестирования я сначала определяю не количество участников, а критерии, по которым человек вообще может попасть в выборку.
Если мы тестируем интерфейс для бухгалтеров, мнение случайных пользователей цифровых сервисов не заменит опыт людей, которые действительно работают с бухгалтерскими задачами. Аналогично, проверяя оформление повторного заказа, имеет смысл привлекать людей, знакомых с соответствующим покупательским сценарием.
Начинаем с профиля участника
Критерии отбора должны вытекать из исследуемого сценария. Для одного продукта будет важен профессиональный опыт, для другого — частота покупок, использование определенных сервисов или недавний опыт решения конкретной задачи.
При этом слишком узкий профиль тоже способен создать проблему. Если установить десять обязательных критериев, поиск респондентов усложнится, хотя часть ограничений никак не влияет на исследуемое поведение.
Я обычно разделяю критерии на обязательные и дополнительные. Обязательные определяют, способен ли человек реалистично оказаться в проверяемой ситуации. Дополнительные позволяют сравнивать отдельные сегменты, если такое сравнение действительно предусмотрено исследованием.
Для предварительного отбора можно использовать короткий скрининг. Например, перед основным заданием задать несколько вопросов об опыте респондента и в зависимости от ответов определить дальнейший маршрут исследования. Такой сценарий можно организовать через Тестограф, чтобы неподходящие участники не переходили к основной части тестирования.
Не раскрывайте цель исследования в скрининге
Скрининговые вопросы тоже могут создавать подсказки. Если перед тестированием новой функции управления подпиской подробно расспрашивать человека о том, где он обычно меняет тариф и как ищет настройки подписки, участник заранее начинает размышлять о будущем задании.
Поэтому скрининг должен проверять соответствие профилю, а не репетировать UX-тест.
Полезнее спросить, какими типами сервисов человек пользовался за определенный период или решал ли соответствующую задачу, чем заранее выяснять его ожидания относительно конкретного элемента интерфейса.
Еще одна распространенная проблема — слишком очевидный «правильный» ответ. Если из формулировки понятно, кого ищет исследователь, некоторые участники могут выбирать подходящий вариант просто для продолжения опроса. Нейтральные вопросы и менее прозрачная логика отбора помогают снизить этот риск.
Сколько участников нужно для тестирования
Универсального числа здесь нет. Я бы с осторожностью относился к правилу «для UX-теста всегда достаточно пяти человек». Небольшая выборка действительно может быстро выявить заметные проблемы, особенно если участники относятся к одной достаточно однородной группе. Но это не означает, что пять респондентов подходят для любого исследования.
Необходимое количество зависит от нескольких факторов: сложности сценария, разнообразия аудитории, числа исследуемых сегментов и того, какие выводы команда собирается сделать по результатам.
Если мы тестируем один короткий сценарий на однородной аудитории и хотим найти основные препятствия, разумно начинать с небольшой группы и смотреть, появляются ли новые типы проблем. Если же требуется сравнить новичков и опытных пользователей или проверить несколько существенно различающихся сценариев, участников понадобится больше.
Особенно осторожно нужно интерпретировать проценты на маленькой выборке. Если четыре человека из пяти выполнили задачу, математически это 80%, но представлять такой результат как устойчивый показатель успешности интерфейса было бы неправильно. В данном случае полезнее сказать: четыре из пяти участников завершили сценарий, а один столкнулся с конкретной проблемой.
Итерации полезнее одной большой волны
Для тестирования прототипов я часто предпочитаю несколько небольших последовательных исследований одной крупной волне.
Представим, что команда приглашает сразу 30 участников. После первых четырех сессий обнаруживается, что почти все неправильно понимают название основного раздела. Остальные 26 человек, вероятно, продолжат сталкиваться с той же проблемой, хотя команда уже получила достаточно сигнала, чтобы пересмотреть решение.
Более практичный подход выглядит иначе: провести первую серию тестов, проанализировать проблемы, изменить прототип и проверить обновленную версию на следующей группе. В таком случае каждый следующий участник помогает не просто подтверждать уже известную ошибку, а проверять новое решение.
Именно здесь преимущество прототипирования проявляется особенно хорошо. Figma позволяет относительно быстро изменить структуру, подписи или последовательность экранов и снова запустить тот же пользовательский сценарий.
Сегменты нельзя смешивать без необходимости
Если продуктом пользуются принципиально разные группы, результаты стоит рассматривать отдельно. Например, профессиональный инструмент может быть очевидным для опытного специалиста и совершенно непонятным для новичка. Средняя оценка двух групп скроет это различие.
Поэтому еще до рекрутинга важно решить, нужна ли нам одна аудитория или несколько сегментов. Если сегментация необходима, ее следует сохранить и при анализе.
В итоге вопрос «сколько человек нужно?» появляется только после другого вопроса: чье поведение мы хотим изучить и какое решение собираемся принять на основании наблюдений?
Для раннего Figma-прототипа зачастую ценнее несколько релевантных участников и две-три последовательные итерации, чем большая выборка, собранная за один раз. Когда аудитория определена, можно переходить к самому тесту — выстраивать путь респондента и решать, какие данные фиксировать на каждом этапе.
Когда прототип, задания и выборка готовы, начинается этап, на котором особенно важна последовательность. В удаленном тестировании участник должен пройти исследование без лишних догадок о том, что от него требуется, но одновременно без подсказок о правильном способе выполнения задачи.
Я стараюсь проектировать тест как отдельный пользовательский путь. Респондент не должен разбираться в организации исследования: искать нужную ссылку в письме, вспоминать номер задания после перехода в Figma или самостоятельно решать, когда возвращаться к анкете. Чем меньше таких организационных действий, тем выше вероятность, что наблюдаемые затруднения относятся именно к прототипу.
Путь участника от приглашения до завершения
В немодерируемом исследовании последовательность может выглядеть так: участник переходит по приглашению, при необходимости проходит скрининг, получает короткую вводную, знакомится с заданием, открывает Figma-прототип, выполняет сценарий и возвращается к вопросам о своем опыте.
Если сценариев несколько, я предпочитаю не показывать их все заранее. Иначе участник может запомнить будущие задания и начать специально обращать внимание на соответствующие элементы интерфейса.
Например, если второе задание связано с изменением способа оплаты, пользователь не должен знать об этом во время первого сценария. Иначе он может заранее заметить раздел «Способы оплаты», а во втором задании найти его не благодаря понятной навигации, а благодаря предыдущему знакомству.
Поэтому задания лучше выдавать последовательно.
Что фиксировать во время тестирования
Сам факт завершения задачи — важный, но недостаточный показатель. Два пользователя могут прийти к одному результату совершенно разными путями: первый сразу выберет нужный раздел, второй несколько раз ошибется, вернется назад и только затем случайно найдет правильное действие.
Для каждого сценария полезно фиксировать несколько типов данных:
Для модерируемого исследования эти данные можно заносить в заметки непосредственно во время сессии. В немодерируемом формате часть информации собирается через вопросы после выполнения задания.
Например, после сценария можно попросить оценить его сложность по шкале, а затем задать открытый вопрос: «Если что-то вызвало затруднение, расскажите, на каком этапе это произошло».
Так мы получаем количественный показатель для сравнения участников и текстовое объяснение, которое помогает его интерпретировать.
Не заставляйте респондента объяснять каждый клик
В модерируемых UX-тестах часто используется метод проговаривания мыслей. Он действительно дает полезную информацию, но применять его нужно аккуратно.
Если после каждого действия спрашивать «Почему вы сюда нажали?», естественное взаимодействие быстро превращается в интервью. Пользователь начинает анализировать каждое решение сильнее, чем делал бы это в обычной ситуации.
Я предпочитаю вмешиваться тогда, когда поведение требует уточнения. Например, участник долго не совершает действий или несколько раз возвращается к одному экрану. В такой момент можно спросить: «Что вы сейчас ищете?» или «Чего вы ожидали на этом экране?»
Важно не подменять наблюдение объяснением самого респондента. Пользователь не всегда может точно восстановить причину собственного действия. Поэтому комментарий «я сразу понял, куда нужно нажать» стоит сопоставить с тем, что происходило во время выполнения задачи.
Собираем данные в единой структуре
Если тестируется несколько сценариев или версий прототипа, заранее заданная структура существенно упрощает последующий анализ.
В Тестографе можно выстроить последовательность вопросов вокруг работы с Figma-прототипом и собирать закрытые и открытые ответы в одном исследовании. Например, после каждого задания фиксировать факт самостоятельного выполнения, оценку сложности и комментарий участника.
При этом я рекомендую сохранять одинаковые формулировки шкал для одинаковых сценариев. Если после первой задачи мы спрашиваем о сложности по шкале от 1 до 5, а после второй — от 1 до 10, сравнение без необходимости усложняется.
То же относится к направлению шкалы. Значение «1» не должно в одном вопросе означать «очень легко», а в другом — «очень сложно», если для этого нет методологической причины.
Отделяем UX-проблемы от проблем самого исследования
После первых участников полезно проверить не только результаты, но и качество исследовательского процесса.
Если несколько человек закрыли Figma сразу после открытия, возможно, проблема не в интерфейсе, а в доступе к прототипу. Если участники систематически выполняют не ту задачу, стоит перепроверить ее формулировку. Если многие не возвращаются к анкете после Figma, возможно, нужно сделать инструкцию перехода более заметной.
Такие случаи нельзя автоматически записывать в UX-проблемы продукта.
Поэтому при анализе я разделяю как минимум три источника затруднений: сам интерфейс, ограничения прототипа и устройство исследования. Это позволяет не отправлять дизайнеру на исправление проблему, которая на самом деле возникла из-за неработающего перехода или двусмысленной инструкции.
Собрать ответы — только половина работы. После завершения тестов нужно связать успешность выполнения, наблюдаемое поведение и комментарии участников, а затем определить, какие проблемы действительно повторяются и требуют изменения прототипа. Этому и посвящен следующий этап — анализ результатов.
После завершения тестирования возникает соблазн сразу составить список изменений для дизайнера. Пользователь не заметил кнопку — сделать ее ярче. Не понял название раздела — переименовать. Сказал, что экран перегружен, — убрать часть элементов.
Я бы не торопился переводить каждый комментарий в задачу на редизайн. Ценность UX-тестирования не в количестве замечаний, а в способности определить, какие из них указывают на реальную проблему пользовательского сценария.
Для этого я анализирую результаты на трех уровнях: что участник сделал, что произошло во время выполнения и как сам участник объяснил свой опыт. Эти данные могут как подтверждать друг друга, так и противоречить друг другу.
Сначала смотрим на выполнение задачи
Первый уровень — результат сценария. Смог ли участник достичь поставленной цели самостоятельно?
При этом бинарного деления «выполнил / не выполнил» часто недостаточно. Представим двух участников. Первый сразу нашел нужный раздел и завершил задачу. Второй открыл четыре раздела, несколько раз вернулся назад и только после этого пришел к тому же результату. Формально оба успешно справились, но качество взаимодействия было разным.
Поэтому полезно отдельно отмечать случаи, когда задача выполнена уверенно, выполнена после заметных затруднений или не выполнена вовсе.
Дальше я смотрю не только на количество таких случаев, но и на место возникновения проблемы. Если несколько участников независимо друг от друга останавливаются на одном экране или выбирают один и тот же неправильный раздел, это значительно сильнее указывает на системную проблему, чем единичная ошибка.
Ищем паттерны, а не самые яркие комментарии
Один эмоциональный отзыв легко запоминается. Например: «Я вообще не понимаю, зачем здесь это меню». Такая фраза может показаться достаточным основанием для изменения навигации.
Но сначала стоит проверить поведение остальных участников. Возможно, этот респондент действительно столкнулся с проблемой, а остальные без затруднений выполнили задачу. Или, наоборот, несколько человек долго искали нужную функцию, но только один смог четко сформулировать причину.
Поэтому я группирую наблюдения по типам проблем: навигация, терминология, заметность элементов, последовательность шагов, содержание экрана, ожидание результата. После этого становится проще увидеть повторяющиеся сценарии.
Особенно полезны совпадения между поведением и комментариями. Если несколько участников сначала ищут настройку в профиле, а после задания говорят, что ожидали найти ее именно там, мы получаем более содержательный вывод, чем просто «пользователи не нашли настройку».
Разбираемся в причине ошибки
Допустим, четыре участника из восьми не смогли выполнить одно действие. Само по себе это еще не говорит, что именно нужно изменить.
Причины могут быть разными:
Каждая причина предполагает разное решение. В первом случае можно исследовать визуальную иерархию, во втором — терминологию, в третьем — информационную архитектуру. Поэтому вывод «нужно сделать кнопку заметнее» нельзя делать только потому, что по ней мало нажимали.
Я стараюсь формулировать находку сначала как описание проблемы, не предлагая решение. Например: «Три участника искали изменение адреса доставки в настройках профиля и не ожидали увидеть эту функцию внутри карточки заказа».
Такая запись сохраняет исследовательский факт. Уже после этого команда может обсуждать варианты интерфейсного решения.
Сопоставляем количественные и качественные данные
Если после каждого сценария участники отвечали на одинаковые вопросы, можно сравнить успешность выполнения, оценки сложности и комментарии.
Например, сценарий получил относительно хорошие оценки по шкале простоты, но записи тестов показывают, что многие пользователи делали лишние переходы. Это не обязательно противоречие. Человек мог в итоге решить задачу и оценить ее как несложную, хотя интерфейс направлял его не самым очевидным путем.
И обратная ситуация: пользователь выполнил сценарий быстро, но поставил низкую оценку удобству. Тогда стоит посмотреть его комментарий — возможно, результат был найден случайно или участник не был уверен, что действие действительно завершено.
Если ответы собирались через Тестограф, результаты опроса можно использовать как структурированный слой анализа: сравнивать распределения ответов и изучать открытые комментарии. Но цифры я все равно рекомендую интерпретировать вместе с контекстом прохождения прототипа.
Определяем приоритет проблем
Не все найденные недостатки нужно исправлять одновременно. Я оцениваю проблему как минимум по повторяемости и влиянию на выполнение целевого сценария.
Если пользователь немного сомневается в формулировке второстепенной подсказки, но продолжает работу без ошибки, такая находка обычно будет менее приоритетной. Если же несколько участников не могут завершить основное действие, проблема требует внимания до передачи интерфейса в разработку.
Особенно важны ситуации, когда ошибка приводит пользователя к неправильному результату, но он этого не замечает. Такой сценарий может быть серьезнее очевидного тупика: человек уверен, что успешно выполнил действие, хотя фактически получил не тот результат.
В итоге хороший отчет по UX-тестированию — это не перечень всех реплик респондентов. Он должен показывать связь: задача → наблюдаемое поведение → повторяющаяся проблема → возможная причина → приоритет.
И только после этого стоит переходить к изменениям прототипа. Причем исследование не заканчивается после первой серии исправлений: наиболее важные решения желательно снова проверить на пользователях, чтобы убедиться, что изменение действительно устранило проблему, а не просто переместило ее на следующий экран.
Удаленное тестирование Figma-прототипа имеет смысл не само по себе. Его результатом должен стать следующий шаг: оставить решение без изменений, доработать его, проверить альтернативный вариант или пересмотреть сам пользовательский сценарий.
В проектах я стараюсь разделять исследовательскую находку и дизайнерское решение. Если участники не понимают название раздела, результат исследования — именно эта проблема, а не рекомендация «переименовать раздел в X». Новое название остается гипотезой, которую команда формирует на основании полученных данных.
Такой подход особенно важен при нескольких итерациях. Он позволяет видеть, какую проблему мы пытались решить каждым изменением и действительно ли следующая версия прототипа показала лучший результат.
Не исправляйте все замечания подряд
После тестов может накопиться несколько десятков наблюдений. Часть относится к критическим препятствиям, часть — к небольшим затруднениям, а некоторые комментарии вообще отражают индивидуальные предпочтения участников.
Я бы в первую очередь работал с проблемами, которые мешают выполнить основной сценарий, приводят к неправильному результату или повторяются у нескольких релевантных участников.
Например, если пользователи регулярно не находят возможность изменить способ доставки, это влияет на саму выполнимость задачи. А комментарий одного участника о том, что ему больше нравятся скругленные кнопки, в рамках такого исследования едва ли должен получить сопоставимый приоритет.
Приоритизация помогает не превращать UX-тест в голосование по деталям дизайна.
Меняем прототип и проверяем гипотезу повторно
После внесения изменений возникает еще одна распространенная ошибка: считать найденную проблему закрытой.
Предположим, участники не замечали функцию экспорта. Команда перенесла ее на более заметное место. Кажется, что проблема решена. Но в следующем тесте может выясниться, что теперь пользователи видят функцию, однако не понимают название кнопки. Или находят ее быстрее, но ожидают другой результат после нажатия.
Поэтому значимые изменения стоит тестировать повторно.
Рабочий цикл получается достаточно простым:
гипотеза → прототип → задание → тестирование → анализ → изменение → повторный тест.
При этом следующая итерация не обязательно должна быть такой же большой, как первая. Если команда изменила один конкретный участок сценария, можно сосредоточить исследование именно на нем.
Сохраняйте историю исследовательских решений
При регулярном тестировании прототипов полезно вести журнал находок. Для каждой значимой проблемы достаточно сохранить сценарий, наблюдение, затронутый сегмент пользователей, принятое решение и результат повторной проверки.
Это помогает через несколько месяцев ответить на вопрос, почему определенный элемент интерфейса устроен именно так. Без такой истории команда нередко возвращается к уже проверенным вариантам или повторяет старые исследования.
Структурированные ответы из Тестографа также можно использовать для сопоставления последовательных волн исследования. Если формулировки заданий и шкалы остаются сопоставимыми, становится проще увидеть, как изменилось прохождение сценария после новой версии прототипа.
Но сравнивать итерации нужно аккуратно. Если одновременно изменились прототип, задание и профиль участников, нельзя уверенно связывать разницу результатов только с новым дизайном.
Когда прототип можно передавать дальше
UX-тестирование не должно продолжаться до тех пор, пока каждый участник не пройдет сценарий идеально. У реальных пользователей все равно будут разные стратегии, ожидания и ошибки.
Практический критерий завершения я связываю с первоначальной целью исследования. Если критические препятствия устранены, ключевые сценарии понятны целевой аудитории, а оставшиеся замечания не мешают выполнению основных задач, команда может принять решение о переходе к следующему этапу.
И здесь особенно полезно вернуться к вопросу, который мы сформулировали перед первым тестом: что именно мы хотели узнать?
Если исследование начиналось с гипотезы «пользователь сможет самостоятельно изменить тариф», в финале нам нужно не общее впечатление о новом интерфейсе, а данные о том, насколько этот сценарий оказался понятным, где возникали затруднения и удалось ли их устранить в следующей версии.
Удаленное тестирование Figma-прототипов хорошо работает именно как итерационный инструмент. Оно позволяет проверить решение до дорогостоящей разработки, увидеть интерфейс глазами человека, который не участвовал в его создании, и заменить внутренние предположения команды наблюдаемыми данными.
При этом ни Figma, ни платформа для опросов сами по себе не обеспечивают качественное исследование. Результат зависит от того, насколько точно сформулирована гипотеза, кого пригласили на тест, какое задание получил участник и как команда интерпретировала его действия.
Поэтому я рассматриваю тестирование прототипа не как финальную проверку дизайна, а как часть процесса принятия продуктовых решений. Хороший тест не просто показывает, что пользователи делают в текущем интерфейсе. Он дает команде достаточно информации, чтобы понять, что именно стоит изменить в следующей версии и зачем.