7 типичных ошибок при проектировании процесса чекаута

После долгого перерыва мы в PayU решили возобновить ведение блога на Хабре. Тут не будет рекламы сервиса, зато будут рассказы о разработке новых продуктов, обзоры рынка и исследования.

Начать мы решили c 7 типичных ошибок в проектировании процесса оформления покупки на сайтах интернет-магазинов. Хочу отметить, что список далеко не полный и в комментариях я с удовольствием обсужу другие примеры.

Анализ составлен на основе крупнейших в рунете магазинов из ТОП100. Для этих ребят ошибки в проектировании процесса оформлении заказа стоят миллионы недополученных рублей. Итак, приступим.

1. Кнопка «Применить»

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

b8d112a68280439fa569d08d48d73696

059c163ab8214feda661d8c5280089a4

Решение: используйте автообновление на основе введенных в поле данных вместо кнопки «Применить».

2. Запрос избыточной информации

Часто интернет-магазины пытаются получить как можно больше информации от пользователя, при этом совершенно не объясняют зачем эта информация требуется. Иногда в обязательном порядке необходимо ввести одни те же данные по несколько раз.

c0e28533a4054706bac2ebcf0baa933e

8af5f821a0984c4780928a62ad864d6e

Решения:

  1. Не запрашивайте информацию, которая не нужна для оплаты и доставки заказа. Подписать на новости или опросить пользователя можно где-нибудь в другом месте уже после завершения оформления заказа.
  2. Если запрашиваете – делайте поле необязательным.
  3. Объясняйте зачем вам информация, если поле обязательное. Мы часто видим, как пользователи заполняют обязательные поля абракадаброй. Это происходит именно потому, что магазин не объясняет зачем им нужна данная информация.

Хороший пример:
f43e4b2d72d7422bbece20f51436970b

3. Форма ввода карточных данных

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

f72dc0410b0c432ba17f806c0c82aba8

e8d3fc48e6c24b5b87fd46e2e372edac

Решения:

  1. Выделяйте форму ввода платежных данных.
  2. Добавляйте опознавательные элементы безопасности рядом с формой, пользователи в большинстве своем не понимают что значок SSL вверху страницы относится ко всей странице и ко всем полям. Они могут вообще не знать что он означает.

Хороший пример:
08b78e362ba64c37ac7391d2c4fcdccf

4. Поля ввода срока действия карты

Доля платежей в интернете растет достаточно быстро (исследование на тему). Растет количество как за счет увеличения сервисов с оплатой онлайн, так и за счет притока новых пользователей в интернет, которые до этого никогда онлайн ничего не оплачивали. И вот им предлагают выбрать в выпадающем списке месяц и год окончания срока действия карты, которых нет на карте, а есть 4 цифры разделенные по два слешом. Я проверял, моя мама не знала, что это месяц и год. Однако даже если пользователь попался опытный, считать какой Октябрь месяц по счету в году точно не входило в его планы.

148eabdf28fa474694d3e7db7262d279

Итак, плохо:

  1. Январь / 2014
  2. Январь – 01 / 2014
  3. 1 – Январь / 2014
  4. 1 / 2014

Лучше:

  1. 01 – Январь / 14

Хорошо:

  1. 01 / 14

Совсем хорошо:

  1. [ ] / [ ]

Хорошие примеры:
02b46efab84f408eba13ffe65ebb1f68

8ede632685e94a74b348efd117276b7c

5. Линейность процесса чекаута

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

3e0feff1fd8344e58f84332aba75ec5b

Очень часто кнопка назад в браузере просто не работает и корзина очищается:
ece9ada95cab42ac9ce80c885ec91a29

Иногда нелинейности получается избежать путем запроса недостающей информации во всплывающих окнах:
0a126b970d13455bbdd5ec9490ed95dd

Решения:

  1. Не заставляйте покупателя возвращаться назад, но позволяйте это делать с сохранением всех данных, введенных до и после.
  2. Не заставляйте покупателей регистрироваться для совершения заказа.
  3. Объясните какие плюсы получит зарегистрированный пользователь, например накопление бонусов или привязка карты.

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

6. Множественные колонки

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

Решение: избегать множественных колонок,
есть 2 исключения:

  • Имя и Фамилия.
  • Дата, состоящая из полей ввода дня, месяца и/или года: рождения, доставки, срока действия карты и т.д.

Исключениями они стали потому, что фактически являются частями одного целого. Понятие ФИО — это одно значение, которое часто разбивают на 3 поля просто для удобства ввода, с датой рождения тоже самое.

7. Заключение по тестирование

Что именно вам дадут эти советы? Я не знаю, может конверсия увеличится, а может и нет. Единственный способ это выяснить – проводить А/В тесты! Недавно на вебсарафане был небольшой обзор систем тестирования, выбирайте что вам по душе.

Мы PayU не выводим ни одно изменение без проведения нескольких A/B тестов по каждому элементу страницы, у нас запрещено принимать в расчет собственные суждения при проектировании интерфейсов. Платежная страница PayU сейчас выглядит так:

79896ee5c7534826a0b1080083b15426

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

Тема проведения A/B будет рассмотрена в одном из следующих постов.