
CarVoid — сервис поиска автосервисов и квалифицированных механиков для обслуживания автомобиля
AutoTech O2O Platform
Компания
Систем-Групп
Роль
Продуктовый дизайнер
UX\UI
Время реализации мной
6 месяцев
Дата
Март 2024 - Сент 2024
CarVoid — заказ от аутсорс-компании «Систем-Групп» по созданию платформы для поиска автосервисов и механиков. Нужно было сделать: веб-сайт, мобильное приложение и админ-панель для управления
моя роль
— Активные созвоны с заказчиками, проведение интервью и брифингов
— Сбор документации продукта и сегментирование функционала для итераций с определённым приоритетом
— Презентация и защита решений перед заказчиками
— Координация работы фронта и дизайна, отчёты по выполненным таскам и блокерам
— Проведение ревью дизайна и реализованного функционала
проблемы
— Сначала заказчики хотели логику продукта, как у одного конкурента, но мы были против данного решения по простой причине: тот продукт был локальным внутри компании, а цель заказчиков — объединить разные мелкие, средние и, может быть, даже большие автосервисы в одну платформу и упростить их поиск
— Ролевая система и функционал, зависящий от неё: Автосервис и Клиент
— Заказчики хотели сначала только веб-версию, что было спорным решением по причине логики поиска человеком автосервиса
— Команда была небольшой, да и бюджет не небесный, хотя для такого проекта нужно больше ресурсов, поэтому были моменты упрощения и частых обсуждений, чтобы прийти к золотой середине бюджета и возможностей разработки
— Параллельное проектирование мобилки и веба создавало проблемы, так как приходилось думать сразу на три фронта: веб, адаптив и мобилка
задачи
— Провести исследование и изучить опыт конкурентов, собрать артефакты и оформить файл
— Собрать график приоритетов, user flow, use case, CJM и многое другое
— Обеспечить инклюзивность и доступность
— Создать библиотеку компонентов (а не дизайн-систему) в угоду простоте и скорости
— Проводить регулярные созвоны с заказчиками и командой для отслеживания статусов и выявления блокеров
— Проводить ревью дизайна и фронта
отзвук от юзера и заказчика
У продукта не было прямых конкурентов на рынке Беларуси, а были лишь косвенные. Также не было базы пользователей, которая могла бы упростить нам этап исследований и интервью
Автосервисы часто нужны в самый неподходящий момент, поэтому хотелось бы видеть лучших из лучших в списке, чтобы не попасть на халтурщиков
Поиск автосервисов — это основная функция, но также можно было бы пойти в сторону всех услуг для машин: продажа и покупка авто, автомойки, эвакуатор и многое другое
Хотелось бы знать статус своей машины без звонков, смс или переписок: просто открыл приложение, а тебе сказано — «Не готово, подождите немного»
Если сервис сложно найти или дело не требует спешки, то было бы удобно просто кинуть заявку в общую группу: там её будут смотреть автосервисы и уже откликаться

после брифа и исследования стало ясно
документация и артефакты
Для документации и артефактов был подготовлен файл в FigJam: там были референсы, анализ конкурентов, метрики и пирамида метрик, карты Мобилки и Веба, гипотезы и итерации






главные функции продукта
главная страница
Поиск, поиск, поиск и щепотка рекомендаций — вот основная цель всей главной страницы Веба и Мобилки: Фронт убедил перевести основной упор в сторону Мобилки и работы с геолокацией, чтобы мы могли выдавать более релевантные и нужные данные
главная страница веба
Главную страницу решено было делать не полностью по принципу маркетплейсов (Главный экран — Умный поиск — Подставление фильтрации): здесь Фронт пошёл по пути разделения на первичные фильтры (самые часто используемые), вторичные (то, что настраивается после поиска) и умный поиск, который ищет по названию услуги, названию Автосервиса, по марке автомобиля и по описанию

главная страница мобилки
Мобилка сильно отличалась от Веба не по функционалу, а скорее по философии и цели каждой страницы: если в Вебе необходимо сделать акцент на поиске, быстрых фильтрах, рекомендациях и быстрых вопросах (при этом сам поиск уходил на второй план), то Мобилка — совсем другой вопрос
Исследования показали, что нашему продукту ближе классифайды (маркетплейсы, поиск услуг и работы), поэтому главная страница Мобилки действует всего в двух направлениях:
Поиск — самая важная часть функционала, пока у Пользователя не появятся избранные сервисы, механики и не пройдёт большое количество времени активного использования продукта
Рекомендации Автосервисов — список на главной должен смотреть не только на прошлые поиски, но и на то, в какие Автосервисы Пользователь заходил и где задерживался, с кем переписывался и есть ли у него Автомобиль внутри платформы. Одно из самых важных здесь — «Геолокация»: все рекомендации основаны не просто на персонализации под Пользователя и его предпочтения, а именно на персонализации под нужду Пользователя

Карта и поиск по карте
Одной из функций, которую хотели Заказчики, но которая по данным исследований не имела сверхбольшого успеха, стал поиск по карте: это, грубо говоря, тот же главный экран, но вместо списка идут точки на карте
Основные аргументы «За»
Поиск на главной удобен, но найти ближайший Автосервис сложнее: бывают базовые поломки, которые устранит большинство мастеров, и здесь есть нюанс быстрого поиска, где фактор времени становится решающим.
Простое сравнение: хорошо сделанная карта и данные, всплывающие при нажатии, позволяют сравнить Автосервисы между собой гораздо быстрее, чем в обычных условиях текстового списка.
Географическая гибкость: работа рекомендаций может быть удобна для Пользователя, который ищет услуги только «под себя» в привычной локации. Однако в случае поиска в другом районе это нужно долго указывать через фильтрацию — а на карте достаточно просто «найти пальцем» нужный район, и вы сразу видите все доступные Автосервисы там.
Основные аргументы «Против»
Информационный шум: В Мобилке он возникает из-за двух разных способов входа в основной сценарий. При этом у классического поиска больше успешных кейсов и более качественные данные, чем у варианта с картой.
Сложность сравнения: Для сравнения Автосервисов заметно отсутствие «быстрых» данных. При обычном поиске Пользователь сразу видит множество базовых параметров, которые помогают принять решение, и считывается это проще. На карте же нужно кликать и вчитываться в каждую точку, то есть вниманию доступен только один Автосервис за раз. В связи с этим нужно придумывать сложную логику подсветки более выгодных и качественных предложений без использования накрученных данных.
Затраты: Карта, особенно качественно функционирующая, — вещь недешевая и может быть нестабильной. Необходимо постоянно обеспечивать актуальность этих данных, что гораздо труднее реализовать при опоре на логику внешних продуктов, таких как 2ГИС или Яндекс Карты.


своя машина
Заказчики хотели иметь возможность доступа к данным об Автомобиле — истории регистраций, авариях, участии в аукционах, количестве владельцев, нахождении в розыске и т. п. Однако реализация подобного решения требовала значительных усилий, времени и, самое главное, средств. Поэтому в первой итерации функционал отличался от изначальной идеи.
Как хотели:
История Автомобиля на платформе обладала логикой сервисной книжки
Получение доступа к данным Автомобиля на платной основе, по аналогии с проверкой по VIN-коду и госномеру
Можно было сформировать документ с сервисными работами, которые проводились
Проверка Автомобилей на статус угона и другие критические параметры
Можно было не просто поделиться историей работ по Автомобилю с другим Пользователем, но и при продаже передать права на Автомобиль, чтобы сервисная книжка продолжалась
Интеграция со страховыми компаниями для обработки логики сервисных книжек и работы с Автосервисами
Чтобы автомобиль не добавлялся «из воздуха», вводятся параметры и соблюдается логика реального автомобиля: это не позволит создать профиль и вести книжку для фейкового Автомобиля
К чему пришли:
Логика истории, формирования документа и возможности «поделиться» осталась, но была упрощена и не могла стать полноценной сервисной книжкой
Проверки Автомобилей и их статусов можно было бы сделать отдельной услугой, но не частью системы Автосервисов, поэтому их решено было убрать
Интеграция с кем-либо внешним, кроме Автосервисов, на первой итерации была отметена сразу из-за времени и средств, которые могли понадобиться
Прописана логика подтверждения Автомобиля: мы оставили ввод VIN-кода и госномера для верификации через Автосервис


чат и заявки
Основные способы взаимодействия на платформе:
Чат — дает возможность быстро написать сообщение и получить ответ. Реализована поддержка вложений, чтобы Пользователь мог прикрепить необходимые документы, файлы и фотографии поломок.
Заявка — формат отправки Автосервису готовых данных об Автомобиле. Это позволяет оперативно закрыть основные вопросы по ремонту без лишних уточнений. В дальнейшем данный функционал должен стать частью системы «Аукциона».
Звонок — прямой способ связи, который доступен в том случае, если Автосервис активировал эту возможность в своем профиле.
Основная цель такого решения — удерживать клиентов внутри платформы как можно дольше и закрывать все их потребности, не блокируя при этом возможность выбрать другой путь. Для Автосервисов также предусмотрен функционал, дающий преимущества при взаимодействии внутри платформы.


