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