Комментарии 56
А где их тут семь? Я увидел только две типичных ошибки…
Доля платежей в интернете растет достаточно быстро (исследование на тему). Растет количество как за счет увеличения сервисов с оплатой онлайн, так и за счет притока новых пользователей в интернет, которые до этого никогда онлайн ничего не оплачивали. И вот им предлагают выбрать в выпадающем списке месяц и год окончания срока действия карты, которых нет на карте, а есть 4 цифры разделенные по два слешом. Я проверял, моя мама не знала, что это месяц и год. Однако даже если пользователь попался опытный, считать какой Октябрь месяц по счету в году точно не входило в его планы.
А у меня на карте наоборот написано срок действия в виде ХХ/YYYY то есть нужно просто переписать данные с карты. А по вашей логике мне нужно вспоминать соответствие какой месяц какой цифре принадлежит.
Вообще юзабилити это вопрос не такой тривиальный. Зависит как минимум от аудитории продукта. Поэтому в таких случаях лучше анализировать что вводит пользователь и если все обишаются значит нужно изменить юзабилити.
Игорь, вы абсолютно правы. Именно этому посвящена заключительная часть поста про А/Б тестирование на реальной базе. А вообще первый раз слышу, что на карте может быть указан срок действия в таком формате.
Да ладно, Посмотрел на своих двух картах, спросил в скайпе знакомых у всех формат ММ/ГГГГ или ММ/ГГ во всяком случае в Украине так.
ММ/ГГ — распростаненный формат, а вот ММ/ГГГГ, как писал выше, встречаю в первый.
Анализировать и тестировать нужно всегда. Бывает так, что вещи, кажущиеся аксиомами, становятся чуть ли не фатальным заблуждением! И этим грешат даже самые известные компании, не говоря уже о тех, кто только начинает свой путь в электронной коммерции. И хорошо, если посчастливится вовремя встретиться с конструктивной критикой! Автор статьи, как мне кажется, поступает очень правильно, приветствуя критику и активно отвечая на вопросы. Ведь, по сути, здесь мало кто заинтересован в лести. Так что можно получить много объективно ценной информации.
Надо заметить, что сайт РЖД в самом деле хороший пример. Но есть и у них нюансы. Например надо не забывать ставить галку «оплатить постельное бельё» (по умолчанию она не стоит у ночных и дальних поездов) и снимать галку с добровольной страховкой. И ещё: напуркуа им моё место рождения?
Вопросы юзабилити всегда неоднозначны, но что касательно поля «Промо-код» и кнопки «Применить» вопрос уж совсем спорный.
Ситуация 1: Пользователь вводит промо-код и нажимает «Применить»
Ожидаемая реакция: корзина пересчитается с учетом промо-кода. При этом пользователю всё равно, что произойдет со страницей: обновится, не обновится, лишь бы скидку дали.
Ситуация 2: пользователь вводит промо-код, а кнопки применить нет.
Ожидаемая реакция А: корзина пересчитается сразу после ввода последнего символа;
Ожидаемая реакция B: корзина пересчитается сразу после ввода и снятия фокуса с поля;
Ожидаемая реакция C: корзина пересчитается после ввода кода и нажатия кнопки «Заказать».
Т.е. что должно случиться однозначно непонятно.
В итоге отсутствие кнопки имеет для бизнеса негативные последствия, например. если промо-код не применяется, а такое бывает нередко: или промо-код нерабочий, или введен неправильно, а клиент решил не замечать красной надписи об ошибке. В итоге клиент оказывается недоволен, заказ отменен, что хуже — возвращен из-за несоответствия цены ожиданиям, в особо лютых случаях клиенты начинают требовать скидку по промо-коду у курьера. А это уже совсем другие показатели, более важные, чем конверсия.
У одного брендового магазина пока проверяется промо-код, вообще можно вполне успеть нажать «Заказать», и заказ оформляется без применения промо-кода.
Так что, кнопку «Применить» убирать стоит кране осмотрительно.
Ситуация 1: Пользователь вводит промо-код и нажимает «Применить»
Ожидаемая реакция: корзина пересчитается с учетом промо-кода. При этом пользователю всё равно, что произойдет со страницей: обновится, не обновится, лишь бы скидку дали.
Ситуация 2: пользователь вводит промо-код, а кнопки применить нет.
Ожидаемая реакция А: корзина пересчитается сразу после ввода последнего символа;
Ожидаемая реакция B: корзина пересчитается сразу после ввода и снятия фокуса с поля;
Ожидаемая реакция C: корзина пересчитается после ввода кода и нажатия кнопки «Заказать».
Т.е. что должно случиться однозначно непонятно.
В итоге отсутствие кнопки имеет для бизнеса негативные последствия, например. если промо-код не применяется, а такое бывает нередко: или промо-код нерабочий, или введен неправильно, а клиент решил не замечать красной надписи об ошибке. В итоге клиент оказывается недоволен, заказ отменен, что хуже — возвращен из-за несоответствия цены ожиданиям, в особо лютых случаях клиенты начинают требовать скидку по промо-коду у курьера. А это уже совсем другие показатели, более важные, чем конверсия.
У одного брендового магазина пока проверяется промо-код, вообще можно вполне успеть нажать «Заказать», и заказ оформляется без применения промо-кода.
Так что, кнопку «Применить» убирать стоит кране осмотрительно.
Надо экспериментировать в любом случае. И считать позитивный/негативный эффект. Очень часто кнопки применения промо-кода и продолжения оформления практически равнозначны в дизайне.
Поддерживаю Sirleh пользователю глубоко фиолетово будет перезагружаться страница или нет, и уж точно он не будет об этом задумываться при нажатии кнопки. А вот поле с автопроверкой для пользователя менее очевидное решение. Я бы вообще сделал поле с кнопкой, но поле проверяется автоматически, и там же выводится результат проверки.
Пользователю не фиолетово если на этой странице он уже ввел кучу своих личных данных, таких как дата, время и адрес доставки, телефон, почту, ФИО и т.д.
ничто не мешает вам, как программисту, реализовать повторное заполнение ранее заполненных полей.
но тут скорее произошла подмена понятий — думаю, что Sirleh под «страница обновится» имел в виду что на ней обновятся поля, а не целиком перезагрузится вся страница
но тут скорее произошла подмена понятий — думаю, что Sirleh под «страница обновится» имел в виду что на ней обновятся поля, а не целиком перезагрузится вся страница
Виктор, совершенно верно, так и нужно поступать. Введенные пользователем данные должны быть сохранены. Вопрос в том, ожидает ли это пользователь? Подсказка под полем и кнопкой с текстом «Ваши данные не потеряются, нажимайте смелее» решит задачу. Что касается перезагрузки полей, это решение и имелось ввиду в проблеме №1.
Рекомендую заголовки ошибок пронумеровать — и для удобства их подсчёта, и для удобства последующих ссылок на них в форме «третья из ошибок, упомянутых вон в том обзоре».
Буквально вчера столкнулся с доменным регистратором, который просил добавить данные карты во время регистрации. Одна проблема: страница была 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
---> Добавляйте опознавательные элементы безопасности рядом с формой, пользователи в большинстве своем не понимают что значок 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
Спасибо, передал разработчикам.
Хорошо, буду следить за развитием событий. Только нужно учитывать, что предложенные мною изменения могут не понравиться PCI-аудиторам. Использование шифра RC4, являющегося потоковым, предотвращает атаку BEAST (Browser Exploit Against SSL/TLS) против блочных шифров, когда зловредный JavaScript нарушает политику одного источника. Но уязвимость на то и браузерная, что решать её на стороне сервера не стоит, так как современные браузеры реализовали механизм разделения записей 1/n-1. Либо можно выключить использование RC4 с протоколами новее TLS 1.0.
Диффи-Хеллман тоже не все любят, у банков редко встретишь.
Диффи-Хеллман тоже не все любят, у банков редко встретишь.
Второй скрин среди хороших примеров поля ввода срока действия карты — это реальный? У Озона ввод данных карты по HTTP? Да, хороший пример…
Промо-коду кнопка «Применить» нужна однозначно.
Почему так думаете?
Потому что я активный клиент различных интернет-магазинов и не раз вводил эти коды.
Коды очень часто могут не работать (обычно проблема в сроках действия, но бывает и много других) или работать не так, как ожидает покупатель (действие только на определенные товары, от определенной суммы корзины и т.п.)
Поэтому клиент хочет:
а) убедиться, что код работает
б) узнать, какую точно скидку он получает
в) скажется ли это на стоимости доставки
Понимание того, что произойдет при нажатии кнопки «применить», достаточно прозрачное. Оно намного лучше психологического дискомфорта от перехода к оплате без понимания итоговой суммы. Это как идти на кассу в магазине, не зная, сколько у тебя денег в кармане.
Коды очень часто могут не работать (обычно проблема в сроках действия, но бывает и много других) или работать не так, как ожидает покупатель (действие только на определенные товары, от определенной суммы корзины и т.п.)
Поэтому клиент хочет:
а) убедиться, что код работает
б) узнать, какую точно скидку он получает
в) скажется ли это на стоимости доставки
Понимание того, что произойдет при нажатии кнопки «применить», достаточно прозрачное. Оно намного лучше психологического дискомфорта от перехода к оплате без понимания итоговой суммы. Это как идти на кассу в магазине, не зная, сколько у тебя денег в кармане.
Речь о том, что при вводе промокода все поля пересчитываются автоматически. Если это по какой-то причине сделать невозможно, кнопку можно и оставить, но она должна быть отличной от кнопки продолжения оформления заказа.
эти автоматические пересчёты ещё и визуализировать надо, чтобы была обратная связь «ввёл — изменилось».
Это сделать невозможно. Точнее не невозможно, но совершенно бессмысленно.
Промо-код — это фактически пароль, валидность которого всегда проверяется на сервере. Проверять его после каждого символа, пугая юзера сообщениями «код не распознан»? Или по таймауту? Или как?
Кроме того, в серьезных магазинах, если код не работат, пишут причину. Типа — «Срок действия этого купона истек 10.01.2015». Какую внятную причину можно показать для обрывка кода?
И выше верно написали — если что-то происходит «само по себе», нужна обратная связь, чтобы юзер это заметил и понял, что происходит.
Правда, послушайте многоопытного покупателя — с кнопкой лучше, намного. А красить её в яркий цвет, чтобы она затмила собой всю форму заказа, никто и не просит. Она просто должна быть рядышком.
P.S. Вообще часто такое наблюдаю — в попытках слишком буквально понимать советы UI/UX-гуру многие себе создают больше проблем, чем пользы. Советы гуру хороши, но в сочетании со здравым смыслом.
Промо-код — это фактически пароль, валидность которого всегда проверяется на сервере. Проверять его после каждого символа, пугая юзера сообщениями «код не распознан»? Или по таймауту? Или как?
Кроме того, в серьезных магазинах, если код не работат, пишут причину. Типа — «Срок действия этого купона истек 10.01.2015». Какую внятную причину можно показать для обрывка кода?
И выше верно написали — если что-то происходит «само по себе», нужна обратная связь, чтобы юзер это заметил и понял, что происходит.
Правда, послушайте многоопытного покупателя — с кнопкой лучше, намного. А красить её в яркий цвет, чтобы она затмила собой всю форму заказа, никто и не просит. Она просто должна быть рядышком.
P.S. Вообще часто такое наблюдаю — в попытках слишком буквально понимать советы UI/UX-гуру многие себе создают больше проблем, чем пользы. Советы гуру хороши, но в сочетании со здравым смыслом.
А что, заставить JS отправлять код не после каждого символа, а только после того, как будет набран весь код — слишком сложно?
Обратная связь вполне себе реализуется крутящимся колесиком на время обработки.
Обратная связь вполне себе реализуется крутящимся колесиком на время обработки.
Большинство промокодов переменной длины. Т.е. то, что он набран весь можно узнать только по событию blur (может быть), но это выглядит крайне ненадёжным способом. Лучше уж кнопка «Применить» рядышком.
Тогда просто не показывать ошибку, сообщая о ней на следующем шаге. Впрочем, это я не советую, а просто говорю, как можно обойтись без кнопки «применить».
Более, кнопка «Применить» в данном случае дает понятный поток действий и отсутствие ненужных пауз (а не отвлекает, как некоторые пытаются говорить).
Так что её даже не надо расценивать как вынужденную жертву, это нормальное хорошее решение.
Так что её даже не надо расценивать как вынужденную жертву, это нормальное хорошее решение.
Я не вижу надежного способа определить, что код действительно введен в полностью.
>> Позитивным примером, как не странно, может быть сайт РЖД. Для покупки билета необходимо авторизоваться, однако это не обрывает процесс.
Позитивным, да не очень, к сожалению.
Аутентификация процесс действительно не прерывает, а вот если пользователь не зарегистрирован, то выбирать маршрут-дату-поезд-вагоны придётся заново.
Хорошо хоть у конкретного пользователя этот провал происходит один-единственный раз (потом уже будут реквизиты доступа).
Позитивным, да не очень, к сожалению.
Аутентификация процесс действительно не прерывает, а вот если пользователь не зарегистрирован, то выбирать маршрут-дату-поезд-вагоны придётся заново.
Хорошо хоть у конкретного пользователя этот провал происходит один-единственный раз (потом уже будут реквизиты доступа).
До сих пор не могу понять какое отношение имеет 03 и 12 к Январю
А еще не надо запрещать ввод данных карты копированием, и уж точно не разделять серии цифр карты на разные поля.
Спасибо, отличные вводные. О проектировании платежной странице расскажем в следующем посте.
А расскажите еще, зачем у меня изредка просят наименование банка, выдавшего карту(!). Исходя из того, что это встречается на одной из десятка сайтов, необходимости в этом никакой нет.
И еще о том, почему никто не проверяет имя-фамилию(я вводил два года на сайтах ZAYTSEV, а потом внезапно обнаружил, что на карте ZAYTCEV. проблем с оплатой не было ни разу).
И почему некоторые сайты заставляют выбирать тип карты(виза/мастер), хотя это определяется парой строчек кода по первой цифре номера. Более того, они это определяют, и говорят, что я выбрал неверный тип карты! Откуда берутся такие альтернативно умные люди, которые в состоянии сделать проверку на корректный тип и выдать сообщение, но не могут сделать просто тихое определение типа карты(если он им зачем-то нужен).
И еще о том, почему никто не проверяет имя-фамилию(я вводил два года на сайтах ZAYTSEV, а потом внезапно обнаружил, что на карте ZAYTCEV. проблем с оплатой не было ни разу).
И почему некоторые сайты заставляют выбирать тип карты(виза/мастер), хотя это определяется парой строчек кода по первой цифре номера. Более того, они это определяют, и говорят, что я выбрал неверный тип карты! Откуда берутся такие альтернативно умные люди, которые в состоянии сделать проверку на корректный тип и выдать сообщение, но не могут сделать просто тихое определение типа карты(если он им зачем-то нужен).
Влад, эмитента спрашивают для последующей сверки с данными, полученными при самой транзакции, это один из доисторических методов противодействия фроду. Мы так не делаем, но коллеги по цеху все еще спрашивают, вы правы. Что касается кардхолдера, это тоже в основном информационное поле, которое не влияет на прохождение транзакции.
А как его сравнивают? Вручную? Нет же никаких правил, как вводить это название. Альфабанк, альфа, альфа-банк, Альфа Банк, Alfabank, Alfa-Bank, alfa-banc, куча вариантов же есть написания одного и того же банка.
Да, вручную. Например если транзакция «выпала» на ручной мониторинг, т.е. у автоматический фильтров сложилось подозрение, что это потенциальный фрод. Риск менеджер смотрит поля транзакции. Там куча факторов, например если форму заполнили за 0.1 секунду, это вероятно робот. Запрет на копирование делается с аналогичной целью.
Если робот не потрудился заполнить поле эмитента, или заполнил его какими-то шаблонными данными, это тоже вызывает подозрения.
Если робот не потрудился заполнить поле эмитента, или заполнил его какими-то шаблонными данными, это тоже вызывает подозрения.
> ввод данных карты копированием
Думается мне, это не очень хорошая идея (если у вас, конечно, не чистится буфер копирования автоматом). Неосторожный пользователь может потом эти данные вставить куда-то не туда.
Отсюда же и растут ноги разделения цифр в номере карты — их визуально так удобнее заполнять и проверять перед отправкой.
Думается мне, это не очень хорошая идея (если у вас, конечно, не чистится буфер копирования автоматом). Неосторожный пользователь может потом эти данные вставить куда-то не туда.
Отсюда же и растут ноги разделения цифр в номере карты — их визуально так удобнее заполнять и проверять перед отправкой.
А может я сам буду решать, какие данные в моем буфере — хорошая идея, а какие — нет? Я имею ввиду, что если пользователь хочет вставить номер карты, а не ввести его вручную — то он уже есть у него на компе в электронном виде. Более того, он уже и есть у него в буфере обмена, потому что он его уже скопировал из файлика/хранилища паролей и попытался вставить в поле на сайте. А тут раз, и не вставилось. Пользователь бесится, потому что ему надо вставлять длинный номер куда-нибудь(например в адресную строку браузера, которая ближе всего), и копировать по 4 цифры. А если там вообще запрещено копирование, то и вводить вручную. Номер из буфера обмена по прежнему никуда не девается.
А это уже проблемы верстальщика. Можно прекрасно сделать и в одном поле средствами JS/HTML/CSS разделение по 4 цифры, и выглядеть это будет красиво и понятно.
их визуально так удобнее заполнять и проверять перед отправкой.
А это уже проблемы верстальщика. Можно прекрасно сделать и в одном поле средствами JS/HTML/CSS разделение по 4 цифры, и выглядеть это будет красиво и понятно.
Ну вот вы можете это решить, а 95% пользователей — нет. И у них нет никаких зашифрованных хранилищ, а есть карты в кошельке.
Мне и самому было бы удобнее так (для оплаты пользуюсь исключительно вирт. картами).
Мне и самому было бы удобнее так (для оплаты пользуюсь исключительно вирт. картами).
И у них нет никаких зашифрованных хранилищ, а есть карты в кошельке.
Так этих пользователей оно и не коснется — они же не будут вставлять по определению, потому что у них карта реальная, и они будут вводить цифру за цифрой. Запретить копирование из формы — пожалуйста, не жалко. Но зачем вставку запрещать?
UPD: выше ответили, почему. Один из факторов, которые повышают «доверие» к транзакции.
---> А еще не надо запрещать ввод данных карты копированием
Это один из методом анти-кардинга. Если копипаст, велика вероятность мошенничества, данные карты предполагаются берущимися из блокнота, экселя, аськи, жаббера итд итп. Против этого на кард-форумах программы выкладывают, которые ручной ввод имитируют. Не всё так просто.
Это один из методом анти-кардинга. Если копипаст, велика вероятность мошенничества, данные карты предполагаются берущимися из блокнота, экселя, аськи, жаббера итд итп. Против этого на кард-форумах программы выкладывают, которые ручной ввод имитируют. Не всё так просто.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
7 типичных ошибок при проектировании процесса чекаута