Какие знаешь сценарии?

Сценарии: Типы, анализ и применение

Определение

Сценарий в контексте Product Analyst — это подробный, пошаговый описание того, как пользователь взаимодействует с продуктом для достижения конкретной цели. Это отличается от юзкейса (просто цель) тем, что включает детали, ошибки, альтернативные пути и контекст.

Формула сценария:

Сценарий = Персона + Цель + Контекст + Пошаговые действия + Результат

Основные типы сценариев

1. Happy Path (Основной сценарий)

Определение: Идеальный путь без ошибок, когда всё работает как задумано.

Пример: Отправка сообщения в Telegram

Персона: Александр, 28 лет, маркетолог
Цель: Отправить срочное сообщение коллеге о встречи
Контекст: На работе, открыл Telegram на мобилке

Шаги:
1. Открыл приложение Telegram
2. Нашёл контакт "Мария" в чатах
3. Кликнул на чат
4. Нажал на поле ввода сообщения
5. Напечатал: "Встреча перенесена на 15:00"
6. Нажал отправить
7. Сообщение отправилось мгновенно
8. Видит "✓✓" (две галочки) — Мария прочитала
9. Мария ответила: "Ok, спасибо!"
10. Александр вышел из чата

Результат: ✓ Цель достигнута
Время: 20 секунд
Удовлетворённость: 5/5

Зачем нужен: Это base case — то, что должно работать идеально всегда.

2. Unhappy Path (Сценарий с ошибками)

Определение: Пользователь сталкивается с проблемами, но успешно их преодолевает.

Пример: Отправка сообщения без интернета

Персона: Александр, 28 лет
Цель: Отправить сообщение
Контекст: Едет в метро, интернет нестабильный

Шаги:
1. Открыл Telegram
2. Написал сообщение: "Встреча перенесена на 15:00"
3. Нажал отправить
4. Появилось сообщение об ошибке: "No internet"
5. Интернет вернулся (вышел из метро)
6. Сообщение автоматически переотправилось
7. Видит "✓✓" — успешно доставлено

Результат: ✓ Цель достигнута (но с задержкой)
Время: 3 минуты
Удовлетворённость: 3/5 (было страшновато)

Зачем нужен: Выявляет проблемы в error handling, умеет ли приложение восстанавливаться.

3. Edge Case (Граничный случай)

Определение: Редкое, экстремальное, или необычное использование.

Примеры:

Сценарий 1: Отправка очень большого сообщения

Персона: Иван, программист
Цель: Отправить код в чат (1000 строк)
Контекст: Спешит, на мобилке

Шаги:
1. Скопировал код из GitHub
2. Вставил в поле ввода Telegram
3. Сообщение заняло 5000+ символов
4. Нажал отправить
5. Что произойдёт?
   - ✗ Плохо: Приложение зависло на 5 секунд
   - ✓ Хорошо: Разбилось на 4 сообщения автоматически

Сценарий 2: Отправка сообщения с 100+ упоминаниями

Персона: HR, отправляет массовое сообщение
Цель: Отправить поздравление всем
Контекст: "@user1 @user2 @user3 ... @user100"

Шаги:
1. Напечатал 100 упоминаний
2. Нажал отправить
3. Что произойдёт?
   - ✗ Плохо: Всем придёт 100 нотификаций
   - ✓ Хорошо: Бэклог сообщений, потом отправляются волнами

Сценарий 3: Отправка сообщения в чат, который вышиб из памяти

Персона: Юзер
Цель: Отправить сообщение старому знакомому
Контекст: Открыл Telegram после 6 месяцев перерыва

Шаги:
1. Открыл Telegram
2. Ищет чат с "Петей"
3. Нашёл старый чат (6 месяцев назад)
4. Написал: "Привет, как дела?"
5. Нажал отправить
6. Что произойдёт?
   - ✗ Плохо: Сообщение ушло в void (петя удалил аккаунт)
   - ✓ Хорошо: Сообщение отправилось, но показано, что петя неактивен 6 месяцев

Зачем нужны: Выявляют баги в редких ситуациях, предотвращают catastrophic failures.

4. Failure Case (Отказ — цель НЕ достигнута)

Определение: Пользователь не может достичь цель из-за ошибки приложения или ограничения.

Пример 1: Отправка сообщения — бан

Персона: Спамер
Цель: Отправить спам всем контактам
Контекст: Telegram часто блокирует за спам

Шаги:
1. Написал сообщение: "Заработай 100k в день!"
2. Отправил 50 людям
3. После 30 сообщений получил ошибку: "Too many requests"
4. Попытался ещё раз — аккаунт заблокирован на 24 часа
5. Не может отправить ничего

Результат: ✗ Цель НЕ достигнута
Удовлетворённость: 1/5 (но это нормально — спам плохой)

Пример 2: Отправка сообщения — нет прав

Персона: Юзер
Цель: Отправить сообщение в приватный чат
Контекст: Юзер был удалён из чата

Шаги:
1. Попытался открыть чат с Антоном
2. Открылась история, но нет поля ввода
3. Сообщение: "You are not a member of this chat"
4. Нажимает кнопку "Add" — но это приватный чат, нужна приглашение
5. Написал Антону в другом чате: "Почему ты вышиб меня?"

Результат: ✗ Цель частично достигнута (связался с человеком, но не в том чате)

Зачем нужны: Помогают спланировать user experience для ошибок.

5. Alternative Path (Альтернативный путь)

Определение: Другой способ достичь одну и ту же цель.

Пример: Отправка сообщения в Telegram

Happy Path:

1. Открыть Telegram
2. Найти контакт
3. Написать сообщение
4. Отправить

Alternative Path 1 — через быстрый поиск:

1. Открыть Telegram
2. Нажать иконку поиска (лупу)
3. Напечатать имя контакта
4. Кликнуть на контакт в результатах
5. Написать сообщение
6. Отправить

Alternative Path 2 — через голос:

1. Открыть Telegram
2. Найти контакт
3. Нажать кнопку микрофона
4. Сказать в микрофон сообщение
5. Система распознаёт речь
6. Скорректировать текст (если нужно)
7. Отправить

Alternative Path 3 — через умный помощник (AI):

1. Сказать голосовой команде: "Telegram, отправь сообщение Маше"
2. Система откроет чат с Машей
3. Повторить сообщение или напечатать
4. Отправить

Alternative Path 4 — через шорткут:

1. Создать шорткат в iOS/Android: "Message Masha"
2. Активировать шорткат (нажать на иконку)
3. Система откроет Telegram и чат с Машей
4. Написать сообщение
5. Отправить

Зачем нужны: Показывают, что один юзкейс можно решить несколькими путями. Выявляют, какой путь самый эффективный.

6. Concurrent User Scenario (Сценарий с конкурирующими пользователями)

Определение: Два пользователя делают одно и то же одновременно, может быть конфликт.

Пример: Отправка сообщения + редактирование

Персона A: Маша (отправляет сообщение)
Персона B: Саша (редактирует ранее отправленное сообщение)
Контекст: Один чат, одновременные действия

Время: 14:00:00
Маша: Пишет "Привет"
Саша: Пишет "Привет" в своем сообщении

14:00:05
Маша: Нажимает отправить
Саша: Нажимает отправить (редакт)

Что произойдёт?
- Маше: "Сообщение отправлено"
- Саше: "Изменено"
- Петя (читатель): видит оба сообщения в нужном порядке
- База данных: всё синхронизировано

Результат: ✓ Обе операции успешны, конфликта нет

Сложный пример: Race condition

Персона A: Иван (отправляет сообщение)
Персона B: Ольга (удаляет чат)
Контекст: Одновременные действия

14:00:00.000 - Иван: Нажимает "отправить"
14:00:00.001 - Ольга: Нажимает "удалить чат"
14:00:00.002 - Сервер получает обе команды

Что произойдёт?
- ✗ Плохо: Иван видит "Message sent", но сообщение в БД не сохранилось
- ✓ Хорошо: Сервер сначала отправляет (с timestamp 14:00:00.000), потом удаляет (останется история)

Зачем нужны: Выявляют race conditions, проверяют consistency БД.

Как я использовал сценарии в работе

Задача 1: Дизайн процесса покупки Premium

Happy Path: Пользователь видит кнопку "Upgrade", платит, получает Premium.

Unhappy Paths:

• Сбой платежа → retry механизм
• Пользователь закрыл приложение при платеже → восстановление
• Карта отклонена → альтернативный метод платежа

Edge Cases:

• Пользователь купил Premium, потом удалил приложение и переустановил
• Пользователь купил на iPhone, потом переключился на Android
• Пользователь отменил подписку через App Store

Failure Cases:

• Пользователь не может добавить карту (поддерживаем только Visa/Mastercard)
• Пользователь из страны, где платежи запрещены

