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

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

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

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

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


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





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

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


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





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


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


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


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





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


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


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


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



    Итак, плохо:
    1. Январь / 2014
    2. Январь – 01 / 2014
    3. 1 – Январь / 2014
    4. 1 / 2014


    Лучше:
    1. 01 – Январь / 14


    Хорошо:
    1. 01 / 14


    Совсем хорошо:
    1. [ ] / [ ]


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




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


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



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


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


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


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

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


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


    Решение: избегать множественных колонок,
    есть 2 исключения:
    • Имя и Фамилия.
    • Дата, состоящая из полей ввода дня, месяца и/или года: рождения, доставки, срока действия карты и т.д.

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

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


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

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



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

    Тема проведения A/B будет рассмотрена в одном из следующих постов.
    Метки:
    PayU 24,08
    Компания
    Поделиться публикацией
    Комментарии 56
    • +2
      А где их тут семь? Я увидел только две типичных ошибки…
      • 0
        Андрей, спасибо! Исправил пост
      • –3
        Доля платежей в интернете растет достаточно быстро (исследование на тему). Растет количество как за счет увеличения сервисов с оплатой онлайн, так и за счет притока новых пользователей в интернет, которые до этого никогда онлайн ничего не оплачивали. И вот им предлагают выбрать в выпадающем списке месяц и год окончания срока действия карты, которых нет на карте, а есть 4 цифры разделенные по два слешом. Я проверял, моя мама не знала, что это месяц и год. Однако даже если пользователь попался опытный, считать какой Октябрь месяц по счету в году точно не входило в его планы.

        А у меня на карте наоборот написано срок действия в виде ХХ/YYYY то есть нужно просто переписать данные с карты. А по вашей логике мне нужно вспоминать соответствие какой месяц какой цифре принадлежит.

        Вообще юзабилити это вопрос не такой тривиальный. Зависит как минимум от аудитории продукта. Поэтому в таких случаях лучше анализировать что вводит пользователь и если все обишаются значит нужно изменить юзабилити.
        • 0
          Игорь, вы абсолютно правы. Именно этому посвящена заключительная часть поста про А/Б тестирование на реальной базе. А вообще первый раз слышу, что на карте может быть указан срок действия в таком формате.
          • +1
            Да ладно, Посмотрел на своих двух картах, спросил в скайпе знакомых у всех формат ММ/ГГГГ или ММ/ГГ во всяком случае в Украине так.
            • +1
              ММ/ГГ — распростаненный формат, а вот ММ/ГГГГ, как писал выше, встречаю в первый.
              • 0
                Так дело даже не в годе. Вы советуете вместо списка [01,02,03,04,05,06,07,08,09,10,11,12] вставить список месяцев [Январь, Февраль и т.д.].

                То есть я смотрю на карту вижу 04/16. Мне нужно вспомнить что 04 это апрель и выбрать апрель?
                • +2
                  Игорь, как раз наоборот. Я отметил этот вариант, как плохой. Чуть лучше, когда рядом с буквенным названием месяца добавлен номер месяца. Чуть лучше, это все равно плохо.
          • +1
            Анализировать и тестировать нужно всегда. Бывает так, что вещи, кажущиеся аксиомами, становятся чуть ли не фатальным заблуждением! И этим грешат даже самые известные компании, не говоря уже о тех, кто только начинает свой путь в электронной коммерции. И хорошо, если посчастливится вовремя встретиться с конструктивной критикой! Автор статьи, как мне кажется, поступает очень правильно, приветствуя критику и активно отвечая на вопросы. Ведь, по сути, здесь мало кто заинтересован в лести. Так что можно получить много объективно ценной информации.
          • 0
            Надо заметить, что сайт РЖД в самом деле хороший пример. Но есть и у них нюансы. Например надо не забывать ставить галку «оплатить постельное бельё» (по умолчанию она не стоит у ночных и дальних поездов) и снимать галку с добровольной страховкой. И ещё: напуркуа им моё место рождения?
          • +6
            Вопросы юзабилити всегда неоднозначны, но что касательно поля «Промо-код» и кнопки «Применить» вопрос уж совсем спорный.

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

            Ситуация 2: пользователь вводит промо-код, а кнопки применить нет.
            Ожидаемая реакция А: корзина пересчитается сразу после ввода последнего символа;
            Ожидаемая реакция B: корзина пересчитается сразу после ввода и снятия фокуса с поля;
            Ожидаемая реакция C: корзина пересчитается после ввода кода и нажатия кнопки «Заказать».
            Т.е. что должно случиться однозначно непонятно.

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

            У одного брендового магазина пока проверяется промо-код, вообще можно вполне успеть нажать «Заказать», и заказ оформляется без применения промо-кода.

            Так что, кнопку «Применить» убирать стоит кране осмотрительно.
            • 0
              Надо экспериментировать в любом случае. И считать позитивный/негативный эффект. Очень часто кнопки применения промо-кода и продолжения оформления практически равнозначны в дизайне.
              • +1
                Поддерживаю Sirleh пользователю глубоко фиолетово будет перезагружаться страница или нет, и уж точно он не будет об этом задумываться при нажатии кнопки. А вот поле с автопроверкой для пользователя менее очевидное решение. Я бы вообще сделал поле с кнопкой, но поле проверяется автоматически, и там же выводится результат проверки.
                • 0
                  Пользователю не фиолетово если на этой странице он уже ввел кучу своих личных данных, таких как дата, время и адрес доставки, телефон, почту, ФИО и т.д.
                  • 0
                    ничто не мешает вам, как программисту, реализовать повторное заполнение ранее заполненных полей.

                    но тут скорее произошла подмена понятий — думаю, что Sirleh под «страница обновится» имел в виду что на ней обновятся поля, а не целиком перезагрузится вся страница
                    • 0
                      Виктор, совершенно верно, так и нужно поступать. Введенные пользователем данные должны быть сохранены. Вопрос в том, ожидает ли это пользователь? Подсказка под полем и кнопкой с текстом «Ваши данные не потеряются, нажимайте смелее» решит задачу. Что касается перезагрузки полей, это решение и имелось ввиду в проблеме №1.
            • 0
              Рекомендую заголовки ошибок пронумеровать — и для удобства их подсчёта, и для удобства последующих ссылок на них в форме «третья из ошибок, упомянутых вон в том обзоре».
              • 0
                Спасибо, как-то подумал об этом сразу.
              • +3
                Буквально вчера столкнулся с доменным регистратором, который просил добавить данные карты во время регистрации. Одна проблема: страница была HTTP. Пришлось вручную прописывать https://, причём даже в этом случае в коде прописаны HTTP-ссылки на JavaScript. Ну и толку после этого, что у них сертификат Extended Validation? Обязательно найдут, где обосраться.

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

                Вот поэтому и нужно объяснять и всегда просить проверять данные. Подробно описывал здесь: habrahabr.ru/post/247367/#comment_8210681

                Кстати, по поводу secure.payu.ru:
                www.ssllabs.com/ssltest/analyze.html?d=secure.payu.ru
                This server is vulnerable to the POODLE attack against TLS servers. Patching required. Grade set to F.

                Балансировщики нагрузки неправильно HTTPS-соединения обрабатывают. Фото на память: habrastorage.org/files/1b5/6d8/d38/1b56d8d389ab4fccb749a80a53bdd013.png

                Ах, да. Если не перестанете использовать шифр RC4 и обычный RSA, новые версии Google Chrome будут сообщать, что соединение зашифровано с помощью УСТАРЕВШЕЙ криптографии. Вместо этого нужно использовать 128-битный AES в режиме AEAD GCM и эфемерный Диффи-Хеллман, желательно на базе эллиптических кривых. Скрин из девелоперского билда: habrastorage.org/files/ea7/e62/81f/ea7e6281f82d40efa799f5e3e7c99db4.png
                • 0
                  Спасибо, передал разработчикам.
                  • 0
                    Хорошо, буду следить за развитием событий. Только нужно учитывать, что предложенные мною изменения могут не понравиться PCI-аудиторам. Использование шифра RC4, являющегося потоковым, предотвращает атаку BEAST (Browser Exploit Against SSL/TLS) против блочных шифров, когда зловредный JavaScript нарушает политику одного источника. Но уязвимость на то и браузерная, что решать её на стороне сервера не стоит, так как современные браузеры реализовали механизм разделения записей 1/n-1. Либо можно выключить использование RC4 с протоколами новее TLS 1.0.
                    Диффи-Хеллман тоже не все любят, у банков редко встретишь.
                • +1
                  Второй скрин среди хороших примеров поля ввода срока действия карты — это реальный? У Озона ввод данных карты по HTTP? Да, хороший пример…
                  • 0
                    У озона используется iframe, который форма подставляется с сервера с ssl. Но озон не во всем хороший пример, это точно.
                    • +3
                      Так если сама страница по HTTP, MITM может просто подменить iframe на свой, и никто этого не заметит. Ввод логина и пароля на HTTP c отправкой на HTTPS — такое везде, но чтобы оплата…
                      • 0
                        Озон, видимо, решил, что для них это не так важно.
                  • +1
                    Промо-коду кнопка «Применить» нужна однозначно.
                    • +1
                      Почему так думаете?
                      • +7
                        Потому что я активный клиент различных интернет-магазинов и не раз вводил эти коды.

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

                        Понимание того, что произойдет при нажатии кнопки «применить», достаточно прозрачное. Оно намного лучше психологического дискомфорта от перехода к оплате без понимания итоговой суммы. Это как идти на кассу в магазине, не зная, сколько у тебя денег в кармане.
                        • 0
                          Речь о том, что при вводе промокода все поля пересчитываются автоматически. Если это по какой-то причине сделать невозможно, кнопку можно и оставить, но она должна быть отличной от кнопки продолжения оформления заказа.
                          • 0
                            эти автоматические пересчёты ещё и визуализировать надо, чтобы была обратная связь «ввёл — изменилось».
                            • +1
                              Это сделать невозможно. Точнее не невозможно, но совершенно бессмысленно.

                              Промо-код — это фактически пароль, валидность которого всегда проверяется на сервере. Проверять его после каждого символа, пугая юзера сообщениями «код не распознан»? Или по таймауту? Или как?
                              Кроме того, в серьезных магазинах, если код не работат, пишут причину. Типа — «Срок действия этого купона истек 10.01.2015». Какую внятную причину можно показать для обрывка кода?

                              И выше верно написали — если что-то происходит «само по себе», нужна обратная связь, чтобы юзер это заметил и понял, что происходит.

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

                              P.S. Вообще часто такое наблюдаю — в попытках слишком буквально понимать советы UI/UX-гуру многие себе создают больше проблем, чем пользы. Советы гуру хороши, но в сочетании со здравым смыслом.
                              • 0
                                А что, заставить JS отправлять код не после каждого символа, а только после того, как будет набран весь код — слишком сложно?
                                Обратная связь вполне себе реализуется крутящимся колесиком на время обработки.
                                • +1
                                  Большинство промокодов переменной длины. Т.е. то, что он набран весь можно узнать только по событию blur (может быть), но это выглядит крайне ненадёжным способом. Лучше уж кнопка «Применить» рядышком.
                                  • 0
                                    Тогда просто не показывать ошибку, сообщая о ней на следующем шаге. Впрочем, это я не советую, а просто говорю, как можно обойтись без кнопки «применить».
                                    • 0
                                      Более, кнопка «Применить» в данном случае дает понятный поток действий и отсутствие ненужных пауз (а не отвлекает, как некоторые пытаются говорить).
                                      Так что её даже не надо расценивать как вынужденную жертву, это нормальное хорошее решение.
                                    • 0
                                      Я не вижу надежного способа определить, что код действительно введен в полностью.
                                      • 0
                                        Сравнивать его с хешами всех валидных промокодов, которые есть на сервере. Естественно, дополнительно валидировать его на сервере, но отправлять только есть совпал хеш.
                                        • 0
                                          А если пользователь вводил валидный код, но опечатался в одной букве? Вот он ввёл, сидит и ждёт, когда же система соблаговолит принять его правильный (как он думает) код?
                          • 0
                            >> Позитивным примером, как не странно, может быть сайт РЖД. Для покупки билета необходимо авторизоваться, однако это не обрывает процесс.

                            Позитивным, да не очень, к сожалению.
                            Аутентификация процесс действительно не прерывает, а вот если пользователь не зарегистрирован, то выбирать маршрут-дату-поезд-вагоны придётся заново.
                            Хорошо хоть у конкретного пользователя этот провал происходит один-единственный раз (потом уже будут реквизиты доступа).
                            • 0
                              Позитивный он только в приведенном кейсе, конечно.
                            • +2
                              До сих пор не могу понять какое отношение имеет 03 и 12 к Январю
                              • 0
                                Никакого, спасибо что обратили внимание. Поправил цифры в соответствии с месяцем.
                              • +1
                                А еще не надо запрещать ввод данных карты копированием, и уж точно не разделять серии цифр карты на разные поля.
                                • 0
                                  Спасибо, отличные вводные. О проектировании платежной странице расскажем в следующем посте.
                                  • +1
                                    А расскажите еще, зачем у меня изредка просят наименование банка, выдавшего карту(!). Исходя из того, что это встречается на одной из десятка сайтов, необходимости в этом никакой нет.
                                    И еще о том, почему никто не проверяет имя-фамилию(я вводил два года на сайтах ZAYTSEV, а потом внезапно обнаружил, что на карте ZAYTCEV. проблем с оплатой не было ни разу).
                                    И почему некоторые сайты заставляют выбирать тип карты(виза/мастер), хотя это определяется парой строчек кода по первой цифре номера. Более того, они это определяют, и говорят, что я выбрал неверный тип карты! Откуда берутся такие альтернативно умные люди, которые в состоянии сделать проверку на корректный тип и выдать сообщение, но не могут сделать просто тихое определение типа карты(если он им зачем-то нужен).
                                    • 0
                                      Влад, эмитента спрашивают для последующей сверки с данными, полученными при самой транзакции, это один из доисторических методов противодействия фроду. Мы так не делаем, но коллеги по цеху все еще спрашивают, вы правы. Что касается кардхолдера, это тоже в основном информационное поле, которое не влияет на прохождение транзакции.
                                      • 0
                                        А как его сравнивают? Вручную? Нет же никаких правил, как вводить это название. Альфабанк, альфа, альфа-банк, Альфа Банк, Alfabank, Alfa-Bank, alfa-banc, куча вариантов же есть написания одного и того же банка.
                                        • 0
                                          Да, вручную. Например если транзакция «выпала» на ручной мониторинг, т.е. у автоматический фильтров сложилось подозрение, что это потенциальный фрод. Риск менеджер смотрит поля транзакции. Там куча факторов, например если форму заполнили за 0.1 секунду, это вероятно робот. Запрет на копирование делается с аналогичной целью.

                                          Если робот не потрудился заполнить поле эмитента, или заполнил его какими-то шаблонными данными, это тоже вызывает подозрения.
                                  • 0
                                    > ввод данных карты копированием

                                    Думается мне, это не очень хорошая идея (если у вас, конечно, не чистится буфер копирования автоматом). Неосторожный пользователь может потом эти данные вставить куда-то не туда.
                                    Отсюда же и растут ноги разделения цифр в номере карты — их визуально так удобнее заполнять и проверять перед отправкой.
                                    • +1
                                      А может я сам буду решать, какие данные в моем буфере — хорошая идея, а какие — нет? Я имею ввиду, что если пользователь хочет вставить номер карты, а не ввести его вручную — то он уже есть у него на компе в электронном виде. Более того, он уже и есть у него в буфере обмена, потому что он его уже скопировал из файлика/хранилища паролей и попытался вставить в поле на сайте. А тут раз, и не вставилось. Пользователь бесится, потому что ему надо вставлять длинный номер куда-нибудь(например в адресную строку браузера, которая ближе всего), и копировать по 4 цифры. А если там вообще запрещено копирование, то и вводить вручную. Номер из буфера обмена по прежнему никуда не девается.

                                      их визуально так удобнее заполнять и проверять перед отправкой.

                                      А это уже проблемы верстальщика. Можно прекрасно сделать и в одном поле средствами JS/HTML/CSS разделение по 4 цифры, и выглядеть это будет красиво и понятно.
                                      • 0
                                        Ну вот вы можете это решить, а 95% пользователей — нет. И у них нет никаких зашифрованных хранилищ, а есть карты в кошельке.
                                        Мне и самому было бы удобнее так (для оплаты пользуюсь исключительно вирт. картами).
                                        • 0
                                          И у них нет никаких зашифрованных хранилищ, а есть карты в кошельке.

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

                                          UPD: выше ответили, почему. Один из факторов, которые повышают «доверие» к транзакции.
                                    • 0
                                      ---> А еще не надо запрещать ввод данных карты копированием

                                      Это один из методом анти-кардинга. Если копипаст, велика вероятность мошенничества, данные карты предполагаются берущимися из блокнота, экселя, аськи, жаббера итд итп. Против этого на кард-форумах программы выкладывают, которые ручной ввод имитируют. Не всё так просто.
                                      • 0
                                        Анти-фрод фильтры ушли далеко вперед и анализирует потенциальную возможность перебора по очень большому количеству факторов. Усложнять жизнь пользователю в угоду антифрод фильтрам — это не дело.

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое