Usability-тест скрипт с AI: пошаговое руководство

Что такое AI-сгенерированный скрипт usability-теста?

AI-сгенерированный скрипт usability-теста — это структурированный гайд для сессии, созданный LLM на основе специфики продукта: гипотез, ключевых флоу и описания аудитории, включающий вступление, предтестовый опрос, сценарные задачи, пост-задачные вопросы, завершающий опрос и чеклист модератора, что сокращает ручную подготовку с нескольких часов до 30–40 минут.

TL;DR

  • -85% юзабилити-проблем обнаруживаются на первых пяти участниках (данные Nielsen Norman Group) — узкое место не в количестве сессий, а в качестве скрипта, которое AI может систематически повысить.
  • -Хорошие задачи описывают цели пользователя, а не действия в UI, не содержат подсказок, идут от простого к сложному и включают измеримый критерий успеха для модератора.
  • -Single Ease Question (шкала 1–7, среднее по индустрии 5.5 по данным MeasuringU) после каждой задачи даёт количественный якорь для качественных наблюдений.
  • -Постсессионный анализ включает три AI-шага: разметка транскрипции по задачам, матрица проблем по серьёзности и частоте, одностраничный executive summary с топ-5 проблемами.
  • -Точки интеграции, реально влияющие на решения: тестирование прототипа до разработки, баги в бэклог во время спринта, валидация решений на живом продукте после релиза.

85% юзабилити-проблем обнаруживаются уже на первых пяти участниках — классический результат Nielsen Norman Group. Узкое место — не проведение теста, а подготовка скрипта. Средний PM тратит на это часы. AI сокращает до 30–40 минут, и качество часто выше: модель покрывает сценарии систематически, а не по памяти.

Статья о том, как генерировать полный скрипт usability-теста: от структуры сессии до анализа результатов. С промптами, которые можно использовать сразу.

Структура usability-тест скрипта

Скрипт юзабилити-тестирования состоит из шести блоков. Каждый блок решает конкретную задачу. Пропуск любого блока снижает качество данных.

БлокДлительностьЦель
Вступление и согласие3-5 минСнять напряжение, получить согласие на запись
Предтестовый опрос3-5 минПонять контекст и опыт участника
Задачи (core)25-35 минНаблюдать поведение при выполнении задач
Пост-задачные вопросы5-7 минСобрать впечатления после каждой задачи
Общий опрос5-7 минОценить целостное восприятие продукта
Завершение2-3 минПоблагодарить, узнать что упущено

Общая длительность сессии: 45-60 минут. Больше часа участник устаёт, данные теряют достоверность.

Вступление: промпт для генерации intro-скрипта

Вступление задаёт тон всей сессии. Участник должен понять, что тестируется продукт, а не он сам; что здесь нет правильных и неправильных ответов; и что думать вслух — это полезно, а не странно.

Ты UX-исследователь. Напиши вступительный скрипт для модерируемого
usability-теста.

Продукт: [название и краткое описание]
Формат: [удалённый/очный]
Запись: [да/нет]

Скрипт должен включать:
1. Представление модератора (имя, роль — без должности)
2. Объяснение цели: тестируем продукт, не участника
3. Просьбу думать вслух
4. Инструкцию по записи и согласие
5. Напоминание: можно остановиться в любой момент
6. Вопрос "Есть вопросы перед началом?"

Тон: спокойный, дружелюбный, не корпоративный.
Длина: 150-200 слов.

Ключевой момент: фраза “мы тестируем продукт, не вас” снижает тревожность участника. Без неё люди стараются угодить модератору, а не решать задачи естественно. Это искажает данные.

Предтестовый опрос: контекст участника

Прежде чем давать задачи, нужно понять, кто перед вами. Опыт участника определяет, как интерпретировать его поведение. Новичок, который застрял на навигации, и эксперт, который застрял на навигации, сигнализируют о разных проблемах.

Сгенерируй 5-7 предтестовых вопросов для usability-теста.

Продукт: [название]
Категория продукта: [например, таск-менеджер, travel-приложение, CRM]
Целевая аудитория: [описание]

