Рапидо

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

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

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

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

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

Цель: проверить, как различная компоновка игровых элементов влияет на восприятие, удобство заполнения билета и готовность пользователя дойти до оплаты.

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

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

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

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

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

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

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

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

На этом этапе я опирался на сформированные Job Stories и построил user flow для ключевых пользовательских путей.

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

Определив приоритетный сценарий, я перешёл к первой итерации макетов Рапидо.

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

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

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

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

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

Точные метрики проекта остаются закрытыми, поэтому в кейсе я не привожу внутренние цифры.

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

Фокус был на сокращении лишних действий, повышении ясности интерфейса и улучшении основного пути пользователя от входа в игру до покупки билета.