Дизайнер показывает прототип. PM спрашивает: «Ну как? Понятно?»
Респондент кивает: «Да, нормально».
Команда выдыхает. Значит, можно отдавать в разработку.
Через неделю выясняется, что люди:
- не понимают, что будет после клика;
- боятся нажимать на главный CTA;
- путают два похожих варианта;
- не доверяют шагу с оплатой, доступом или правами команды.
И это не потому, что люди “плохо смотрели”.
Это потому, что тест начался с неправильного вопроса.
В этом разборе — практичный набор вопросов для тестирования прототипа: как формулировать задания без подсказок, что спрашивать до/во время/после действия и как фиксировать ответы так, чтобы они показывали UX‑риски, а не превращались в список вкусовщины.
Если вам нужна рамка шире, пригодятся соседние разборы UXDog: как подготовить Figma‑прототип к юзабилити‑тестированию, как проверить интерфейс до разработки, и кейсы про текст кнопки и текст в интерфейсе.
Коротко: какие вопросы нужны для тестирования прототипа
Если нужен быстрый ответ, вопросы для тестирования прототипа должны проверять не мнение о дизайне, а разрыв между ожиданием человека и тем, что показывает интерфейс.
Рабочая схема такая:
- сначала дайте задачу без названия кнопки;
- до клика спросите, что человек ожидает увидеть дальше;
- во время сценария смотрите, где он замирает или ищет другой путь;
- после действия спросите, что было непонятно и где он боялся ошибиться;
- фиксируйте не цитаты ради цитат, а момент, ожидание и цену ошибки.
Эти же вопросы подходят не только для кликабельного макета. Если у вас один экран, лендинг или форма, используйте их как вопросы для тестирования интерфейса: пусть человек объяснит, что он понял, чего ждёт и где не уверен.
Что на самом деле проверяет тестирование прототипа
Юзабилити‑тест прототипа — это не “оцените дизайн”.
Мы проверяем другое:
- понимает ли человек цель шага;
- знает ли, какой следующий шаг главный;
- понимает ли, что произойдёт после клика;
- доверяет ли действию (и почему);
- видит ли разницу между вариантами;
- не спотыкается ли о слова команды (“аккаунт”, “организация”, “доступ”).
Если тест заканчивается фразой “в целом нормально”, он не сделал работу.
Правило №1: задание — это цель, а не кнопка
Плохое задание говорит человеку, куда кликнуть:
“Нажмите кнопку «Подключить» и оплатите тариф.”
Хорошее задание говорит человеку, чего он хочет добиться:
“Вы закончили пробный период и хотите подключить тариф для команды. Дойдите до момента, где вы уверены, что понимаете условия и следующий шаг.”
Почему это важно: когда вы называете кнопку, человек перестаёт искать смысл. Он просто исполняет инструкцию. А вы теряете возможность увидеть, где прототип сам не объясняет следующий шаг.
Мини‑чеклист хорошего задания:
- короткий контекст (кто вы и зачем здесь);
- цель (что хотите сделать);
- ограничение (что не трогаем);
- критерий успеха (в какой момент “готово”).
Мини‑пример (один экран, две формулировки):
- Плохо: “Вам тут всё понятно?”
Человек почти всегда отвечает “да” — и вы ничего не узнаёте.
- Лучше: “Что вы ожидаете увидеть после клика?”
Ответ сразу покажет разрыв ожиданий: человек ждёт одно, прототип обещает другое.
Правило №2: вопросы задаём по таймингу
Есть три окна, где вопросы работают по‑разному.
1. До действия — ловим ожидание. 2. Во время — ловим поиск и “замирание”. 3. После — ловим причину и цену ошибки.
12 вопросов, которые вытаскивают UX‑риски
Ниже — набор, который можно держать как шпаргалку. Не нужно задавать все 12 в каждом тесте. Выбирайте 4–6 по ситуации.
A. Ожидание и следующий шаг
- Что вы ожидаете увидеть после клика?
- Как вы поймёте, что сделали всё правильно?
- Что здесь самое главное действие?
- Что вы сделаете, если это не сработает?
B. Доверие и цена ошибки
- Что в этом шаге выглядит рискованным?
- В какой момент вы бы остановились и “пошли думать”?
- Что должно быть написано/показано, чтобы вы доверились?
- Можно ли отменить действие? Где вы ищете путь назад?
C. Язык и смысл
- Какие слова здесь непонятны или двусмысленны?
- Как бы вы назвали этот шаг своими словами?
- Что вы думаете означает эта кнопка/подсказка?
- Что вас может смутить в этой формулировке?
Готовый мини‑шаблон скрипта
Если времени мало, не собирайте большой исследовательский гайд. Возьмите один сценарий и пройдите по короткому шаблону.
Контекст: “Вы отвечаете за командный аккаунт и хотите подключить тариф, чтобы коллеги могли продолжить работу”.
Задание: “Дойдите до момента, где вы понимаете условия и готовы принять решение”.
До действия: “Что вы ожидаете увидеть после следующего клика?”
Во время: “Что вы сейчас ищете?” / “Где вы не уверены?”
После: “Что было рискованным?” / “Что должно быть написано, чтобы вы доверились?”
Фиксация: момент → ожидание → что увидел → цена ошибки.
Такой скрипт не заменяет полноценное исследование. Но он быстро показывает, где прототип не объясняет себя сам.
Как фиксировать ответы: сигнал vs шум
Цель теста — не собрать “все улучшения мира”.
Цель — найти места, где человек:
- задаёт один и тот же вопрос разными словами;
- замирает и ищет “другой” клик;
- ожидает последствия, которых нет;
- боится ошибиться или потерять контроль.
Это сигнал.
А вот что часто шум:
- “мне не нравится фиолетовый” (если это не про доступность/контраст);
- “я бы сделал по‑другому” без привязки к цели;
- “давайте добавим ещё 10 полей” как личное желание.
Правило фиксации, которое работает почти всегда:
Момент → Ожидание → Что увидел → Цена ошибки.
Где помогают AI‑респонденты и где нужна осторожность
AI‑респонденты полезны как быстрый ранний сигнал.
Например, чтобы:
- быстро увидеть, что задание слишком “ведёт за руку”;
- поймать двусмысленные слова;
- проверить, где человек ожидает другой следующий шаг.
Но есть важное ограничение: ответы AI нельзя трактовать как поведение реальных людей.
Если цена ошибки высокая (деньги, доверие, доступы, безопасность), используйте AI как способ подготовиться к тесту на людях, а не как замену.
Мини‑скрипт: 30 минут на один сценарий
Если нужно быстро проверить прототип до разработки, держите ритм:
- 5 минут — контекст, цель, критерий успеха.
- 15 минут — одно задание + вопросы по таймингу.
- 10 минут — 3 риска, 3 правки, 1 повторная проверка.
Главное: не превращать тест в лекцию.
Вы проверяете не “как красиво”. Вы проверяете “где человек не уверен”.
Когда нужно идти к реальным пользователям
Быстрый аудит и AI‑респонденты заканчиваются там, где начинается высокая ставка.
Рабочее правило:
- низкий риск — чеклист и быстрая правка;
- средний риск — экспертный взгляд + быстрый прогон;
- высокий риск — люди, данные и (если возможно) эксперимент.
Как проверять до разработки
Если вы делаете быстрый UX‑аудит сценария до разработки, важно одно: чётко сформулировать задание и вопросы.
Это ровно тот тип предварительной проверки, вокруг которого строится UXDog: быстро найти очевидные разрывы в сценарии, тексте или прототипе, а затем решить, где нужна настоящая пользовательская проверка.
Вывод
Хорошие вопросы юзабилити‑тестирования не спрашивают: “вам нравится?”
Они ставят человека в ситуацию, где прототип должен объяснить себя сам.
Если человек понимает цель, следующий шаг и цену ошибки — сценарий можно докручивать дальше. Если он угадывает, боится кликнуть или повторяет один и тот же вопрос, у команды есть конкретная правка до разработки.
Не “всё норм”.
А “вот здесь человек не уверен”.