Оформление заказа: как убрать тупики между корзиной и оплатой

Сначала нарисуйте путь одного заказа

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

Запишите состояние на каждом шаге: что уже известно и какое решение предстоит. Где определяется доступность доставки? Когда резервируется товар? Что произойдёт, если человек уйдёт в банковское приложение и вернётся назад? Эти вопросы нужно согласовать с разработчиком и платёжным провайдером. Не обязательно показывать покупателю все внутренние состояния, но команда должна понимать, как заказ проходит через них и где возникает ошибка.

Состав заказа должен оставаться перед глазами

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

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

Не скрывайте стоимость доставки

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

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

Собирайте данные под выбранный способ получения

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

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

Разделите оплату и подтверждение её результата

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

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

Проверяйте ошибки так же внимательно, как покупку

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

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

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

Что проверить в своей задаче

1. Выбранные варианты товара видны на всех шагах.
2. Доставка и итоговая сумма понятны до подтверждения.
3. Возврат назад не уничтожает заполненные данные без причины.
4. Проверены отказ оплаты, повторное уведомление и потеря сети.
5. Покупатель и менеджер видят согласованный статус заказа.