xNode: как игра помогла вырастить аудиторию продукта

Привет! Мы — Murukae, студия разработки и дизайна. Берём на себя весь процесс — от первых концептов до полноценной разработки и запуска.

Посмотреть, как мы гоняем на мероприятия, работаем над проектами и просто веселимся можно в нашем Telegram-канале.

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

К нам пришли с идеей запустить mini-app для привлечения новых пользователей к основному продукту. Выбрали телеграм, потому что сервис основной и, возможно, единственный выход на самую крупную аудиторию криптовиков.

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

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

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

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

Фанатическая любовь распространилась и на клиента. После одной из встреч мы с клиентом сходили в компьютерный клуб и играли в R.E.P.O.

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

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

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

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

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

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

Например, у нас был спор про кнопку переключения языка. Телеграм открывает веб-апп на языке гаджета, поэтому англоговорящие пользователи хотели сменить язык, но не все понимали, как. Провели тест, сделали вывод, что многих тормозит начальный UX. Переместили настройки с аватарки в отдельный пункт в таббаре.

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

Ведь это не просто веб или нативка — это Telegram Mini App со своей системной средой. Тесты и бесчисленное число гипотез были важны для конечного продукта.

Передали макеты с максимально подробно расписанными комментариями для разработчиков. Просто скинуть экраны и сказать «ну вы там разберётесь» — точно не про нас.

В приложении куча состояний, логик и анимаций, в которых легко запутаться. Мы всё максимально разложили: к каждому экрану — пояснение, каждой анимации — видео. Прежде чем отдать макеты на код, мы созванивались и подробно рассказывали, как должна работать каждая анимация и свайп на отдельной странице. Какой апгрейд за что отвечает. Даже с объяснением разработчики иногда путались, без них — вовсе бы был кавардак.

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

Нам нужно было создать приложение, которое не разорвет от 300-500к пользователей за раз и не зависнет при первой же выдаче рефералки. Что оказалось проблематичным.

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

RAW — быстрая, но мы сами формируем запрос.ORM — иногда медленная, но можно общаться по-человечески. (Даже немного фамильярно, если хочется.) Но она ищет по-своему, делает много лишних движений.

По сути, у нас был выбор между сделанным под нас, но запаристым набором из «Лего» — RAW, и готовым конструктором в ORM.

Мы выбрали ORM, хоть она и была медленнее, но с ней было проще работать. При первом же запуске на 10 000 пользователей мы поняли, что фоновые запросы стремятся к бесконечности. Поэтому большую часть мы перенесли на RAW, что увеличило скорость с 1 сек. до 0,01с.

База данных быстро превысила количество пользователей в 100к, потом 200к и дошла до 300 000. Такой большой наплыв пользователей затормозил задачи в приложении. В какой-то момент код перестал справляться. Произошла ситуация, сравнимая с 2 км пробкой перед одним единственным шлагбаумом: пользователи прибывали, но система не успевала их обрабатывать.

Оказалось, что PostgreSQL при обработке больше 100 000 операций начинает тормозить, а вдобавок Atomic-транзакции, на которых мы работаем, замораживает данные, с которыми сейчас работает база. Получилась бесконечная петля. Если брать тот же пример с пробкой, то мы поняли, что помимо 2 км пробки, машины ещё и останавливают на проверку перед ней, а поток не заканчивается.

Чтобы разгрузить эту бесконечную пробку, мы применили batch size — метод в PostgreSQL, который разбивает один огромный запрос на более мелкие. Например, не 100к записей за раз, а порционно по 1к. Проще говоря, мы поставили больше шлагбаумов, чтобы разгрузить поток.

Сейчас мини-аппка стоит на частном сервере, который полностью закрывает потребности использования приложения до 500 000 пользователей за раз, но в дальнейшем мы перейдем на Kubernetes. Технология поможет кратно увеличить объем.

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

Пока шла разработка, подключились к Telegram-каналу заказчика. Чтобы продукт не простаивал и начинал набирать интерес ещё до запуска, делали анимации для постов, общались с комьюнити-менеджером, помогали выстраивать прогрев.

Чем дальше шёл проект, тем больше мы ощущали xNode не как заказчика, а как часть своей команды. В какой-то момент даже стали пересекаться вне рабочих задач: бильярд, рестораны, компьютерные клубы.

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

По итогу результатом довольны и мы, и заказчик.

• Количество юзеров: 48585
• Регистраций на основном сайте: 2006
• Получили награду «лучшая работа UI» на платформе дипрофайл

Для нас это ещё и крутой опыт: Telegram Mini Apps — относительно новый формат, и было классно ощущать, что мы двигаемся вместе с рынком.

Тимур Нариманов — CEO, руководитель проекта
Анна Ким — Арт директор
Павел Мартынчик — Продуктовый дизайнер
Настя Пелевина — Проджект-менеджер
Даня Саенко — Технический директор
Алишер Исмоилов — Разработчик
Андрей Буйнов — редактор статьи & PR-менеджер студии