Перейти к основному содержимому

User Stories: аналитик / UX

Эта страница описывает user stories для внутренней аудитории: аналитика, UX-исследователя и продуктовой команды.

Главная задача этой аудитории - понимать поведение родителей и детей в продукте, находить проблемы в пользовательском сценарии и принимать решения на основе данных.

MVP-сценарий​

Минимальный рабочий сценарий для аналитика / UX:

  1. Увидеть, сколько пользователей дошло до ключевых шагов MVP-сценария.
  2. Понять, где пользователи теряются или останавливаются.
  3. Сравнить созданные, одобренные и прослушанные сказки.
  4. Понять, возвращаются ли пользователи к библиотеке и повторному прослушиванию.
  5. Найти сигналы качества: перегенерации, отмены, повторные прослушивания, сохранения.
  6. Получить прямую обратную связь от пользователей: неисправности, просьбы об улучшениях, свободные комментарии.
  7. Сформулировать продуктовые гипотезы на основе поведения и пользовательской обратной связи.

P0: минимально необходимая аналитика​

P0 user stories нужны, чтобы команда могла понять, работает ли базовый MVP-сценарий и где он ломается.

  • P0.1 Воронка MVP: As an analyst, I want to see the funnel from sign-in to first story playback, so that I can understand whether users complete the core product scenario.
  • P0.2 Шаги создания сказки: As an analyst, I want to track each step of story creation, so that I can identify where parents drop off or get stuck.
  • P0.3 Созданные сказки: As an analyst, I want to know how many stories are generated, so that I can measure whether parents reach the main value of the product.
  • P0.4 Одобренные сказки: As an analyst, I want to compare generated stories with approved stories, so that I can understand whether the generated content meets parent expectations.
  • P0.5 Аудио-генерация: As an analyst, I want to track how many approved stories become audio, so that I can understand whether audio generation is valuable and usable.
  • P0.6 Первое прослушивание: As an analyst, I want to know whether users play the audio after it is created, so that I can validate the bedtime listening scenario.
  • P0.7 Сохранение в библиотеку: As an analyst, I want to track whether stories are saved to the library, so that I can understand whether users see long-term value.
  • P0.8 Повторное прослушивание: As an analyst, I want to track repeated plays of saved stories, so that I can understand whether stories become part of a family ritual.
  • P0.9 Ошибки генерации: As an analyst, I want to see text and audio generation errors, so that I can separate product problems from technical failures.
  • P0.10 Базовая сегментация: As an analyst, I want to segment behavior by child age, so that I can understand how product value differs across age groups.
  • P0.11 Сообщение о неисправности: As a UX researcher, I want users to report problems from inside the product, so that the team can discover broken flows that analytics events alone may not explain.
  • P0.12 Запрос улучшения: As a UX researcher, I want users to request product improvements, so that the team can understand what users expect next.
  • P0.13 Свободная обратная связь: As a UX researcher, I want users to leave open-ended feedback, so that the team can hear concerns, emotions, and use cases that were not predicted in advance.

P1: UX-диагностика и продуктовые решения​

P1 user stories помогают понять, почему пользователи ведут себя определенным образом, и какие продуктовые улучшения стоит делать первыми.

  • P1.1 Перегенерация: As an analyst, I want to track story regenerations, so that I can identify when the first generated story does not satisfy parents.
  • P1.2 Причины неодобрения: As an analyst, I want parents to optionally mark why they rejected a story, so that I can understand what content problems matter most.
  • P1.3 Выбор персонажей: As an analyst, I want to see which ready-made characters are selected most often, so that I can understand which characters create the most demand.
  • P1.4 Пользовательские персонажи: As an analyst, I want to compare ready-made and custom characters, so that I can decide how much effort to invest in character creation tools.
  • P1.5 Длительность прослушивания: As an analyst, I want to know how much of the audio story was played, so that I can understand whether children stay engaged.
  • P1.6 Возврат пользователей: As an analyst, I want to track whether parents return after the first story, so that I can understand early retention.
  • P1.7 Использование библиотеки: As an analyst, I want to see how often users open the library, so that I can understand whether saved stories have real value.
  • P1.8 Особые ситуации: As an analyst, I want to track stories created for specific situations, so that I can evaluate whether therapeutic or routine-based use cases are important.
  • P1.9 Качество онбординга: As an analyst, I want to see how long it takes from opening the app to first playback, so that I can decide whether onboarding is too heavy.
  • P1.10 UX-проблемы: As a UX researcher, I want to see rage clicks, repeated attempts, or abandoned forms, so that I can find confusing parts of the interface.

P2: продвинутая аналитика​

P2 user stories полезны для масштабирования продукта, но их можно отложить до проверки базовой ценности.

  • P2.1 Когорты: As an analyst, I want to compare cohorts by signup week, so that I can understand whether product changes improve retention.
  • P2.2 A/B тесты: As an analyst, I want to compare variants of story creation flows, so that I can make UX decisions based on behavior rather than opinion.
  • P2.3 Качество контента: As an analyst, I want to connect story attributes with approval and replay rates, so that I can understand what makes stories successful.
  • P2.4 Монетизация: As an analyst, I want to connect usage behavior with subscription or purchase decisions, so that I can understand what drives willingness to pay.
  • P2.5 Семейные сценарии: As an analyst, I want to understand whether multiple adults use the same account, so that I can evaluate family sharing needs.
  • P2.6 Долгосрочные привычки: As an analyst, I want to track bedtime usage patterns over time, so that I can understand whether Moona Tales becomes a recurring ritual.
  • P2.7 Контекстная обратная связь: As a UX researcher, I want to collect short feedback after meaningful moments, so that I can combine behavioral data with user explanations.

Минимальные события для MVP​

Чтобы закрыть P0-аналитику, продукт должен отправлять события по ключевым шагам:

  • пользователь вошел в приложение;
  • профиль ребенка создан;
  • персонаж выбран или создан;
  • создание сказки запущено;
  • сказка создана;
  • сказка одобрена;
  • сказка отклонена или перегенерирована;
  • создание аудио запущено;
  • аудио создано;
  • аудио воспроизведено;
  • сказка сохранена в библиотеку;
  • сказка повторно воспроизведена из библиотеки;
  • произошла ошибка генерации текста или аудио;
  • пользователь отправил сообщение о неисправности;
  • пользователь отправил запрос на улучшение;
  • пользователь отправил свободный комментарий.

Минимальная обратная связь для MVP​

На старте в продукте нужен простой способ оставить обратную связь без сложной формы и без ухода в отдельный канал.

Минимально нужно поддержать три типа обратной связи:

  • неисправность - что-то не работает, сломалось или мешает завершить сценарий;
  • улучшение - пользователь хочет предложить идею или недостающую возможность;
  • свободный комментарий - пользователь хочет просто рассказать, что ему понравилось, не понравилось или что произошло в реальном использовании.

Для каждого сообщения полезно сохранять:

  • тип обратной связи;
  • текст пользователя;
  • текущий экран или сценарий;
  • связанный объект, если он есть: сказка, аудио, персонаж, профиль ребенка;
  • технический контекст: время, пользователь, версия приложения, ошибка, если она была.

Что важно не собирать лишнего​

Аналитика должна помогать принимать продуктовые решения, а не превращаться в сбор данных ради данных.

На старте не нужно собирать:

  • лишние персональные данные ребенка;
  • содержимое приватных семейных сценариев без явной необходимости;
  • сложные behavioral-события, которые не влияют на ближайшие решения;
  • метрики, для которых заранее непонятно, какое решение они помогут принять.