MOLNIA: интерфейсы для парка из 4 000 электросамокатов на улицах Петербурга

Контекст и масштаб задачи

MOLNIA — независимый петербургский кикшеринг. В сезоны 2021–2022 годов сервис активно масштабировался: парк вырос с 500 до 4 000 электросамокатов Ninebot (модели Max G30, Pro и Plus), а общая зарегистрированная база превысила 400 000 пользователей.

Продуктовая экосистема обслуживала внушительный объем
городской мобильности:

500 000+

поездок за сезон

(в среднем 2 500 – 3 000 поездок в день, с пиками до 5 000 в теплые летние выходные)

40 000

активных пользователей в месяц

MAU в пиковые месяцы лета

При таком объеме ключевым вызовом для независимого бизнеса стала оборачиваемость техники и оптимизация операционных затрат. Выездные сотрудники на фургонах, менявшие батареи по всему городу, получали по 150 000 – 200 000 рублей в месяц. Если самокаты застревали в неликвидных спальных дворах с простоем по 48–60 часов, сервис терял деньги.

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

Масштаб парка

До 4 000 самокатов на балансе сервиса (Ninebot Max G30, Pro, Plus)

Экономика поездки

Средний чек — 95–125 ₽ (с учетом тарифов и подключаемой страховки)

Объем поездок

~500 000+ поездок за сезон (2 500 – 5 000 поездок в день)

Аудитория

Пиковый MAU — до 40 000 активных райдеров; база — 400 000+ регистраций

Моя роль

Продуктовый дизайнер (UX/UI, исследования, сценарии, спецификации, Design QA)

Сезонность

С теплой весны до первых заморозков и гололедицы осенью

Продуктовый контур

Android ServiceApp (с нуля), Web Admin (развитие функционала), B2C Mobile (доработка на данных)

Команда и моя роль в проекте

Я работал в продуктовой команде в тесной связке с продакт-менеджером, продуктовым аналитиком, тестировщиком (QA), разработчиками и главным дизайнером, который проводил дизайн-ревью.

Задачи внутри сервиса распределялись по направлениям:

B2B

• 

Приложение для полевых техников

Проектирование с нуля (0 → 1)

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

Web

Панель диспетчеров и логистики

Развитие и доработка функционала

Перестроил систему после внешней студии; спроектировал модули финансового аудита, журнал аппаратных тревог и картографический инструмент геозон

B2C

• 
• 

Клиентское приложение аренды

Доработка сценариев на данных

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

ФОТ выездных техников составлял ключевую часть операционных расходов сервиса (зарплаты специалистов на фургонах — 150 000 – 200 000 ₽/мес). Бригады тратили слишком много времени на одной точке: обслуживание партии из 15 разряженных самокатов в кузове «Газели» занимало до 15 минут. На каждый объект техник отдельно открывал камеру, ждал загрузки карточки (4–5 сек) и нажимал «Открыть замок».

Исследования

Чтобы найти причину потерь времени, мы с ПМ выехали на реальную смену вместе с выездной бригадой и провели замер каждого шага обслуживания партии из 15 самокатов в кузове «Газели».

Потоковый сценарийПродуктовая гипотеза

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

Что я спроектировал в интерфейсе:

Как проверили решение

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

Результат:

Ускорение работы в поле в 4 раза

Обслуживание партии самокатов в кузове сократилось с 15 до 3–4 минут. Это позволило смене из того же числа людей оборачивать парк в 4 000 самокатов без раздувания ночного штата

До появления мобильного приложения у логистов и техников не было инструмента оперативного контроля парка «на земле». Из-за этого до 15% самокатов регулярно оседало в «слепых зонах» (тупиках, закрытых дворах) и простаивало без аренды по 48–60 часов.

Это приносило двойной убыток: бизнес терял выручку от простоя, а аккумуляторы уходили в глубокий саморазряд («в ноль»), сокращая срок службы дорогого аккумулятора.