Вопросы должны выявить:
- Опыт использования аналогичных продуктов
- Частоту решения задачи, которую покрывает продукт
- Текущий способ решения этой задачи (без нашего продукта)
- Уровень технической грамотности (косвенно, без прямого вопроса)

Формат: открытые вопросы. Никаких да/нет.
Не упоминай конкурентов по имени.

Результат этого блока: профиль участника, который используется при анализе. “Участник 3 пользуется аналогичными продуктами ежедневно, но не нашёл функцию X” значит больше, чем просто “участник 3 не нашёл функцию X”.

Генерация задач: ядро usability-теста

Задачи определяют, что именно вы тестируете. Плохая задача приводит к бесполезным данным. Хорошая задача отвечает трём критериям: реалистичная, конкретная, без подсказок.

Пример плохой задачи: “Найдите кнопку фильтров и отфильтруйте результаты по цене.” Здесь содержится подсказка. Участник знает, что искать кнопку. В реальности он может не знать, что фильтры существуют.

Пример хорошей задачи: “Вы ищете отель в Бангкоке на 3 ночи. Бюджет — не больше $80 за ночь. Покажите мне, как вы найдёте подходящий вариант.”

Сгенерируй набор из 5-8 задач для usability-теста.

Продукт: [название и описание]
Ключевые флоу для тестирования:
1. [флоу 1, например: онбординг нового пользователя]
2. [флоу 2, например: создание первого проекта]
3. [флоу 3, например: приглашение коллеги]
4. [флоу 4, например: поиск и фильтрация]

Для каждой задачи:
- Сценарий: реалистичная ситуация (2-3 предложения)
- Задача: что участник должен сделать (без подсказок по UI)
- Критерий успеха: как модератор определит, что задача выполнена
- Максимальное время: сколько минут отвести

Правила:
- Задачи идут от простых к сложным
- Первая задача — разминочная (простая, для снятия напряжения)
- Формулировки описывают цель пользователя, а не действия в интерфейсе
- Никаких терминов из UI продукта (не "нажмите hamburger menu",
  а "найдите настройки")
- Каждая задача тестирует один конкретный флоу

Калибровка сложности задач

После генерации задач стоит проверить баланс сложности. AI может сместить все задачи в одну сторону.

Оцени набор задач для usability-теста по критериям:

[вставить сгенерированные задачи]

Критерии оценки:
1. Есть ли разминочная задача (успех >90% участников)?
2. Есть ли задача средней сложности (успех 50-80%)?
3. Есть ли сложная задача (успех <50%)?
4. Содержат ли формулировки подсказки (термины из UI)?
5. Покрывают ли задачи разные части продукта?
6. Реалистичен ли порядок задач для нового пользователя?

Для каждой проблемы: опиши что не так и предложи исправленную
формулировку.

Вопросы think-aloud и промежуточные пробы

Think-aloud протокол генерирует основной массив качественных данных. Участник озвучивает мысли в процессе выполнения задачи. Модератор не вмешивается, но иногда нужно мягко вернуть участника к озвучиванию мыслей.

Несколько фраз для модератора стоит заучить наизусть:

  1. При молчании участника: “Что вы сейчас ищете?” (не “Что вы делаете?” — это давит)
  2. При затруднении: “Что вы ожидали здесь увидеть?” (фиксирует ментальную модель)
  3. При успехе: “Это было так, как вы ожидали?” (ловит скрытое недовольство)

После каждой задачи полезно задать 2-3 вопроса. Генерировать их стоит под конкретные задачи.

Для каждой задачи usability-теста сгенерируй 2-3 пост-задачных вопроса.

Задачи:
[вставить список задач]

Типы вопросов:
- Субъективная оценка сложности: "Насколько это было легко/сложно?"
- Соответствие ожиданиям: "Это работало так, как вы ожидали?"
- Альтернативы: "Как бы вы попробовали решить это по-другому?"
- Уверенность: "Вы уверены, что задача выполнена?"

Правила:
- Открытые вопросы (не да/нет)
- Нейтральная формулировка (не "Вам понравилось?")
- Не больше 3 вопросов на задачу (участник устаёт)

Шкала Single Ease Question (SEQ)

После каждой задачи стоит использовать SEQ: “Насколько легко было выполнить эту задачу?” Шкала от 1 до 7. Средний показатель по индустрии: 5.5 (данные MeasuringU). Всё, что ниже 5.5, сигнализирует о проблеме.

SEQ даёт количественный якорь для качественных наблюдений. “Участник поставил 3/7 и сказал, что не нашёл фильтры” весомее, чем просто “участник не нашёл фильтры”.

Завершающий опрос: целостная картина

После всех задач участник переключается с выполнения на рефлексию. Здесь собираются данные о целостном восприятии продукта.

Сгенерируй 6-8 вопросов для завершающего опроса usability-теста.

Продукт: [название]
Что тестировали: [список флоу]

Вопросы должны покрыть:
- Первое впечатление от продукта
- Самый сложный момент во время тестирования
- Самый понятный/приятный момент
- Что бы участник изменил в первую очередь
- Вероятность рекомендации (NPS или аналог)
- Сравнение с текущим способом решения задачи

Формат: открытые вопросы.
Тон: разговорный, не академический.
Последний вопрос: "Есть что-то, о чём я не спросил, но вы хотели бы
сказать?"

Последний вопрос (“Есть что-то, о чём я не спросил?”) регулярно вытаскивает инсайты, которые не покрыты скриптом. Пропускать его нельзя.

Промпт для полного скрипта: всё в одном

Когда структура понятна, можно сгенерировать весь скрипт одним запросом. Это работает лучше для опытных исследователей, которые знают, что редактировать.

Ты старший UX-исследователь с 10+ годами опыта модерируемых
usability-тестов.

Создай полный скрипт usability-теста для:
Продукт: [название и описание, 2-3 предложения]
Стадия продукта: [прототип / MVP / production]
Целевая аудитория: [описание]
Ключевые гипотезы для проверки:
1. [гипотеза 1]
2. [гипотеза 2]
3. [гипотеза 3]

Формат тестирования: [удалённое через Zoom / очное]
Длительность сессии: [45/60 минут]

Структура скрипта:
1. Вступление (дословный текст для модератора)
2. Предтестовый опрос (5-7 открытых вопросов)
3. 5-7 задач (сценарий + формулировка + критерий успеха + время)
4. Пост-задачные вопросы (2-3 после каждой задачи + SEQ)
5. Завершающий опрос (6-8 вопросов)
6. Завершение (дословный текст)

Дополнительно:
- Таймлайн сессии (поминутный)
- Чеклист для модератора (подготовка до сессии)
- Лист наблюдений (таблица для записи во время теста)

Правила:
- Задачи описывают цели, не действия в UI
- Вопросы открытые, нейтральные
- Первая задача разминочная
- Порядок: от простого к сложному
- Нет терминов из интерфейса продукта в формулировках задач

Результат: документ на 3-5 страниц, готовый к использованию после 15-20 минут редактирования. Редактирование обязательно. AI не знает специфики вашего продукта так глубоко, как вы.

Анализ результатов usability-теста с AI

Собранные данные требуют структурированного анализа. Один тест генерирует 45-60 минут записи, десятки наблюдений и субъективных оценок. AI ускоряет переход от сырых данных к actionable-выводам.

Шаг 1: транскрипция и разметка

Транскрипция сессии (Otter.ai, Fireflies, встроенные инструменты Zoom) даёт текст. Текст нужно разметить по задачам.

Размети транскрипцию usability-теста по блокам.

Транскрипция:
[вставить текст]

Задачи теста:
[список задач]

Для каждого блока определи:
- Какая задача выполнялась
- Таймкод начала и конца
- Статус: выполнена / выполнена с трудом / не выполнена
- Ключевые цитаты участника (дословно)
- Моменты затруднения (что именно вызвало проблему)
- Моменты успеха (что сработало хорошо)

Шаг 2: матрица проблем

