На связи продакт каршеринга Ситидрайв — Настя Голованова. Сегодня расскажу, как мы пересобрали UX пост-осмотра автомобиля без единой строчки бэкенда и без A/B-тестов — только через быстрое прототипирование, юзер-интервью и разумные продуктовые компромиссы. Получился кейс, где дизайн решает бизнес-задачу, а изменения в одном экране экономят миллионы. Будет полезно всем, кто работает на стыке клиентского опыта и юнит-экономики 🤝
Что такое пост-осмотр и почему мы взялись его переделывать
Пост-осмотр авто в каршеринге — это возможность для пользователя зафиксировать состояние машины после аренды. В приложении Ситидрайва это выглядело так: клиент завершал аренду, получал чек, а потом в отдельном экране приложение предлагало «по желанию» сделать пару снимков. Неудивительно, что большинство пользователей просто пропускали этот этап. При этом в начале аренды есть предосмотр — пользователь может зафиксировать уже имеющиеся повреждения до поездки.
В итоге отсутствие полной информации о состоянии авто в разные моменты времени создавало ряд проблем:
Повреждения обнаруживались поздно: через часы или дни, и найти виновника становилось сложнее. Оперативное выявление помогло бы быстрее обслуживать машины и постоянно сохранять авто в хорошем состоянии.
Касания лояльных пользователей: во время расследования приходилось обращаться к клиентам, включая тех, кто не был виновен, что вызывало раздражение и снижало доверие.
Расследования длились до 3 месяцев, потому что доказательств не хватало.
Низкая возвращаемость убытков: возвращаемость убытков с помощью пост-осмотра пользователями составляла чуть больше 30%.
Причин, чтобы заняться редизайном, накопилось достаточно. С одной стороны, команда по урегулированию убытков запрашивала улучшения: без фото невозможно понять, кто повредил авто. С другой — аналитика показывала, что лишь 30% убытков удавалось вернуть. И, наконец, сами пользователи писали в поддержку, присылая фото в обход интерфейса, просто чтобы «подстраховаться». Это создавало дополнительную нагрузку на саппорт. Все сошлись в одном мнении — нам нужно было как-то побудить людей к выполнению пост-осмотра при завершении аренды.
Как согласовать фичу с топами и не потратить лишнего: бюджет, модель и немного читерства
Прежде чем пуститься в разработку, нам нужно было доказать её экономическую целесообразность и согласовать идею с руководством. Я построила финансовую модель, аналитики сказали: «Впечатляет, но давай умножим на 0,8 😁».
Основной метрикой, на которую могла бы повлиять наша фича — возвращаемость убытков и снижение доли кейсов с невыявленным виновником благодаря улучшению доказательной базы с помощью фотографий, которые пользователи загружают при пост-осмотре.
Как мы считали эффективность?
Вначале мы составили план. Для этого использовали данные команды по урегулированию убытков и посмотрели на текущую ситуацию. Оказалось, что повысить возвращаемость до 50% — вполне реалистичная цель. После этого мы посчитали три основных сценария для релиза:
Пессимистичный: возвращаемость 50% и увеличение доли установленных виновников до 50% случаев.
Реалистичный: возвращаемость 50% и увеличение доли установленных виновников до 80%.
Оптимистичный: возвращаемость 60% и увеличение доли установленных виновников до 80%.
Одного прогноза недостаточно, поэтому наше решение прошло оценку командой разработки. Тут мы использовали «читерский» приём, который позволил сэкономить время и ресурсы — показали мокапы ребятам из разработки ещё до того, как решение было окончательно утверждено.
Изменение, действительно, оказалось масштабное, но нам удалось выработать общее решение и не привлекать бэкенд разработку — сделать исключительно визуальные изменения на стороне клиента. Это позволило сэкономить время и деньги — вместо 1,5 квартала мы уложились за 1 месяц на мобильной и веб-разработке.
Продуктовые решения без A/B-тестов
В идеальном мире мы бы провели ряд A/B-тестов и выбрали решение, основанное на данных. Это помогло бы минимизировать риски и убедиться, что фича действительно работает. Если есть возможность, A/B-тесты стоит использовать, особенно для масштабных изменений.
Но такой опции на тот момент у нас просто не было. Один из самых простых вариантов — палец в небо, сделать на авось. Но такие решения зачастую слишком дорогие, потому что вероятность попасть прямо в цель крайне мала, а затраченное время разработки уже не вернёшь. Ниже — пошагово, как мы приняли решение, опираясь на аналитику и пользовательский голос:
1. Анализ обратной связи пользователей:
Пользователи торопятся и не хотят тратить время на фото (особенно если это не обязательно).
Пошаговый гид: многие просили чёткие инструкции, что и как фотографировать.
Прозрачность: клиенты хотели видеть, какие фото были сделаны, и иметь возможность переснять их, если что-то пошло не так.
2. Анализ существующих данных по фиче
У нас уже были данные по текущему процессу пост-осмотра — ключевая проблема в том, что не все пользователи осознают важность и доходят до финала. Нашей точкой отсчёта была ситуация, когда большинство клиентов пропускали этот этап.
3. Анализ конкурентов и трендов в индустрии
Мы изучили, как решают похожие проблемы конкуренты и компании из других отраслей, чтобы получить идеи для адаптации под наш продукт. Например, мы обратили внимание на тренд широкоугольных камер, который стал стандартом во многих сервисах. Это дало нам понимание, что стоит внедрить такую технологию и у нас.
Мы также посмотрели на решения конкурентов, и выяснилось, что только у одного из каршеринг-сервисов пост-осмотр является обязательным этапом для завершения аренды. Однако значительная часть фотографий, которые пользователи делают при обязательном осмотре — это не снимки авто, а просто асфальт или нога. Обязательность без мотивации не работает. Поэтому мы пошли другим путём: объяснить ценность, показать удобство. Без жёстких требований, но с чёткой пользой для всех.
Как мы искали идеальный пост-осмотр
Процесс разработки нового флоу был настоящим калейдоскопом идей, дебатов, проб и ошибок. С самого начала у нас было много разногласий. Команда убытков хотела, чтобы мы фотографировали “каждый сантиметр” автомобиля, а команда по работе с клиентами утверждала, что если мы сделаем фотографии обязательными — это вызовет недовольство пользователей и негативные отзывы. Главная задача была найти баланс — подсветить важность фотографий, но не сделать это обязаловкой.
Концепт 1
На первом этапе мы пробовали внедрить обязательный пост-осмотр с явно выделенным этапом в процессе аренды — но команда СХ сразу отмела этот вариант, так как это вызовет негатив у клиентов, и мы получим какие угодно фото, но не авто. Также на этом макете дизайн камеры «выпадал» из приложения.
Концепт 2
Вторая итерация — позволили сворачивать пост-осмотр. Угадайте, что делали пользователи? Правильно, сразу закрывали экран. Подсказки были туманными, реализация требовала трогать бэкенд, что автоматически отбрасывало нас на квартал назад.
Концепт 3
Третья версия открывала камеру сразу, без контекста. Пользователь не понимал, зачем она включилась. Минус в карму UX и плюс в копилку «фото асфальта». Но зато здесь впервые появилась идея: уточнить у пользователя, действительно ли он хочет пропустить фотоэтап. Это оказалось полезным.
Концепт 4
В четвёртой версии мы начали играть на важности — добавили акценты и больше говорили с пользователем. Но камера всё ещё казалась «чужой», инструкции — размытыми.
Концепт 5 — Финальный вариант
То самое «золотое сечение»:
можно загрузить до 10 фот и переснять их при необходимости,
чёткие подсказки и иллюстрации,
дважды подчёркиваем, зачем это нужно,
возможность пропустить с честным предупреждением: «На вашей ответственности».
После того, как прототипы были готовы, мы провели несколько раундов юзабилити-тестирования с реальными пользователями. Нам было важно понять, как воспринимается новый флоу, как пользователи реагируют и не раздражает ли их этот процесс.
Так как изменение масштабное, и мы не были уверены без теста в том, что эффект будет таким, какой мы ожидаем, пост-осмотр сначала появился у ios пользователей. После получения положительной обратной связи, решение вышло и на android.
Как мы сделали пост-осмотр, которым все довольны
Этот релиз стал случаем, когда довольны все: пользователи не чувствуют давления, команда убытков видит рост возвращаемости, служба поддержки — падение нагрузки и жалоб, и финансы, наконец, улыбаются. В цифрах это:
Увеличение возвращаемости убытков: до 52% за первый месяц.
Снижение жалоб: на 25% по сравнению с предыдущим периодом.
Доля заказов с пост-осмотром выросла с 45% до 94%. При этом доля заказов с успешным пост-осмотром (есть фото и/или тег) изменилась с 45% до 83% (x 1.8).
Новый флоу пост-осмотра стал важным шагом в улучшении пользовательского опыта и повышении эффективности работы команды урегулирования убытков. Главные выводы этого проекта:
Если нет A/B-теста — считай, что идёшь в тумане. Нужно полевыми тестами проверять, как поведёт себя пользователь. То, что кажется очевидным, может развалиться на первом же живом клике.
Раннее подключение разработчиков = экономия времени и денег. Благодаря их вовлечённости в проектирование мы смогли не трогать бэкенд и сократили минимум 2 месяца разработки.
Нельзя забывать, что бизнес-задача ≠ UX-задача. Можно сделать идеальное решение для бизнеса, которое обрушит пользовательскую лояльность. Или наоборот — сделать супер-лайтовый UX, но потерять десятки миллионов. Важно балансировать и постоянно сверяться с целью.
Цифры рулят. Самый важный момент проекта — построение финансовой модели: как донести до топ-менеджмента, что нам действительно нужен ресурс, и какие метрики изменятся. Сначала мы считали руками, на коленке, но это дало точку входа в обсуждение. Сейчас возвращаемость по некоторым кластерам уже приближается к 60%.
Этот кейс напомнил нам всем: даже без идеальных условий можно делать качественные продуктовые решения — если идти итерациями, быть ближе к пользователю и не бояться считать деньги.
