Челленджи
- Время до первой ценности
- Долго
- Зависимость от других
- Высокая
- Сложность реализации
- Средняя
- Повторяемость
- Низкая
iGaming · 2022–2025 · Product Designer
Как я перезапустил продукт и вырастил базу пользователей в 13 раз за 2 месяца
Пивот с нуля: от сломанной модели челленджей до быстрых матчей, которые реально работают.
Пивот продуктаMVP за короткий циклПоведенческая логика
×13
Рост базы пользователей
40%
Конверсия в первый матч
300
Матчей в месяц у топ-игроков
2 мес
До первого результата
TL;DR
Платформа для соревновательных игр на деньги два года разрабатывалась, а после релиза 5 месяцев не показывала роста. Я инициировал смену core-механики и спроектировал новый user flow — командой запустили MVP. Результат: ×13 к базе пользователей, 40% конверсия в первый матч — в 10 раз лучше ожиданий.
Контекст
Я пришёл в проект на стадии идеи и проработал в нём 3 года — с первого дня до закрытия. Команда насчитывала 18 человек, я был единственным дизайнером. Отвечал за весь UX и визуальный дизайн, участвовал в продуктовой стратегии и инициировал ключевой поворот в направлении продукта.
Проблема
Что не работало и почему
Изначально продукт строился вокруг пользовательских челленджей: игрок сам придумывает соревнование, сам его организует, находит соперника и проводит игру. На бумаге это выглядело логично. На практике механика требовала слишком много действий до первой ценности.
Как выглядела платформа
- 1Зарегистрироваться
- 2Придумать и создать челлендж
- 3Дождаться, пока кто-то примет вызов
- 4Самому провести игру
- 5Загрузить результаты
- 6Согласовать победителя или пройти модерацию
Данные
Поведение подтверждало диагноз
- Пользователи появлялись только во время рекламных кампаний.
- После окончания рекламы активность почти сразу исчезала.
- Признаков самостоятельного органического роста не было.
Активность держалась только на рекламе
2рекламные кампании дали всплеск
0органического роста между кампаниями
150регистраций за 5 месяцев
Рекламная кампания 1 Рекламная кампания 2
Как мы читали данные
Релиз платформы
Первая версия продукта с механикой челленджей запущена.
Кампания 1 — сбор обратной связи
Неудобно, непонятно, кривоТвич-стримеры играли на платформе в прямом эфире.
Редизайн
Ошибка диагнозаУлучшили интерфейс — платформой стало удобнее пользоваться. Но решение роста не дало: мы лечили симптом, а не причину. Зато редизайн убрал интерфейсный шум — и во второй кампании пользователи смогли добраться до настоящей проблемы.
Кампания 2 — сбор обратной связи
Создавать челлендж — это работа, никто не хочетИнтерфейс уже не мешал — выплыло главное.
Пивот механики
Верный диагнозПроблема не в дизайне, а в core-механике. Инициировали смену модели на быстрые матчи.
Гипотеза и решение
Как я пришёл к идее быстрых матчей
Когда платформа не показывала роста, команда приняла решение двигаться к турнирам — следующей большой фиче. Передо мной поставили задачу: спроектировать турниры.
Прежде чем рисовать, я изучил как это работает у конкурентов. На Fastcup, Cybershoke и других платформах я увидел системную проблему: большинство турниров мёртвые — не набирают участников, не стартуют. Исключение — Faceit, но это самая крупная платформа в нише, конкурировать с ней на нашем этапе нереально.
Маленькая аудитория
Маленькие взносы
Маленькие призовые
Маленький доход платформы
Для нормального турнира по CS2 нужны собственные игровые серверы — без них организация снова ложится на пользователя.
Я понял: если мы запустим турниры в таком виде — повторим ту же ошибку, что с челленджами. Механика снова потребует от пользователя слишком много работы до первой ценности.
Тогда я принял решение выйти за рамки задачи. Параллельно с турнирами я самостоятельно спроектировал быстрые матчи — изучил как это устроено у конкурентов, выстроил user flow, нарисовал screen flow. На презентации я показал оба варианта рядом. Увидев интерфейсы, команда сама сделала выбор: быстрые матчи — это то, что нужно в первую очередь. Реализовать проще, серверов нужно меньше, не нужно собирать 16+ игроков. И главное — пользователь сразу получает ценность.
Материалы решения
| Челленджи | Турниры | Быстрые матчи | |
|---|---|---|---|
| Время до первой ценности | Долго | Очень долго | Быстро |
| Зависимость от других | Высокая | Высокая | Низкая |
| Сложность реализации | Средняя | Высокая | Средняя |
| Повторяемость | Низкая | Низкая | Высокая |
Турниры
- Время до первой ценности
- Очень долго
- Зависимость от других
- Высокая
- Сложность реализации
- Высокая
- Повторяемость
- Низкая
Быстрые матчи
- Время до первой ценности
- Быстро
- Зависимость от других
- Низкая
- Сложность реализации
- Средняя
- Повторяемость
- Высокая
Wireframe: турнирная механика
Wireframe: экран поиска матча
Старый флоу — 6 шагов
1Зарегистрироваться
2Придумать и создать челленджработа
3Дождаться, пока кто-то примет вызовработа
4Самому провести игруработа
5Загрузить результатыработа
6Согласовать победителя / пройти модерациюработа
Новый флоу — 6 шагов
1Зарегистрировался
2Выбрал игрувыбор
3Выбрал взносвыбор
4Нажал «найти матч»1 действие
5Сыгралценность
6Получил деньгирезультат
Ключевой инсайтАнализ поведения пользователей дал ключевое понимание: люди приходят на платформу не "поиграть", а доказать себе, что они лучше — и заработать на этом. Монетизация скилла была сутью платформы с первого дня. Вопрос был только в том, какая механика даёт к этому самый короткий путь.
Что я сделал
Этапы работы
01
Конкурентный анализ
Изучил три платформы — Faceit, Fastcup, Cybershoke. Зафиксировал ключевые паттерны: как устроен поиск матча, какие взносы, как обрабатываются результаты. Главный вывод: турниры на всех платформах кроме Faceit не собирают участников — висят мёртвые. Быстрые матчи как механика давали мгновенный цикл и не зависели от одновременного присутствия большого числа игроков. Из анализа Fastcup взял за основу механику матчей, но доработал: у них если игрок ливнул в середине игры, матч всё равно идёт до конца — пользователь теряет 15 минут впустую. Мы заложили авто-победу/поражение при ливе.
| Платформа | Механика | Проблема | Что взяли |
|---|---|---|---|
| Faceit | Матчи и турниры | Крупнейшая платформа в нише, конкурировать напрямую на нашем этапе нереально. | Ориентир по ожиданиям аудитории. |
| Fastcup | Быстрые матчи | Если игрок ливнул в середине игры, матч всё равно идёт до конца. | Взяли матчевую механику за основу и заложили авто-победу/поражение при ливе. |
| Cybershoke | Турниры и игровые сценарии | Турниры не собирают участников и висят мёртвыми. | Подтвердили риск турнирной модели для маленькой аудитории. |
Faceit
- Механика
- Матчи и турниры
- Проблема
- Крупнейшая платформа в нише, конкурировать напрямую на нашем этапе нереально.
- Что взяли
- Ориентир по ожиданиям аудитории.
Fastcup
- Механика
- Быстрые матчи
- Проблема
- Если игрок ливнул в середине игры, матч всё равно идёт до конца.
- Что взяли
- Взяли матчевую механику за основу и заложили авто-победу/поражение при ливе.
Cybershoke
- Механика
- Турниры и игровые сценарии
- Проблема
- Турниры не собирают участников и висят мёртвыми.
- Что взяли
- Подтвердили риск турнирной модели для маленькой аудитории.
02
Инициировал пивот
Вышел за рамки задачи: параллельно с турнирами самостоятельно спроектировал быстрые матчи и показал оба варианта на презентации.
Читать подробнее03
User flows и архитектура
Спроектировал user flow и screen flow для быстрых матчей. Одно из ключевых решений — отказ от мобильной версии: суть платформы изменилась, пользователь играет в CS2 с компьютера, мобильный контекст перестал быть релевантным. Флоу челленджей был громоздким — десятки разветвлённых путей. Флоу быстрых матчей получился лаконичным: меньше экранов, меньше решений, больше скорости до первой ценности.
04
Визуальный дизайн
Отрисовал веб-версию продукта и выстроил дизайн-систему.
05
Доведение до прода
Ускорение разработки случилось комплексно. На старте проекта разработчики были закрыты к диалогу — интерфейсы выходили захардкоженными, правки занимали недели. Позже в команду пришли новые разработчики, с которыми получилось выстроить нормальную коммуникацию в паре дизайнер-фронт-бек. На этой основе мы вместе построили компонентную дизайн-систему. В результате то, что раньше требовало месяца, стало решаться за дни.
12 мес→3 мес
скорость разработки новой версии
результат смены команды, выстроенного диалога и компонентной системы
Результаты
Результаты превзошли ожидания в 10 раз
3 стримера с аудиторией около 100 человек каждый привели примерно 2 000 пользователей за 2 месяца.
| До пивота | После пивота | |
|---|---|---|
| Новые пользователи | 150 за 5 месяцев | 2 000 за 2 месяца |
| Конверсия в 1-й матч | — | ~40% |
| Конверсия в повтор | — | ~10% |
| Макс. активность | — | 300 матчей/мес |
| Частота возврата | — | каждый день или через день |
Почему платили
90%
Зарабатывать на скилле
8%
Тестировали продукт
2%
Азарт
Аудитория пришла за монетизацией скилла, а не за азартом — это определяло все продуктовые решения.
Проблемы и ограничения
Рост обнажил узкие места
Матчмейкинг без учёта скилла
Слабые игроки попадали к сильным и уходили. Среднее — 3 матча на пользователя. Причина не в интерфейсе, а в отсутствии рейтинговой системы. Я предложил как минимальное решение ограничить матчмейкинг по диапазону рейтинга уже на старте — без полноценной системы лиг это дало бы базовую защиту новичков. Реализовать не успели: финансирование закончилось раньше.
Бонусхантеры
Часть пользователей создавала несколько аккаунтов для получения бонусов. Потребовалась дополнительная верификация через Steam.
Что бы я сделал сейчас
- Система рейтингов и лиг — матчинг по уровню
- Лидерборды и фракции — социальное сравнение
- Социальные механики: друзья, сообщения
- Ограничение матчмейкинга по рейтингу на старте
Выводы
Этот проект изменил то, как я думаю о дизайне
Я начинал как UX/UI дизайнер — строил флоу, рисовал экраны. К концу думал иначе: что влияет на поведение пользователя, и почему он возвращается или уходит.
01
От UX/UI к продуктовой логике
Начал задавать вопрос «зачем эта механика существует», а не «как её оформить».
02
Поведенческая психология
Понял, как формируются привычки и что вызывает повторное действие.
03
Решения, меняющие поведение
Не просто интерфейс — структура, которая влияет на то, как пользователь принимает решения.
Проект закрыт в связи с прекращением финансирования.
Прочитано0%