В магазине интерфейс, товарные данные и обработка заказа работают вместе. Мы разбираем путь от поиска нужного варианта до подтверждения покупки, включая отсутствие товара и ошибки оплаты.
Начинаем с товарной модели
Определяем категории, варианты, атрибуты и идентификаторы товаров. Без согласованной структуры данных фильтры и карточки быстро начинают показывать противоречивые сведения.
Отдельно описываем цены и наличие. Источник обновления должен быть понятен команде, иначе интерфейс не сможет надёжно отражать состояние ассортимента.
Товарную модель описываем до экранов каталога: основной товар, варианты, комплектация, остаток, цена и доступная доставка. Проверяем, какие сведения приходят из учётной системы и кто исправляет расхождения. Вариант товара должен оставаться узнаваемым от списка до оплаченного заказа. Если одинаковый товар поступает от разных поставщиков, сохраняем различия гарантии и комплектации, не объединяя предложения только по похожему названию.
Навигацию строим по способу выбора, привычному покупателю. Фильтры должны опираться на заполненные атрибуты и объяснять, почему подходящих результатов нет.
Помогаем найти вариант
Проверяем поиск по названию, характеристике и распространённой ошибке ввода. Нулевой результат должен помогать продолжить выбор, а не превращаться в тупик.
Для поиска и фильтров берём реальные покупательские задачи: совместимость, размер, назначение и доступность. Проверяем сочетание фильтров без результатов, сброс выбора и возврат из карточки. Количество доступных параметров не компенсирует названия, которые понятны поставщику, но непонятны покупателю. В выдаче проверяем видимость выбранного варианта: фильтр по размеру не должен показывать товар так, будто любой его вариант сейчас доступен.
Покупателю нужны отличия вариантов, комплектация и существенные условия получения. Декоративное описание не заменяет характеристик, которые влияют на совместимость или использование.
Изображения и подписи связываем с выбранным вариантом. Если наличие или цена меняются после выбора, интерфейс должен явно показать новое состояние.
Раскрываем условия в карточке
Допустим, клиент выбирает обувь определённого размера, видит цену, но после перехода в корзину получает другой вариант. Сопоставляем идентификатор предложения, выбранный размер и строку заказа. Исправление текста не решит проблему, если интерфейс передаёт базовый товар вместо конкретной модификации. В условном заказе идентификатор размера сохраняется и в платёжном описании, и в задании сборщику; совпадения картинки товара для проверки недостаточно.
Проверяем последовательность адреса, способа получения и оплаты. Не просим сведения до того, как понятно, зачем они нужны для выбранного сценария.
Ошибки отображаем рядом с действием и сохраняем корректно введённые данные. Повторное нажатие не должно безусловно создавать ещё один заказ.
На оформлении заказа проверяем расчёт доставки, адрес, скидку и доступные способы оплаты. Пользователь должен видеть итоговую сумму до подтверждения. При изменении состава корзины пересчитываем связанные условия, не сохраняя прежнее обещание доставки для уже недоступного набора товаров. При изменении адреса после выбора доставки повторно проверяем условия заказа, особенно если часть товаров недоступна для нового региона получения.
Связываем статусы оплаты
Результат платёжного события сопоставляем с конкретной операцией. Возврат пользователя на страницу магазина сам по себе не является достаточным подтверждением оплаты.
Согласуем обработку повторного уведомления, отмены и недоступности сервиса. Оператор должен видеть статус и понимать, какие действия уже были выполнены.
Оплату рассматриваем как отдельный процесс со статусами: создана, ожидается подтверждение, подтверждена, отклонена или отменена. Возврат на сайт не равен оплате. Сопоставляем уведомление платёжной системы с заказом и проверяем, что повторное сообщение не создаёт повторную отгрузку. Сотрудник видит основание платёжного статуса и может сопоставить его с операцией получателя, не полагаясь исключительно на текст страницы благодарности.
Если заказы расходятся между сайтом и складом, сравниваем время обновления остатка, идентификаторы вариантов и последовательность событий. Проверяем одновременную покупку последнего экземпляра. Автоматическое обновление страницы не устраняет конфликт резервирования, который должен разрешаться в согласованном источнике данных. Сценарий проверяем двумя независимыми покупателями: локальная блокировка кнопки в одной вкладке не решает одновременный запрос остатка из разных сессий.
Проверяем операционный цикл
Проводим тестовый заказ до передачи в рабочую систему, изменения наличия и уведомления клиенту. Проверка только интерфейса корзины оставляет значительную часть процесса неизвестной.
Фиксируем источник ошибок и ответственных за данные. После запуска поддерживаем правила обновления каталога и проверяем затронутые сценарии при изменении интеграций.
Приёмку продолжаем после оформления: проверяем резервирование товара, передачу в обработку, уведомление клиента и изменение статуса. Для отмены и возврата согласуем отдельные правила. Интернет-магазин считается рабочим только тогда, когда команда может выполнить обещанный заказ, а не просто получить форму. Для недоставленного уведомления предусмотрен повтор сообщения, который не запускает заново сборку заказа и не меняет уже согласованное состояние оплаты.
Передаём товарную схему, карту статусов заказа, контракт обмена и набор контрольных покупок. В инструкции поддержки описываем поиск заказа по идентификатору, разбор спорной оплаты и восстановление передачи. Отдельно фиксируем, какие действия сотрудник выполняет вручную и как избегает повторной операции. Поддержка получает примеры спорных статусов, включая оплаченную отмену и частичный возврат, чтобы не восстанавливать их смысл по разрозненным сообщениям.
Часто задаваемые вопросы
Можно ли начать с каталога без оплаты?
Да. Каталог может передавать заявку менеджеру. Возможность дальнейшей оплаты и кабинета стоит учитывать при проектировании модели товара и заказа.
Зачем тестировать повторные уведомления?
Чтобы одно платёжное событие не привело к повторному выполнению операции или противоречивому статусу заказа.
Кто отвечает за корректность характеристик?
Источник и владелец товарных данных должны быть согласованы. Интерфейс не может самостоятельно исправить противоречивые сведения в учётной системе.
