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

Опишите препятствие покупателя до обсуждения нового дизайна

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

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

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

Выясните, что уже умеет стандартный компонент

В «1С-Битрикс: Управление сайтом» для оформления заказа используется, в частности, стандартный компонент sale.order.ajax. В официальной документации описаны его параметры, включая порядок выбора оплаты и доставки, профили покупателей и настройки отображения. Наличие функции в документации не гарантирует, что она корректно включена в вашем шаблоне.

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

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

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

Сократите поля по потребности процесса

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

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

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

Проверьте зависимость доставки от адреса и состава заказа

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

Условный сценарий: покупатель сначала выбрал пункт выдачи, затем изменил город. Старый пункт не должен остаться выбранным незаметно, если он больше не подходит. Форма должна запросить новый выбор и пересчитать связанные условия. Аналогично проверьте изменение количества товара и удаление позиции, от которой зависела доставка.

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

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

Показывайте итоговую сумму до подтверждения

Покупатель должен понимать состав суммы: товары, скидки, доставка и иные согласованные платежи. После изменения города, способа оплаты или количества итог должен обновляться понятно и без потери введённых данных. В ТЗ опишите момент пересчёта и то, что видит пользователь во время ожидания.

Скидку и промокод проверяйте вместе с корзиной. Если удаление товара меняет право на скидку, объясните новый итог. Не оставляйте старую скидку в одном блоке и новую сумму в другом. Источники расчёта на странице, в сохранённом заказе и в платёжном сервисе должны быть согласованы.

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

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

Разделите создание заказа и подтверждение оплаты

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

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

Сопоставьте заказ на сайте, платёжное событие и данные, полученные менеджером. Статус «оплачен», выставленный только по возвращению браузера, требует проверки специалистом: важен подтверждённый результат операции. Заказчику достаточно потребовать демонстрацию цепочки на контрольном примере, без разбора программного интерфейса.

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

Ошибка должна объяснять способ исправления

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

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

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

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

Пройдите оформление на телефоне и без мыши

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

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

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

Выберите браузеры и устройства для проверки по данным об аудитории сайта. Для фиксации результатов полезен порядок из статьи о проверке сайта в разных браузерах. Один удачный проход на компьютере разработчика недостаточен для принятия мобильного сценария.

Сформируйте небольшой выпуск с понятными границами

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

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

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

Передайте ШТАБ ИТ адрес оформления, описание одного затруднения и обезличенный контрольный набор товаров. Через обсуждение доработки можно определить, где достаточно настройки, а где нужна разработка. Результатом задания должны стать конкретные сценарии, которые заказчик сможет проверить самостоятельно.