Исследование

Анализ базы показал: фургоны часто проезжали в 100 метрах от простаивающих самокатов, но не забирали их. А совместный выезд с водителем в дворы старого фонда выявил специфику полевой среды: из-за задержек сети во дворах экраны должны открываться мгновенно, а у техника на улице нет времени на скролл длинных списков — базовые данные (заряд, адрес, замок) должны считываться за секунду при любом освещении.

Что я спроектировал в интерфейсе:

Как проверили решение

Выкатили тестовую APK-сборку на две выездные бригады. Проверили работу софта в реальных дворах с неустойчивой связью и замерили скорость поиска брошенного самоката по фильтру простоя (время упало с 3 минут до 15 секунд).

Результат:

Снижение доли «мертвого» простоя с 15% до 4%

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

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

Исследование

Интервью с финдиректором и руководителем саппорта показали: кнопка списания срабатывала без подтверждений, а отсутствие сквозной финансовой истории затягивало разбор банковских претензий по чарджбэкам на 2–3 дня.

Что я спроектировал в интерфейсе:

БылоСтало

1. Пересобрал таблицу базы пользователей

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

1. Спроектировал вкладку «Транзакции»

   Поминутная таблица всех движений средств клиента (списания, холды, возвраты депозитов, штрафы, промокоды) с привязкой к ID транзакций в банке

Как проверили решение

Провели тестирование на фокус-группе операторов саппорта и финдиректоре: оператору дали реальную претензию с задачей «выяснить, кто, когда и на каком основании начислил клиенту 300 бонусов две недели назад». Цепочку восстановили за 40 секунд вместо прежних 2–3 дней запросов к разработчикам

Результат:

Ликвидация внутреннего фрода

Несанкционированные ручные корректировки балансов стали технически невозможными – 0 подтвержденных инцидентов за сезон 2022 года, а разбор чарджбэков ускорился с 3 дней до 3 минут

Комитет по транспорту Санкт-Петербурга ввел жесткие правила: запрет стоянок ближе 15м от метро и внезапные перекрытия улиц во время марафонов, ПМЭФ и праздников. За оставленные самокаты городом грозила эвакуация на штрафстоянки. В старой админке отключение 150 стоянок вручную по одной занимало 40–50 минут: диспетчеры физически не успевали к дедлайну распоряжений, и сервис получал штрафы.

Исследование

Интервью с логистами показали: город перекрывает улицы не точечно, а территориальными кластерами (кварталы, набережные). Требовался инструмент массового картографического контроля.

Что я спроектировал в интерфейсе:

Городские аномалии: сценарии, которых нет в учебниках по UX

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

Ночные водолазы

Служба безопасности с завидной регулярностью вылавливала самокаты со дна Мойки и каналов. Благодаря Журналу тревог и карточке объекта диспетчер посекундно восстанавливал трек (вплоть до точки падения с набережной) и точно знал, какому пользователю поддержка выставит счет за работу спасателей

Лесные «грибники»

Отдельная когорта клиентов арендовала самокаты на весь день и методично кружила по тропинкам Сосновки или Удельного парка с минутными остановками под деревьями (характер курьерской работы угадывался без труда).

Как проверили решение

Смоделировали с логистами экстренное перекрытие Невского проспекта: диспетчер выделил полигоном нужный периметр и массово переместил 40 стоянок за 1 минуту без единой ошибки.

Результат:

Реакция на перекрытия города за 1–2 минуты

Время массовой настройки стоянок сократилось с 50 минут до пары кликов, что исключило штрафы от администрации города и принесло +12–15% выручки за счет динамического тарифа в пиковые часы

Повышение маржиПрозрачная страховка без «темных паттернов»

При базовом чеке от 95 ₽ повышать тариф в лоб было нельзя из-за конкуренции. Анализ рынка показал: Whoosh и Urent навязывали страховку скрытно по умолчанию («темный паттерн»), получая шквал негатива в отзывах. Наша задача была сделать честный, добровольный переключатель перед поездкой, доказав его пользу прозрачными суммами выплат.

