Когда платит родитель, а пользуется ребёнок: как это меняет архитектуру EdTech-продукта

В образовательной подписке плательщик и ежедневный пользователь часто разные люди. Родитель принимает решение и оценивает пользу, а школьник выполняет задания. Если проектировать сервис только для одного из них, родитель получает либо информационный вакуум, либо поток непонятных данных, а ребёнок — ощущение постоянного наблюдения. Такая модель требует не дополнительного кабинета, а отдельной продуктовой архитектуры.

Один продукт — две разные задачи

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

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

Я смотрю на эту проблему одновременно как магистр по специальности «Прикладные математика и физика», человек с репетиторской практикой, родитель школьника, сдававшего ОГЭ, и разработчик «До Сотки» — приложения для подготовки к ОГЭ и ЕГЭ по десяти предметам с заданиями по формату ФИПИ, прогнозом балла и статистикой прогресса для родителя.

Главный вывод из такого пересечения ролей: родительский интерфейс нельзя делать копией ученического. У сторон разные вопросы, язык и горизонт принятия решений.

Начинать следует не с экранов, а с карты ролей

Ученический путь обычно строится вокруг короткого цикла:

1. Что мне делать сейчас?
2. Сколько времени это займёт?
3. Что будет после выполнения?
4. Как продолжить в следующий раз?

Родительский цикл устроен иначе:

1. Начал ли ребёнок пользоваться продуктом?
2. Сохраняется ли регулярность?
3. В каком направлении меняется ситуация?
4. Нужно ли что-то обсудить с ребёнком или преподавателем?

Если смешать эти циклы, продукт начинает перекладывать работу на семью. Родителю показывают подробную учебную телеметрию, которую приходится самостоятельно интерпретировать. Школьнику добавляют отчёты и статусы, созданные не для него, а для взрослого наблюдателя.

Поэтому первый продуктовый артефакт здесь — не макет кабинета, а таблица ролей. Для каждого события в ней фиксируются три вещи: кому оно полезно, какое решение помогает принять и в какой форме должно быть показано.

Данные не равны информации

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

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

Здесь важен принцип минимально достаточной детализации. Родитель должен видеть основания для вывода, но не обязан превращаться в аналитика или учителя. Продукт создаёт ценность не количеством собранных событий, а качеством их перевода в понятное решение.

Прозрачность не должна становиться слежкой

У родительской статистики есть очевидный риск: полезная функция может восприниматься ребёнком как инструмент контроля каждой минуты.

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

• какие действия действительно важны для образовательного процесса;

• какие события не стоит показывать вообще;

• как объяснить школьнику, что именно видит родитель;

• где проходит граница между общей динамикой и детальной историей;

• какие уведомления помогают, а какие провоцируют лишний конфликт.

Хорошая прозрачность симметрична. Родитель понимает состояние процесса, а ребёнок понимает правила передачи данных. Скрытая или чрезмерно детальная наблюдаемость снижает самостоятельность и может ухудшать само использование продукта.

Активация семьи состоит из двух активаций

Регистрация плательщика ещё не означает, что образовательный продукт начал работать. После неё должен состояться переход к фактическому пользователю: приглашение, вход школьника и первое осмысленное действие.

Поэтому семейную активацию полезно рассматривать как последовательность:

1. Родитель понимает назначение сервиса.
2. Создаётся или подключается профиль школьника.
3. Ребёнок самостоятельно входит в продукт.
4. Он выполняет первое содержательное действие.
5. Родитель получает первое понятное подтверждение, что процесс начался.

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

Такая декомпозиция влияет и на интерфейс, и на коммуникации, и на работу поддержки. Вместо общего вопроса «почему пользователь не активировался?» появляются конкретные точки: не состоялось приглашение, непонятна роль ребёнка, слишком сложен первый вход или родитель не увидел результата запуска.

Уведомление должно предлагать решение

В продукте с двумя ролями легко создать слишком много коммуникаций. Любое действие школьника можно превратить в сообщение родителю, но это быстро обесценивает канал.

Полезнее классифицировать уведомления по решениям:

• информационные — процесс идёт штатно, вмешательство не требуется;

• сигнальные — изменилась регулярность или появился устойчивый признак затруднения;

• координационные — семье нужно согласовать следующий шаг;

• сервисные — требуется действие с доступом, профилем или настройками.

У каждого сообщения должен быть понятный ответ на вопрос «зачем я это получил?». Если после уведомления нет разумного решения, вероятно, оно не нужно.

Отдельная продуктовая задача — частота. Родителю может быть полезнее одна собранная сводка, чем множество событий в реальном времени. Это снижает информационный шум и оставляет школьнику пространство для самостоятельной работы.

Метрики тоже приходится разделять

У такого продукта нет одной универсальной воронки. Команде нужны как минимум три слоя наблюдения.

Первый — ученический: состоялся ли первый полезный сценарий, возвращается ли школьник, формируется ли регулярность.

Второй — родительский: открываются ли сводки, понятны ли их формулировки, приводят ли они к осмысленным действиям, а не к обращениям в поддержку.

Третий — семейный: завершено ли соединение ролей, сохраняется ли совместное использование и не возникает ли перекоса, при котором платит один человек, а продукт фактически не используется другим.

Это меняет приоритизацию разработки. Функция может нравиться родителю, но усложнять путь ребёнка. Или повышать активность школьника, оставаясь невидимой для плательщика. Решение о её ценности нельзя принимать по метрике только одной стороны.

Продуктовый результат — согласованность ролей

Разделение плательщика и пользователя нельзя считать частным UX-сценарием. Оно влияет на онбординг, права доступа, модель данных, уведомления, аналитику, поддержку и удержание.

Сильная архитектура не заставляет родителя постоянно проверять ребёнка и не оставляет его без понимания происходящего. Она даёт школьнику самостоятельный рабочий контур, а взрослому — достаточно контекста для редких и своевременных решений.

В таком EdTech-продукте ценность возникает не внутри отдельного экрана. Она появляется в корректной передаче контекста между двумя людьми, которые участвуют в одном процессе, но отвечают в нём за разные вещи.