Как мы перезапустили автомобильный стартап после неудачной первой версии

Как перезапустить стартап после неудачной первой версии?

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

Что мы решили менять при перезапуске стартапа?

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

Почему мы начали с сокращения пути клиента?

В ранней версии даже авторизация могла сопровождаться несколькими подтверждениями: условиями, политикой конфиденциальности, договорными документами. Количество промежуточных действий сократили и приблизили пользователя к задаче «проверить автомобиль». Параллельно кабинет сделали информативнее: добавили элементы mini-dashboard, статусы и быстрый доступ к основным действиям.

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

Почему регистрацию эксперта пришлось менять отдельно?

«Рулизор» — двухсторонняя платформа, и специалист приходит с другой задачей. Раньше он мог сразу получить большую анкету: контакты, профессиональный статус, банковские реквизиты и данные для расчётов.

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

Это progressive disclosure: сложность показывается постепенно. После регистрации усилили onboarding — специалисту сразу объясняется, где заявки, как начать работу и где открыть отчёт. Здесь важен time to value: время до первой понятной пользы, а не до красивого экрана приветствия.

Почему интерфейс автоэксперта нельзя проектировать только за столом?

Эксперт работает на парковке или в сервисе: держит смартфон, толщиномер, сканер, фонарь, фотографирует и разговаривает с продавцом. Каждый лишний переход конкурирует за внимание с автомобилем.

Почему форму отчёта пришлось строить вокруг машины?

Ранняя форма была ближе к структуре хранения данных. Машина, к сожалению, структуру нашей базы не читала.

Эксперт естественно движется вокруг кузова: крыло → дверь → соседний элемент → следующий участок. Если интерфейс отправляет его от левого крыла к правой двери, затем к багажнику и снова вперёд, специалист начинает физически ходить за формой.

Последовательность перестроили под реальный маршрут осмотра. Там, где не нужен длинный комментарий, появились быстрые отметки и переключатели: проверил → зафиксировал → пошёл дальше. Стандартизация не заменяет мнение специалиста — она убирает лишнюю ручную работу.

Почему фотографии и автосохранение оказались важнее красивых функций?

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

Вторая незаметная вещь — сохранение отчёта. Осмотр легко прервать звонком, плохим интернетом или переходом в другое приложение. Если после этого данные пропадают, цифровой сервис создаёт новую проблему. Поэтому введённую информацию можно сохранить и продолжить работу позже.

Почему структурированный отчёт стал центральной частью продукта?

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

Цифровой отчёт связывает раздел автомобиля, наблюдение, фотографию и комментарий. В публичном описании Rulizor специалист фиксирует фото, комментарии и результаты диагностики, а система формирует цифровой отчёт.

Покупателю недостаточно перечня дефектов: нужна интерпретация — возрастная мелочь, повод для торга или причина отказаться. Поэтому итоговое заключение остаётся профессиональной частью продукта.

Почему перезапуск затронул организацию услуги?

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

Это продуктовая модель, а не юридическое распределение ответственности.

Почему двухсторонний стартап сложнее обычного приложения?

Потому что в нём, как с старом анекдоте, минимум «два путя». Клиенту нужно легко заказать и понять результат. Эксперту — легко подключиться, принять заявку, провести осмотр и оформить его.

Если удобно только одной стороне, платформа всё равно страдает. Поэтому менялись обе цепочки.

Что конкретно изменилось?

Как выглядел путь до и после?

Клиент раньше: вход → подтверждения → кабинет → поиск действия → заказ → результат.

После: вход → понятное действие → заказ → статус → структурированный результат.

Эксперт раньше: регистрация → большой объём данных → поиск следующего шага → сложная форма.

После: минимум данных на старте → onboarding → заказ → последовательный осмотр → сохранённый отчёт.

Это упрощённая продуктовая схема, а не буквальное описание каждого экрана.

Почему мы не стали просто добавлять функции?

Потому что новая вкладка не исправляет старый длинный маршрут. Иногда лучший релиз — не +10 возможностей, а −10 лишних действий.

Важно понимать простой контраргумент: команда может улучшать onboarding, а затем выяснить, что главный барьер лежит в процессе покупки. Хорошая картинка сама по себе не доказывает состояние удовлетворённости рынка.

Что мы сознательно не стали автоматизировать?

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

Платформа полезнее в организации, фиксации, хранении и передаче результата. Короткая формула: автоматизировать не профессию, а трение вокруг профессии.

Что из опыта Rulizor можно использовать в другом стартапе?

1. Рисуйте путь до ценности, а не список экранов.

2. Проверяйте, зачем обязательное поле нужно именно сейчас.

3. Разделяйте данные «для регистрации» и «для дальнейшей работы».

4. Наблюдайте за пользователем в реальной среде.

5. Сверяйте порядок интерфейса с реальным порядком действий.

6. Проверяйте прерывания: звонок, интернет, закрытая вкладка.

7. Оптимизируйте тяжёлые операции — фото, документы, видео.

8. После регистрации отвечайте на вопрос «что дальше?».

9. Не путайте массив данных с понятным результатом.

10. Перед новой функцией попробуйте убрать одно лишнее действие.

Что мы бы проверили дальше?

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

Перезапуск продукта не заканчивает продуктовую работу.

Почему первая версия всё равно была нужна?

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

Так предположения превращаются в наблюдаемые сценарии.

Почему хороший интерфейс ещё не означает успешный бизнес?

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

Перезапуск лишь убрал ряд очевидных барьеров и улучшил базу для следующей проверки гипотезы.

Коротко о важном:

· Первая версия проверяет гипотезы, а не завершает продукт.

· Работающая функция может быть неудобной.

· Путь нужно строить от задачи пользователя.

· Данные следует спрашивать тогда, когда они нужны.

· После регистрации должен быть очевиден следующий шаг.

· Professional UX обязан учитывать реальную среду работы.

· HEIC и автосохранение — полноценные UX-вопросы.

· Структурированный отчёт связывает экспертизу и решение клиента.

· У платформы минимум два пользовательских пути.

· Хороший перезапуск сначала убирает лишнее.

FAQ

Что значит перезапустить стартап?

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

Нужно ли переписывать продукт с нуля?

Нет. Иногда эффективнее последовательно переделать критические участки пути.

Какие функции переделывать первыми?

Те, которые стоят между пользователем и основной ценностью: регистрация, первый шаг, главное действие и результат.

Зачем упрощать интерфейс профессионалу?

Чтобы его внимание уходило на профессиональную работу, а не на обслуживание программы.

Можно ли считать текущую модель Rulizor окончательной версией?

Нет. Digital-продукт продолжает развиваться. Новая версия — очередная итерация, а не финальная точка.

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

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