После анализа 3-5 сессий формируется матрица проблем. Каждая проблема получает серьёзность и частоту.

На основе данных usability-тестов создай матрицу проблем.

Данные участников:
[сводка по каждому участнику: задачи, статусы, проблемы, SEQ-оценки]

Для каждой проблемы определи:
- Описание проблемы (1-2 предложения)
- Серьёзность: критическая / серьёзная / незначительная
  (критическая = блокирует выполнение задачи,
   серьёзная = замедляет, но не блокирует,
   незначительная = раздражает)
- Частота: у скольких участников из скольких
- Задачи, где проблема проявилась
- Рекомендация по исправлению

Отсортируй: сначала по серьёзности, затем по частоте.
Формат: таблица.

Матрица проблем отвечает на главный вопрос: что исправлять первым. Критическая проблема у 4 из 5 участников важнее незначительной проблемы у всех 5.

Шаг 3: отчёт для стейкхолдеров

Результаты тестирования нужно донести до команды. Подробные UX-отчёты на 20 страниц не читают. Работает формат executive summary + топ-5 проблем + конкретные рекомендации.

Напиши executive summary по результатам usability-тестирования.

Продукт: [название]
Количество участников: [N]
Тестируемые флоу: [список]
Ключевые метрики:
- Средний Task Success Rate: [%]
- Средний SEQ: [число]
- Среднее время на задачу: [мин]

Матрица проблем:
[вставить матрицу]

Структура отчёта:
1. Однострочный вывод (продукт готов/не готов к релизу)
2. Топ-5 проблем с рекомендациями (1-2 предложения на каждую)
3. Что работает хорошо (2-3 пункта)
4. Рекомендуемые следующие шаги (приоритизированный список)

Длина: максимум 1 страница.
Тон: фактический, без оценочных суждений.
Используй цифры, а не прилагательные.

Типичные ошибки при составлении скриптов

Даже с AI-генерацией скрипты содержат паттерны ошибок. Проверяйте каждый скрипт по этому списку.

Подсказки в формулировках задач. “Используйте панель поиска для нахождения товара” подсказывает, что есть панель поиска. Правильно: “Найдите беспроводные наушники до 5000 рублей.”

Слишком абстрактные задачи. “Изучите приложение” не тестирует ничего конкретного. Нет критерия успеха, нет наблюдаемого поведения.

Наводящие вопросы. “Вам понравился новый дизайн?” содержит предположение, что дизайн новый и должен понравиться. Правильно: “Опишите ваше впечатление от интерфейса.”

Избыток задач. Больше 7-8 задач за час утомляет участника. Последние задачи получают меньше внимания, данные искажаются.

Отсутствие пилота. Первый прогон скрипта всегда выявляет проблемы с формулировками. Проведите пилотный тест на коллеге перед реальными участниками.

Чеклист модератора

Подготовка к сессии определяет качество данных не меньше, чем скрипт.

До сессии:

  • Скрипт распечатан или открыт на втором экране
  • Прототип/продукт загружен, аккаунт создан
  • Запись настроена и протестирована
  • Лист наблюдений готов (задача, время, статус, заметки)
  • Резервный вариант связи (если Zoom упадёт)
  • Вознаграждение для участника подготовлено

Во время сессии:

  • Следовать скрипту, но адаптировать порядок вопросов при необходимости
  • Не помогать участнику (даже если хочется)
  • Фиксировать время начала и окончания каждой задачи
  • Записывать дословные цитаты, а не интерпретации
  • Делать паузу 3-5 секунд после ответа участника (часто следует дополнение)

После сессии:

  • Записать впечатления в течение 15 минут (пока свежие)
  • Отметить самые яркие моменты
  • Обновить лист наблюдений

Интеграция с продуктовым процессом

Usability-тест приносит ценность, когда результаты влияют на решения. Без интеграции в процесс это дорогое упражнение.