админка, профиль автосервиса и клиента
Одной из самых сложных задач стала панель управления или личный кабинет: после проработки логики выяснилось, что даже с MVP-функционалом разработка требует огромного количества времени и средств. Изначально предлагалось использовать готовый шаблон панели управления для обеих сторон, но я выступил против этого подхода: если для бизнеса такая логика приемлема, то для обычного Пользователя подобный интерфейс выглядит избыточным и странным
В итоге мы пришли к решению делать полноценные кабинеты, расставив приоритеты: сначала обновляем профиль для простого Пользователя, а затем — для Автосервисов
Админка:
Управление Автосервисами и компаниями в целом
Логика банов и модерации
Система логов и жалоб
Поддержка Пользователей со статусами и заявками
Подтверждение данных Автосервиса и клиента
Подключение платных продвижений и услуг
Управление рекламой и выдачей в поиске и фильтрации
Профиль автосервиса:
История заявок, выполненных работ и база визитов Автомобилей
Аналитика и отчетность для понимания роста или спада бизнеса
Управление командой и Автосервисами
Создание Автосервисов, добавление сотрудников и акций
Страница активных заявок с динамической сменой данных и статусов
Продвижение и тарификация Автосервиса, компании и аккаунта в целом
Аукцион заказов: механика перехода Заявок при длительном ожидании отклика
Профиль клиента:
Избранные Автосервисы
Создание профиля Автомобиля с цифровой сервисной книжкой платформы
История оказанных услуг
Передача профиля Автомобиля другому пользователю с сохранением всей истории работ
В первой итерации моей задачей был сбор черновых экранов из готовых шаблонов, поэтому они выглядят как макеты среднего уровня проработки
Я был против того, чтобы мобильное приложение было недоработано так же, как веб-версия. Поэтому мы решили ограничить второстепенный функционал, чтобы сфокусироваться на качественной проработке личного кабинета, причём на данном этапе — только для Пользователя. Мы двигались в рамках четкой парадигмы:
Пользователь использует смартфон
Автосервис — в основном ноутбук, но мы учитывали, что в условиях СТО (из-за специфики работы с грязью и химическими веществами) удобнее использовать мобильные устройства. Поэтому в приоритеты была записана задача разработать в дальнейшем мобильное решение и для Автосервисов

что не вошло в фукционал, но было в планах
Для продукта, что был на этапе разработки и был ограничен по ресурсам и времени, нормально было частичное или полное удаление функционала с финального вида, которые потом закладывались на следующие итерации
Список функицонала не вошедший в итоговую сборку:
Аукцион заказов не был полностью доработан в первой итерации, поэтому функционал был временно скрыт. Механика аукциона проста: если Пользователь не хочет искать Автосервис вручную или столкнулся со специфической проблемой, он создаёт запрос с подробным описанием. Все Автосервисы видят этот запрос и предлагают свои условия — стоимость и сроки. Пользователь сравнивает ответы и выбирает наиболее подходящий вариант
Админ-панель управления и профиль Автосервиса: ускоренная разработка на базе шаблонов
Цифровая Сервисная книжка: история обслуживания внутри экосистемы
Монетизация и инструменты платного продвижения: концепция и тарифная сетка были полностью проработаны, однако в первой итерации мы решили отложить их запуск. Основной приоритет был отдан проверке гипотез и подтверждению жизнеспособности продукта (Product-Market Fit) на рынке перед введением платных сервисов
Рекламные интеграции в первой итерации были исключены в пользу визуальной чистоты интерфейса, хотя все технические решения для их запуска уже полностью подготовлены
Интеграция смежных транспортных услуг: отказ от модели «супераппа» в пользу узкого фокуса
Система безопасных платежей и онлайн-оплата
Специализированное мобильное приложение для механиков
Прямая интеграция с каталогами запчастей и маркетплейсами
Фото- и видеофиксация процесса ремонта в реальном времени
мои мысли по поводу CarVoid
CarVoid — один из моих первых продуктов, созданных самостоятельно в составе довольно большой на тот момент команды. Я не во всём согласен с решениями заказчиков и со своими собственными дизайн-решениями того периода, но главной ценностью продукта была его невероятная масштабируемость, что подтверждает текущий 2026 год. Сфера транспорта и сопутствующих услуг актуальна и продолжает активно развиваться: купля-продажа Автомобилей, Автосервисы, тематические блоги и многое другое
Мне жаль, что заказчики решили закрыть проект, не разглядев в нём потенциала и положительного эффекта. Несмотря на то что не все договоренные деньги мы получили, сам проект мне понравился. Хотя сейчас я смотрю на те макеты, и мне хочется закрыть лицо рукой от стыда :). Когда-нибудь я бы хотел вернуться к этому проекту и сделать редизайн чисто для души
P.S. проект вышел сложным из-за активной смены команды… Мы поменяли одни Бэк-разработчиков раза 6






