Управление дизайном в Достависте и Borzo

Около 95% заказов были срочными: пользователям нужно было, чтобы курьер забрал заказ как можно быстрее. Но форма была построена вокруг ручного выбора времени для каждого адреса.

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

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

После запуска мы заметили, что часть пользователей всё равно выбирала «Запланировать» для срочных заказов. Из интервью выяснили, что ручной выбор времени давал им ощущение контроля. Это привело нас к следующей идее – показывать предсказание времени, чтобы простой сценарий тоже давал пользователю уверенность.

Дальше продукт стал сложнее: появились суперсрочная доставка, более медленные и дешёвые варианты и доставка к определённому времени. Форма должна была уже не только помогать оформить заказ, но и знакомить пользователя с новыми продуктами.

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

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

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

Последняя большая трансформация была для Индии, где у нас было намного больше типов транспорта: мопеды, рикши, несколько видов грузовиков – и для каждого ещё разные скорости доставки.

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

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

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

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

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

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

Мы объединили две задачи и превратили онбординг в персонализированный квиз. Пользователь за несколько действий рассказывал, что и сколько он доставляет, и сразу видел релевантные возможности сервиса. Например, для документов – ожидание и возврат, для крупных грузов – погрузку и разгрузку. Таким образом, квиз одновременно давал пользователю быстрый ответ на вопрос «подходит ли продукт именно мне? », а нам – раннюю сегментацию клиента.

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

В A/B‑тесте конверсия из установки приложения в первый заказ выросла на 8% по сравнению с прежней версией. Позже это подтвердилось и качественно: в исследованиях некоторые клиенты вспоминали, что в онбординге выбрали свой тип бизнеса и увидели релевантную для него информацию. При этом около 35% пользователей пропускали онбординг, поэтому часть данных мы всё равно собирали позже. Это оставалось ограничением решения.