Кейс дополняется – скоро здесь появятся новые материалы
Дозаказ: как дать покупателю изменить заказ после оплаты
Сценарий дополнения активного заказа для сайта, мобильного веба и приложения «Ашан»
О проекте
«Ашан» – международная сеть гипермаркетов и один из крупнейших продуктовых ритейлеров в России. Онлайн для сети – уже не дополнительный канал, а заметная доля всего бизнеса: сайт auchan.ru, приложение «Мой АШАН», доставка из гипермаркетов, самовывоз и экспресс-доставка.
Продукт в масштабе
Публичные показатели «Ашан Ритейл Россия» за 2023 год и первое полугодие 2024
Контекст
«Ашан» – один из крупнейших продуктовых ритейлеров России с интернет-магазином и мобильными приложениями. Онлайн-заказ продуктов устроен жёстко: покупатель собирает корзину, выбирает слот доставки, оплачивает, после чего заказ уходит на сборку в магазин.
Между оплатой и началом сборки есть окно, в котором заказ уже создан, но физически с ним ещё ничего не происходит. Именно в это окно покупатель чаще всего вспоминает, что забыл молоко.
Бизнес-вызов
Задача пришла от бизнеса: от продакт-менеджеров «Ашана» и руководителя направления. У неё было три источника:
Поддержка
Регулярные обращения «добавьте товар в мой заказ», которые оператор не мог решить
Отмены и перезаказы
Покупатели отменяли оплаченный заказ и собирали его заново ради пары забытых позиций
Недополученная выручка
Забытые товары покупались в другом месте или не покупались вовсе
| Было | Стало |
|---|---|
| Заказ после оплаты нельзя изменить | Заказ можно дополнить, пока его не начали собирать |
| Забыл товар → отмена и повторное оформление | Забыл товар → добавил в тот же заказ и тот же слот доставки |
| Вопрос решается через поддержку | Вопрос решается самостоятельно за минуту |
| Страница «Спасибо за заказ» – тупик | Страница «Спасибо за заказ» – точка допродажи |
Как было
Цели и метрики
| Бизнес-цель | Продуктовая метрика |
|---|---|
| Больше выручки с заказа | Средний чек, доля заказов с дозаказом |
| Меньше потерянных заказов | Доля отмен до начала сборки |
| Меньше «досылочных» заказов | Доля повторных заказов в течение 2 часов после первого |
| Меньше нагрузки на поддержку | Обращения по теме «изменить состав заказа» |
Задачи
- Спроектировать новый пользовательский путь дозаказа товаров
- Показать все экраны и состояния, необходимые для понимания функции
- Адаптировать решение для сайта, мобильного веба и мобильного приложения
- Уложиться в существующие правила брендбука и UI-кита «Ашана»
Моя роль и команда
Я был Senior / Lead внешней дизайн-команды студии aic. У «Ашана» была полноценная продуктовая команда, но без собственных дизайнеров, поэтому дизайн-экспертиза и ответственность за решение были на нашей стороне.
- Разбор задачи с продактами и перевод бизнес-цели в сценарий
- Проектирование логики и user flow дозаказа
- Ключевые экраны для трёх платформ
- Декомпозиция задач и ревью двух middle-дизайнеров
- Защита решений перед продактами и руководителем направления
- Проработка ограничений с разработкой и handoff
| aic | «Ашан» |
|---|---|
| Senior Product Designer / Lead (я) 2 Middle Designers Project Manager | Product Managers Руководитель направления Аналитика Frontend, backend и мобильная разработка |
Ограничения
Дозаказ упирается не в интерфейс, а в операционку: склад, сборщиков, курьеров и платёжный контур. Эти ограничения мы получили от бизнеса и разработки, и они определили почти все дизайн-решения.
| Ограничение | Что это значило для интерфейса |
|---|---|
| Дозаказ возможен только до начала сборки | Сценарий привязан к статусу «Ожидает сборки» и должен корректно прерываться при переходе заказа в статус «Собираем» |
| Не более 10 позиций в одном дозаказе | Нужен постоянно видимый счётчик «добавлено N / 10» |
| Лимит по весу: заказ целиком не тяжелее 65 кг | Условие нужно объяснить до начала выбора, а не ошибкой в конце |
| Слот и адрес доставки не меняются | Дозаказ не проходит через чекаут повторно |
| Два способа оплаты с разной механикой | Финальный шаг различается для онлайн- и офлайн-оплаты |
| Не каждый товар можно дозаказать | Нужно состояние «Товар недоступен для дозаказа» с предложением похожего товара |
| Брендбук и UI-кит «Ашана» менять нельзя | Новые элементы собираются из существующих компонентов и паттернов |
Ключевое решение: дозаказ как режим магазина
Главный вопрос был в том, где покупатель выбирает товары для дозаказа.
| Вариант | Плюсы | Почему не выбрали |
|---|---|---|
| Отдельный экран с подборкой товаров | Быстро в разработке | Покупатель ограничен рекомендациями и не находит то, что забыл |
| Обычная корзина с пометкой «в заказ» | Знакомый паттерн | Смешивает новый заказ и дозаказ, неясно, куда уйдёт товар |
| Режим дозаказа поверх всего каталога | Доступен весь ассортимент, привычные карточки и поиск | Выбран: сложнее в реализации, но не ограничивает покупателя |
User flow
В Figma флоу собран отдельно для каждой из трёх точек входа и каждой платформы: всего 9 веток, в каждой – каталог, добавление товаров, три попапа-исключения, страница дозаказа и обновлённый заказ.
#1. Точки входа
Дозаказ должен встретиться покупателю там, где он вспоминает о забытом товаре, а не там, где нам удобно его разместить.
Мы выделили три момента и дали вход в каждом из них. Везде условие дозаказа сформулировано одинаково и показано до клика: сколько позиций можно добавить, какой лимит по весу и до какого момента.
Спасибо за заказ
Самый горячий момент: покупатель только что оплатил и ещё держит в голове список. Рядом с информацией о заказе появился блок «Забыли что-то купить?»: информер с условиями, слайдер рекомендаций на основе товаров в заказе и переход в каталог. В мобильном приложении экран короче, поэтому там остались только информер и кнопка «Перейти в каталог».
Мои заказы
Сюда покупатель возвращается позже, когда вспомнил о товаре. В карточке заказа со статусом «Ожидает сборки» появилась кнопка «Дополнить заказ». На десктопе она открывает попап с рекомендациями для быстрого добавления, на мобильных сразу ведёт в каталог.
Детальная страница заказа
Третья точка – для тех, кто пришёл проверить статус. Кнопка стоит в блоке «Итого» рядом с суммой, потому что дозаказ эту сумму меняет.
#2. Модуль дозаказа
Постоянный спутник покупателя в каталоге, который отвечает на три вопроса: к какому заказу я добавляю, сколько ещё можно и сколько это стоит.
Из любой точки входа покупатель попадает на нулевой уровень каталога, где уже включён режим дозаказа, и дальше ходит по разделам как обычно. На десктопе модуль закреплён плавающей плашкой в углу экрана, в мобильном вебе и приложении встроен над панелью навигации на месте, где обычно живёт корзина.
Что показывает модуль
- Номер и статус заказа
- Счётчик позиций «N / 10»
- Сумму дозаказа
- Действие «Дополнить заказ»
Почему так
- Покупатель не путает дозаказ с новой корзиной
- Лимит виден до того, как в него упираешься
- Нет сюрприза в сумме на финальном шаге
- Завершить можно с любой страницы
Карточки товаров работают так же, как в обычном каталоге: «В корзину», затем степпер количества. Меняется только адресат: товар уходит не в корзину, а в дозаказ.
Если товар сейчас нельзя дозаказать, покупатель видит попап «Данный товар недоступен для дозаказа» прямо в каталоге. Вместо тупика попап предлагает похожий товар, который можно добавить сразу, а уже выбранное не теряется.
#3. Подтверждение и оплата
Перед подтверждением покупатель видит исходный заказ и добавленные товары на одном экране.
Страница «Дополнение заказа» собрана по логике корзины: сверху исходный заказ со слотом доставки, ниже добавленные позиции с возможностью изменить количество, удалить товар или очистить весь дозаказ, справа итог с весом и суммой дозаказа. Кнопка «Назад» возвращает на ту страницу каталога, где покупатель был, чтобы можно было докинуть ещё что-то.
Самая сложная часть – деньги. Механика зависит от способа оплаты исходного заказа.
| Способ оплаты | Что происходит | Что видит покупатель |
|---|---|---|
| При получении | Итоговая сумма заказа пересчитывается | Новую сумму в заказе, оплата при получении как обычно |
| Онлайн | Обновлённая сумма предсписывается, после сборки делается возврат и списывается фактическая стоимость | Страницу оплаты с понятной суммой, затем обновлённый заказ |
После подтверждения покупатель возвращается в «Мои заказы» и видит тот же заказ с добавленными товарами и новой суммой.
#4. Выход и пограничные случаи
Дозаказ живёт внутри чужого процесса и может закончиться не по воле покупателя.
| Ситуация | Решение |
|---|---|
| Покупатель передумал | Выход по кнопке с подтверждением «Прекратить дозаказ?». При отмене покупатель продолжает выбор, при подтверждении товары удаляются и он возвращается в «Мои заказы» |
| Заказ перешёл в статус «Собираем», пока покупатель выбирал | Попап «Невозможно дополнить заказ» (в мобильных – «Время на дозаказ вышло»). Выбранные товары предлагается перенести в корзину и оформить новым заказом |
| Покупатель пришёл дополнить заказ, который уже собирают | Кнопки дозаказа нет, предлагается оформить новый заказ |
| Товар нельзя добавить в дозаказ | Попап «Товар недоступен для дозаказа» с похожим товаром, выбор продолжается |
Когда заказ уже начали собирать, попап объясняет причину и сразу даёт два выхода: «Перенести в корзину» для нового заказа или «Выйти из дозаказа».
Три платформы – одна логика
Сценарий проектировался одновременно для десктопа, мобильного веба и приложения. Логика, тексты и состояния едины, отличается только то, как модуль встроен в навигацию.
| Элемент | Desktop | Mobile Web / App |
|---|---|---|
| Модуль дозаказа | Плавающая плашка в углу экрана | Блок над панелью навигации |
| Быстрое добавление | Попап с рекомендациями | Прямой переход в каталог |
| Подтверждение выхода | Модальное окно | Bottom sheet |
| «Спасибо за заказ» | Информер, слайдер рекомендаций, переход в каталог | Адаптив – как десктоп, приложение – только информер и переход в каталог |
По условиям задачи решение нужно было уложить в существующий брендбук и UI-кит «Ашана». Новыми стали только компоненты самого сценария: модуль дозаказа, модальное окно с рекомендациями и три попапа-исключения. Всё остальное собрано из готовых карточек, кнопок и информеров.
Валидация и ожидаемый результат
Как проверяли решение
До разработки сценарий прошёл внутренние UX-ревью с продактами и разработкой и проверку на кликабельном прототипе. Количественные результаты после запуска мне недоступны: измерения вела команда «Ашана» уже после передачи макетов. Ниже план проверки, который я закладывал в решение.
| Этап | Что проверяем | Как |
|---|---|---|
| До разработки | Понимают ли покупатели, что товар уйдёт в текущий заказ, и видят ли лимиты | Модерируемые тесты прототипа на 5–7 респондентах для каждой платформы |
| Запуск | Влияние на чек, отмены и операционку | A/B-тест 50 / 50 на 3–4 недели с поэтапной раскаткой по регионам |
| После запуска | Какая точка входа работает лучше и где покупатели бросают сценарий | Воронка по событиям: вход → добавление → просмотр → подтверждение |
Чего ожидала команда
Целевые ориентиры по оценке команды на этапе проектирования, а не измеренные результаты.
Стейкхолдеры и разработка
Финальные решения принимали продакт-менеджеры и руководитель направления «Ашана», а дизайн-экспертиза была на стороне студии. Это требовало аргументировать каждое решение через задачу бизнеса, а не через вкус.
- Показывал варианты с плюсами и ценой реализации, а не один «правильный» дизайн
- Каждое ограничение склада и оплаты сначала проговаривал с разработкой, потом рисовал
- Проектировал граничные случаи вместе с основным сценарием, а не после него
Процесс: бриф от продактов → сценарий и ограничения → варианты → ревью → макеты для трёх платформ → handoff → дизайн-поддержка разработки
В handoff вошли состояния модуля, тексты условий, правила для каждого статуса заказа и аннотации к веткам оплаты.
Что я бы сделал иначе
Метрики на старте
Заранее договорился бы с командой клиента о доступе к результатам после запуска, чтобы видеть эффект решения, а не только макеты.
Тесты раньше
Проверил бы на прототипе главный риск – путаницу дозаказа и новой корзины – до детальной проработки трёх платформ.
Шире окно дозаказа
Проработал бы с операционной командой дозаказ на этапе сборки для товаров из уже пройденных зон магазина.