Где тестирование реально встраивается в процесс:

  1. До разработки. Тестирование прототипов в Figma. Стоимость исправления на этом этапе минимальна. Используйте контекстное проектирование промптов под конкретный прототип.

  2. Во время спринта. Тестирование MVP или staging-версии. Результаты попадают в бэклог как баги с приоритетом.

  3. После релиза. Тестирование live-продукта с реальными данными. Валидация решений, принятых на предыдущих этапах.

Оптимальная частота: один раунд тестирования (5 участников) каждые 2-4 недели. Это даёт постоянный поток данных без перегрузки команды.

Метрики для отслеживания

Количественные метрики из usability-тестов дают базу для сравнения между итерациями.

МетрикаЧто измеряетБенчмарк
Task Success Rate% участников, выполнивших задачу>78% (средний по индустрии)
Time on TaskВремя выполнения задачиЗависит от задачи
SEQ (Single Ease Question)Субъективная лёгкость>5.5 из 7
Error RateКоличество ошибок на задачу<0.7 на задачу
SUS (System Usability Scale)Общая удобность продукта>68 из 100

Бенчмарки Task Success Rate (78%) и SUS (68) — данные Jeff Sauro / MeasuringU по сотням исследований; используйте их как ориентир, а не универсальный порог для конкретного продукта.

Сравнивайте метрики между раундами тестирования. “Task Success Rate на флоу регистрации вырос с 60% до 90% после редизайна формы” говорит больше, чем “мы улучшили регистрацию”.

Итого

AI генерирует скрипт usability-теста за 30-40 минут вместо нескольких часов ручной работы. Качество скрипта зависит от качества промпта: конкретный продукт, конкретные гипотезы, конкретные флоу.

Порядок действий:

  1. Определить 3-5 ключевых флоу для тестирования
  2. Сгенерировать задачи промптом (без подсказок, от простого к сложному)
  3. Проверить скрипт по чеклисту ошибок
  4. Провести пилотный тест на коллеге
  5. Провести 5 сессий
  6. Проанализировать результаты через матрицу проблем
  7. Оформить executive summary для команды

Пять участников, один хороший скрипт, 45 минут на сессию. Этого достаточно, чтобы найти 85% проблем юзабилити в продукте.


Нужна помощь с usability-тестированием? Я помогаю стартапам внедрять AI-решения и строить продукты — belov.works.

Часто задаваемые вопросы

Как реагировать на молчание участника во время think-aloud задачи, не подсказывая ответ?
Безопасный зонд — «Что вы думаете прямо сейчас?» — возобновляет вербализацию без намёка на нужное действие. Избегайте «Вы ищете настройки?» или любых формулировок, называющих элементы интерфейса — это вводит именно ту подсказку, которую протокол think-aloud призван исключить. Если молчание продолжается после двух зондов, зафиксируйте таймкод и дайте участнику продолжать — молчание само по себе является данными. После задачи можно спросить: «Вы немного замолчали на этом шаге — что происходило в этот момент?» — это восстанавливает наблюдение, не загрязняя поведение во время задачи.
Можно ли использовать AI для генерации скрипта для продукта, который модель никогда не видела?
AI генерирует структурно корректные скрипты из описаний, но сценарии задач будут обобщёнными без конкретики: реальной пользовательской цели, конкретного флоу, проблемной области. Чем конкретнее входные данные — «мы думаем, пользователи не могут найти пункт навигации для выставления счетов» — тем точнее результат. Скрипты из расплывчатых запросов типа «протестируй онбординг» охватывают широту, но теряют глубину. Воспринимайте AI-сгенерированный скрипт как черновик, требующий 15–20 минут редактирования человеком, знающим продукт.
Что делать, если участник выполняет все задачи быстрее запланированного времени?
Участник, завершающий все задачи за 25 минут из 45 запланированных, даёт другие данные: продукт может быть более понятным, чем предполагалось, или задачи оказались слишком лёгкими. Не заполняйте оставшееся время вспомогательными вопросами. Используйте его для исследования смежных сценариев: «Что вы сделаете дальше?» — или задайте вопросы о функциях, не вошедших в основной набор задач. Если несколько участников завершают раньше срока, это сигнал добавить более сложную задачу в следующем раунде.