Как проектировать социальные сценарии внутри коммерческих продуктов

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

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

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

Именно такую задачу команда MWI решала в рамках разработки Course.Tours: в платформу нужно было встроить бесплатные онлайн-курсы для детей из малообеспеченных семей. Довольно быстро стало понятно: недостаточно просто сделать обучение бесплатным. Чтобы такой сценарий действительно работал, внутри продукта потребовался отдельный пользовательский флоу. 

Почему бесплатные курсы стали отдельным продуктовым сценарием

Course.Tours создавался как международный EdTech-маркетплейс с концепцией «обучение + путешествие». Пользователь выбирает языковой курс или лагерь в Дубае или Дублине и сразу бронирует жилье, трансфер, визовую поддержку. Каталог — 30 000+ курсов, старт на рынках России, СНГ и ОАЭ. Внутри это достаточно сложная система: онлайн- и офлайн-курсы, индивидуальные и групповые занятия, преподаватели, школы, расписание, коммуникация между участниками и различные сценарии бронирования. 

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

Основной пользовательский путь Course.Tours проектировался для взрослой аудитории. Взрослый понимает, зачем нужна регистрация, подтверждение аккаунта или дополнительный шаг перед записью. Даже если процесс кажется неудобным, он способен пройти его до конца.

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

Почему плашка «курс со скидкой 100%» не работает

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

Для взрослого пользователя это может быть просто лишним действием. Для ребенка — точкой выхода из сценария.

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

UX для ребенка: меньше действий, меньше точек выхода

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

Путь выглядел так: 

→ зашел на платформу

   → нашел раздел бесплатных курсов

      → выбрал тему

         → посмотрел возраст, уровень, расписание

            → нажал «Записаться»

               → получил подтверждение

                  → в назначенное время попал на урок.

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

Каждое отклонение от этого пути — сложная регистрация, лишние поля, непонятные статусы, проверка почты — увеличивало вероятность выхода из сценария. Поэтому регистрация проектировалась короткой, формулировки — понятными: не «создать заявку», а «записаться».

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

Самостоятельность не должна снижать безопасность

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

В Course.Tours коммуникация с преподавателем не открывается как обычный мессенджер. Доступ к чату привязан к конкретному курсу и учебной группе — ребенок может взаимодействовать с преподавателем только в рамках образовательного процесса. После завершения занятия доступ к онлайн-классу автоматически закрывается. Это снижает нагрузку на преподавателей и исключает появление неконтролируемых сценариев использования платформы.

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

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

Как social-флоу существует внутри коммерческого продукта

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

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

Как не превратить социальную миссию в строчку в отчете

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

Задача социальной функции внутри продукта — спроектировать путь, которым действительно воспользуются. В случае Course.Tours для этого понадобился отдельный сценарий записи, собственная логика безопасности, роли, расписание и метрики. Полный разбор проекта и продуктовых решений смотрите в кейсе Course.Tours. А если интересна техническая сторона платформы — архитектура, роли пользователей, система бронирования и онлайн-занятий — об этом рассказываем в отдельном материале.

Если планируете встроить социальный сценарий в продукт — давайте обсудим.