Результат: Спроектировали процесс с fallback'ами на каждом шаге.

Задача 2: Анализ багов при отправке видео

Сценарий: Пользователь отправляет видео 500MB

Этап 1: Выбор файла
- Happy: Выбрал видео, видит "Loading..."
- Unhappy: Файл слишком большой → ошибка, нужна компрессия
- Edge: Видео повреждено → ошибка при загрузке

Этап 2: Загрузка
- Happy: Загрузилось 100%
- Unhappy: Интернет отвалился → паузировалось
- Edge: Загружалось 99.9%, потом ошибка → нужен retry

Этап 3: Отправка
- Happy: Отправилось мгновенно
- Unhappy: Сервер переполнен → очередь
- Edge: Пользователь вышел из приложения → продолжает в фоне

Этап 4: Получение
- Happy: Получатель видит видео мгновенно
- Unhappy: Получатель в offline → видео в очереди
- Edge: Получатель удалил чат → видео потеряно

Вывод: Нужны улучшения на этапе 2 и 3.

Задача 3: Сценарии для новой фичи (Emoji reactions)

Happy Path:

1. Пользователь видит сообщение
2. Долгий тап на сообщение
3. Появляется меню с эмодзи
4. Выбирает 👍
5. Под сообщением появляется 👍 с числом (1)
6. Отправитель видит notification: "Петя добавил 👍"

Alternative Paths:

• Выбрать несколько эмодзи на одно сообщение (👍 + 😂 + ❤️)
• Удалить свою реакцию (тап ещё раз)
• Посмотреть кто реагировал (тап на эмодзи)

Edge Cases:

• Старое сообщение (1 месяц назад) → может ли добавить реакцию?
• Сообщение, которое удалили → реакции остаются или удаляются?
• Удалённый пользователь → его реакции видны?
• Пользователь без интернета → реакция сохраняется локально и синхронизируется?

Failure Cases:

• Блокировка пользователя → может ли реагировать?
• Приватный чат, пользователя вышибли → его реакции видны?

Как документировать сценарии

Формат 1: Текстовый (просто и понятно)

Название: Отправка сообщения в оффлайне

Персона: Александр, маркетолог
Цель: Отправить важное сообщение
Предусловие: Интернет отключён

Шаги:
1. Открыть Telegram
2. Найти чат с Машей
3. Написать: "Встреча в 15:00"
4. Нажать отправить

Ожидаемый результат:
- Сообщение помещено в очередь
- Показано "⏱ pending" (часы)
- Когда интернет вернулся:
  - Сообщение отправилось
  - Показано "✓✓" (две галочки)

Фактический результат:
- [После теста]
  ✓ Сообщение в очереди
  ✓ Показано "⏱ pending"
  ✓ После интернета отправилось
  ✓ Показано "✓✓"

Вывод: ✓ Работает как ожидалось

Формат 2: User Story с критериями

Scenario: Отправка сообщения в оффлайне
Given пользователь в чате с Машей
And интернет отключён
When пользователь пишет сообщение "Привет"
And нажимает отправить
Then сообщение помещается в очередь
And показывается значок "pending"
When интернет вернулся
Then сообщение отправляется
And показываются две галочки

Формат 3: Таблица сценариев

| Сценарий | Предусловие | Действие | Результат | Статус |
|----------|-------------|----------|-----------|--------|
| Happy | Интернет OK | Отправить | Отправлено ✓✓ | ✓ |
| Offline | Нет интернета | Отправить | Pending ⏱ | ✓ |
| Retry | Offline, потом Online | Отправить, ждать | Отправлено ✓✓ | ✓ |
| Spam | Много сообщений | Отправить x50 | Blocked 24h | ✓ |
| Large | 50MB видео | Отправить | Compress required | ✓ |

Итоговый чеклист для сценариев

• Happy Path — есть ли идеальный путь?
• Unhappy Paths — как приложение обрабатывает ошибки?
• Edge Cases — редкие, но важные ситуации?
• Failure Cases — что если цель не достигнута?
• Alternative Paths — другие способы сделать то же самое?
• Concurrent scenarios — может ли быть конфликт при одновременных действиях?
• Error handling — понятные сообщения об ошибках?
• Recovery — как восстановиться после ошибки?
• Performance — не медленно ли?
• Security — что если злоумышленник?

Главное: Сценарий — это не теория, это реальный путь пользователя. Если ты можешь описать его детально, значит ты понимаешь продукт достаточно хорошо.