Как упростить оформление заказа в интернет-магазине
Содержание 18 разделов
Упрощение оформления заказа — это сокращение усилий без потери данных, которые действительно нужны магазину для продажи, доставки, оплаты и чека. Хороший чекаут заранее показывает условия, задаёт вопросы в понятном порядке, сохраняет введённое и помогает исправить ошибку. Количество экранов само по себе ничего не гарантирует: один перегруженный экран бывает сложнее трёх коротких шагов.
Перед переделкой полезно диагностировать, где текущая воронка теряет покупателей. Если проблема подтверждена, интерфейс проектируют под конкретные способы доставки, оплаты и обработки заказа, а затем проверяют на реальных устройствах и тестовых платежах.
Сначала определить обязательные данные
Для каждого поля задают три вопроса:
- На каком этапе и для какого процесса значение используется?
- Можно ли получить его автоматически или спросить позже?
- Что произойдёт, если оставить поле пустым?
Обычно в заказе нужны контакт для подтверждения, состав покупки, способ и место получения, способ оплаты. Полное имя, дата рождения, два контакта, индекс и подробный адрес могут оказаться лишними для самовывоза, цифрового товара или заказа, который менеджер уточняет позднее. Набор полей должен меняться вместе со сценарием, а не оставаться одинаковым для всех способов получения.
Показать условия до финального действия
Покупатель должен видеть итоговую сумму и понимать, из чего она состоит: товары, скидка, доставка и возможные дополнительные услуги. Если точную доставку можно рассчитать только после выбора города или адреса, это объясняют рядом с суммой и обновляют итог сразу после выбора.
Правила дистанционной продажи требуют довести до потребителя установленную информацию о продавце, товаре, цене и условиях приобретения до заключения договора.[1] Для интерфейса это означает простой принцип: важные условия размещают в доступном месте по ходу оформления, а не прячут только в длинном документе в подвале.
Гостевой заказ и создание аккаунта
Обязательная регистрация добавляет пароль, подтверждение и ещё один возможный сбой. Если личный кабинет не нужен для выполнения конкретной покупки, основной путь можно сделать гостевым. Аккаунт предлагают после заказа или создают по явному выбору пользователя.
Если авторизация даёт практическую пользу — применяет персональную цену, баллы или сохранённые адреса, — это объясняют рядом с предложением войти. Гостевой путь при этом остаётся видимым, а возвращение после авторизации сохраняет корзину.
Один экран или несколько шагов
Выбор зависит от объёма и зависимостей.
- Один экран подходит короткому заказу с небольшим количеством условий. Покупатель сразу видит весь объём формы.
- Несколько шагов удобны, когда выбор доставки меняет адресные поля, а способ оплаты зависит от доставки или состава заказа.
В пошаговом варианте показывают текущий этап, сохраняют значения и позволяют вернуться назад. Кнопки называют действием: «Перейти к доставке», «Выбрать оплату», «Оформить заказ». Слово «Далее» скрывает результат нажатия.
Как устроить поля формы
Видимые подписи
У каждого поля должна быть постоянная подпись. Placeholder используют для примера формата, но после ввода он исчезает. Связанный элемент label помогает и при нажатии на подпись, и при работе вспомогательных технологий.
Подходящий тип ввода
Для электронной почты, телефона и чисел используют подходящие HTML-типы и inputmode, чтобы смартфон показал удобную клавиатуру.[2] Значение inputmode лишь подсказывает вид клавиатуры; проверка допустимого значения выполняется отдельно.
Автозаполнение
Стандартные значения autocomplete — name, tel, email, shipping street-address, postal-code — помогают браузеру подставить сохранённые данные.[3] Самодельные названия и глобальное отключение автозаполнения увеличивают ручной ввод и могут ухудшить доступность.
Маски без ловушек
Маска телефона должна принимать вставку, удаление, разные способы записи и корректно работать с кодом страны, который поддерживает магазин. Жёсткая маска, совпадающая только с одним демонстрационным номером, создаёт больше ошибок, чем предотвращает. Значение нормализуют на сервере, а исходный ввод не уничтожают до успешной проверки.
Адрес и пункт выдачи
Подсказка адреса ускоряет ввод, однако пользователь должен иметь возможность исправить дом, корпус и квартиру вручную. Для пункта выдачи полезны карта и список, часы работы и срок доставки. Выбранное значение сохраняют после возврата с соседнего шага.
Как показывать и исправлять ошибки
Проверка по мере ввода полезна там, где ответ однозначен: формат почты, обязательность выбора, доступность пункта выдачи. Сообщение появляется после завершения взаимодействия с полем, а не после первого введённого символа.
W3C требует назвать автоматически обнаруженную ошибку и описать её текстом.[4] Практически это означает:
- сообщение находится рядом с проблемным полем;
- текст объясняет способ исправления;
- ошибка обозначена не одним цветом;
- после отправки фокус переводится к сводке или первому ошибочному полю;
- остальные значения сохраняются.
Сообщение «Что-то пошло не так» оставляют только для неизвестного сбоя и дополняют дальнейшим действием: повторить, выбрать другой способ или связаться с магазином. В журнал записывают технический код, чтобы поддержка могла найти причину.
Мобильный чекаут
На телефоне особенно важны порядок блоков, виртуальная клавиатура и плавающие элементы. Проверяют:
- видны ли активное поле и ошибка при открытой клавиатуре;
- не перекрывают ли кнопку cookie-плашка, чат или нижняя панель;
- можно ли выбрать вариант одной рукой;
- помещаются ли длинные адреса и названия пунктов выдачи;
- сохраняется ли заказ после поворота экрана или возврата из приложения банка.
Для сенсорных целей WCAG 2.2 устанавливает минимальный размер 24 × 24 CSS-пикселя либо достаточный интервал вокруг меньшей цели.[5] Основные кнопки и переключатели обычно делают крупнее минимального порога.
Оплата без тупиков
Надёжный сценарий оплаты начинается до перехода в платёжную форму.
- Сервер создаёт заказ с уникальным номером и фиксирует сумму.
- Пользователь переходит в платёжный сервис.
- Статус подтверждается серверным уведомлением провайдера или проверкой через API.
- Страница результата показывает фактическое состояние: оплачено, ожидается подтверждение или платёж не завершён.
- При ошибке доступна повторная попытка или другой способ без повторного заполнения заказа.
Возврат пользователя на success-URL сам по себе не доказывает оплату. Обработчик уведомления делают идемпотентным: повторное сообщение от платёжной системы обновляет тот же заказ и не создаёт дубликат.
Событие purchase отправляют один раз с идентификатором заказа. Официальная документация Метрики описывает обязательный идентификатор покупки и передачу суммы и товарных позиций.[6]
Кассовый чек и контакт покупателя
ФНС указывает, что при расчёте продавец обязан сформировать кассовый чек; электронный чек может быть направлен по номеру телефона или адресу электронной почты, предоставленному покупателем до расчёта.[7] Конкретный набор полей зависит от способа расчёта, выдачи чека и модели доставки. Эту логику согласуют с кассой и учётной системой до проектирования формы, чтобы после запуска не добавлять срочно ещё одно обязательное поле.
Персональные данные и чекбокс согласия
Статья 6 закона № 152-ФЗ допускает обработку, необходимую для исполнения договора или его заключения по инициативе человека.[8] Поэтому оформление заказа не означает автоматическую обязанность разместить универсальный чекбокс согласия возле кнопки. Сначала оператор определяет цель, состав данных и правовое основание.
Когда основанием служит согласие, оно должно быть конкретным, информированным и подтверждаемым. Подписку на рекламные сообщения отделяют от покупки и оставляют добровольной. Политика обработки объясняет, кто и зачем получает данные, но сама ссылка на политику не заменяет основание обработки.
Защита от повторной отправки и потери данных
После первого нажатия кнопка показывает состояние обработки и блокирует повтор до ответа. На сервере применяют ключ идемпотентности или проверку повторного запроса. Если сеть оборвалась, пользователь видит состояние заказа и может безопасно продолжить.
Корзину и черновик формы сохраняют в разумных пределах. При возврате из оплаты или авторизации пользователь попадает к своему заказу, а не на пустую главную страницу. Чувствительные платёжные реквизиты в браузерном хранилище магазина не сохраняют.
План внедрения
- Карта текущего процесса: поля, зависимости, API доставки, оплаты, кассы и CRM.
- Данные: воронка, ошибки, устройства и обращения покупателей.
- Прототип: порядок шагов, состояния загрузки, ошибки и возвраты.
- Технический контракт: статусы заказа, события аналитики, защита от дублей.
- Разработка: поэтапно, с возможностью включить новую версию части трафика.
- Приёмка: устройства, браузеры, способы доставки, успешные и неуспешные платежи.
- Контроль: ошибки, заказы, отмены и показатели воронки после выпуска.
Матрица проверок перед запуском
- гость и авторизованный покупатель;
- самовывоз, курьер и другие фактически подключённые способы;
- товар в наличии, под заказ и закончившийся во время оформления;
- промокод, скидка, изменение количества и минимальная сумма;
- оплата успешная, отклонённая, зависшая и повторная;
- возврат назад, обновление страницы и разрыв сети;
- смартфоны с iOS и Android из основной аудитории;
- повторное уведомление платёжного сервиса;
- однократная передача покупки в аналитику и кассу.
События аналитики для чекаута
События проектируют вместе с интерфейсом, чтобы после запуска не восстанавливать воронку по URL. Минимальный контракт описывает имя события, момент отправки, обязательные параметры и способ дедупликации. Для пошаговой формы фиксируют начало оформления, выбор доставки, переход к оплате, создание заказа и подтверждённый бизнесом статус покупки.
В параметры можно включить способ доставки, способ оплаты, тип клиента, сумму и техническую версию чекаута. Свободный текст полей в аналитику не отправляют. Код ошибки передают как заранее определённое значение: delivery_unavailable, payment_declined, validation_error. Такой справочник позволяет сравнивать периоды и не раскрывает введённые покупателем данные.
Событие отправляют после факта, который оно называет. Нажатие «Оформить» — это попытка, созданный заказ — результат сервера. Для диагностики можно хранить оба события, но с разными названиями. Проверка перед запуском включает отсутствие дублей после обновления страницы и совпадение покупок с заказами за контрольный период.
Особые сценарии, которые часто забывают
- Цена изменилась: интерфейс показывает новую сумму и просит подтвердить её до оплаты.
- Товар закончился: проблема относится только к позиции, остальные товары и введённые данные сохраняются.
- Разделённая доставка: покупатель понимает сроки и стоимость каждой части.
- Юридическое лицо: реквизиты появляются после выбора типа покупателя и не утяжеляют путь физического лица.
- Предзаказ: дата и порядок оплаты обозначены до финальной кнопки.
- Повторная покупка: сохранённые данные можно проверить и изменить, а не только принять целиком.
Как понять, что чекаут стал лучше
Основной показатель — доля начатых оформлений, завершившихся целевым статусом заказа. Вместе с ней контролируют ошибки, время прохождения, среднюю сумму, отмены, невыкуп, обращения и скорость страницы. Изменение оценивают на сопоставимом трафике или в эксперименте. Рост созданных заказов ценой резкого увеличения отмен не считается улучшением процесса.
Итог
Удобный чекаут задаёт только необходимые вопросы, заранее показывает цену и получение, помогает заполнить и исправить форму, сохраняет состояние и надёжно обрабатывает оплату. Конкретная реализация зависит от бизнеса, но критерии проверки универсальны: покупатель понимает следующий шаг, заказ создаётся один раз, статус подтверждается сервером, данные аналитики совпадают с реальными заказами.
Источники
- Постановление Правительства РФ от 31.12.2020 № 2463: правила розничной продажи.
- MDN: атрибут inputmode.
- MDN: атрибут autocomplete.
- W3C: Understanding Success Criterion 3.3.1 — Error Identification.
- W3C: Understanding Success Criterion 2.5.8 — Target Size (Minimum).
- Яндекс Метрика: передача данных электронной коммерции.
- ФНС России: особенности формирования кассового чека.
- Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных».