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

> Как использовать AI для генерации скриптов юзабилити-тестирования: структура сессии, промпты для задач и вопросов, анализ результатов. Шаблоны и примеры.
> Author: Roman Belov · Published: 2026-07-14 · Source: https://futurecraft.pro/ru/blog/usability-test-script-ai/

85% юзабилити-проблем обнаруживаются уже на первых пяти участниках — классический результат [Nielsen Norman Group](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/). Узкое место — не проведение теста, а подготовка скрипта. Средний 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](https://measuringu.com/evolution-of-seq/)). Всё, что ниже 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](/ru/blog/figma-to-prototype/). Стоимость исправления на этом этапе минимальна. Используйте [контекстное проектирование](/ru/blog/context-engineering-guide/) промптов под конкретный прототип.

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%)](https://measuringu.com/task-completion/) и [SUS (68)](https://measuringu.com/sus/) — данные 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](https://belov.works).*