Бонусные стоянкиЛогистика парка

Фургонам было дорого собирать самокаты с окраин спальных районов. Требовалось мотивировать пользователей самих возвращать технику к транспортным узлам за кешбэк.

Edge CasesПроектирование краевых сценариев

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

Что я спроектировал в интерфейсе:

Как проверили решение

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

Запустили фичу через постепенную раскатку на 20% аудитории: замер воронки подтвердил, что появление блока страховки не уронило конверсию в старт поездки (CR удержали на уровне 86%), обеспечив добровольный opt-in свыше 30%

25–30% к чеку поездки за счет прозрачной страховки

Стабильный поток маржинальной выручки без негатива в сторах

15% парка пользователи стали возвращать из спальников сами

Снизились расходы на холостые рейсы фургонов логистов

Снижение оттока на технических сбоях

Понятные альтернативы на экранах отказов и сценарий оплаты долга удержали пользователей в сервисе.

Итоговые результаты работы

За два сезона дизайн-решения объединили городскую логистику, работу диспетчеров и клиентский опыт в слаженную систему. Мы выжали максимум эффективности из доступных ресурсов: ускорили выездных сотрудников в 4 раза, ликвидировали простои техники и повысили средний чек поездки.

Ускорение работы в поле в 4 раза

Сократил время обслуживания партии самокатов в кузове фургона с 15 до 3–4 минут за счет потокового мультискана и пакетных команд. Это позволило тому же числу техников оборачивать выросший парк в 4 000 единиц без расширения штата и переплат по ночному ФОТ.

Снижение «мертвого» простоя с 15% до 4%

Внедрил фильтрацию по времени бездействия (>48 ч) и устойчивую к оффлайну карточку объекта. Логисты стали прицельно формировать маршруты эвакуации, что сократило деградацию литиевых батарей от глубокого саморазряда «в ноль».

Ликвидация внутреннего фрода

Сквозной Audit Trail и обязательная привязка правок баланса к номерам тикетов хелпдеска сделали несанкционированные ручные корректировки технически невозможными: 0 инцидентов внутреннего мошенничества за сезон 2022 года.

Разбор спорных платежей за 3 минуты вместо 3 дней

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

Реакция на перекрытия города за 1–2 минуты

Инструмент полигонального выделения стоянок рамкой на карте заменил 50-минутное ручное перекликивание сотен точек, полностью исключив штрафы Комитета по транспорту за несвоевременную деактивацию парковок.

+25–30% к чеку за счет прозрачной страховки

Нативный переключатель добровольного страхования (+35 ₽) перед стартом аренды обеспечил стабильный opt-in свыше 30% без негатива в сторах, существенно повысив маржинальность коротких поездок с базовым чеком от 95 ₽

Снижение нагрузки на первую линию саппорта на 25%

Понятные экраны отказов с предложением соседнего свободного самоката и сценарий оплаты задолженности в один клик избавили поддержку от тысяч рутинных обращений при пиковой нагрузке в 40 000 MAU

Честная ретроспектива: почему сервис закрылся

Весной 2023 года MOLNIA прекратила работу по двум фундаментальным причинам вне контроля продуктовой команды:

Бонусные стоянкиЦеновая война гигантов

К осени 2022 года рынок Петербурга был перенасыщен техникой на 35–40%. Федеральные конкуренты — «Яндекс Go», Whoosh и Urent — субсидировали поездки венчурными деньгами и экосистемами. Независимый локальный бизнес не выдержал ценовой войны на собственные средства.

CapExАмортизация железа

Компания недооценила скорость износа самокатов в климате Петербурга. К сезону 2023 года парк выработал ресурс и требовал масштабной замены, но у стартапа не было капитала для закупки тысяч новых Ninebot.

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