Дмитрий Коваленко, Head of Product Design в Readdle, дизайнер Fluix (SaaS), SparkMailApp и PDFexpert5, подробно проанализировал проблемы checkout форм популярных сервисов и поделился секретами по их улучшению. Telegraf публикует перевод последней из четырех его статей, посвященных этому вопросу.

Упрощение оформления заказа. 4/4

Fluix от Readdle. Checkout форма. Информация о кредитной карте.

Краткое резюме.

Глава №1.  Мы рассмотрели болезненную проблему checkout процесса разных сервисов.

Глава №2. Здесь собраны 16 обязательных правил для создания лучшего опыта заполнения формы.

Глава №3. Описания процесса создания checkout формы для Fluix, с полезными инсайтами; ограничения для соответствующих полей валидации разных полей и зависимостей между ними.

Глава №4. В этой главе мы разберемся, как определять и проверять номер карты; за что и какая часть номера отвечает; какая разница между CVV/CVN2/CID/ и т.п.

13. Подтверждение

Когда пользователь заполнил все поля мы активируем кнопку следующего шага, которая называется:

«Перейти к информации о карте», если методом оплаты выбрана банковская карта.

«Отправить», если метод оплаты выбран ACH/Wire Transfer.

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

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

Конечно, это ни одной из сторон не выгодно.

Решение оказалось довольно хитрым.  Я вовсе убрал чек-бокс и изменил текст сообщения о подтверждении на следующий: «Нажимая на кнопку «Продолжить» от имени Покупателя, вы соглашаетесь с тем, что…». По сути, с нажатие на «Продолжить» покупатель автоматически соглашается с упомянутыми условиями и соглашениями. Но важно это сообщение разместить прямо над кнопкой подтверждения, чтобы респондент не упустил его из виду.

Сейчас такой подход все чаще используется.

Информация о банковской карте

Форма с информацией о банковской карте. Fluix

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

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

Теперь давайте рассмотрим все в деталях.

Сверху бокса «Информация о карте» пользователь видит финальную  цену, которую он должен заплатить. Критически важно указывать такую информацию, особенно для B2B. Естественно, из-за высоких ценников.

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

На данный момент, мы пользуемся Stripe API, поэтому принимаем те же типы карт, что и они: Visa, MasterCard, AmericanExpress, JCB, Discover, and Diner’s Club. Все.

Теперь о полях.

14. Номер карты

Сразу после нажатия кнопки «Продолжить», автоматически активируется поле «Номер карты». Так пользователь беспрепятственно продолжает заполнение формы без дополнительных кликов.

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

Первая цифра — это Главный отраслевый идентификатор (Major Industry Identifier (MII)). Он представляет категорию структуры, которая выпустила карту.

0 → ISO/TC 68 и другие отраслевые предназначения

1 → Авиалинии

2 → Авиалинии и другие отраслевые предназначения

3 → Путешествия и развлечения (AmericanExpress, Diner’s Club, JCB, Carte Blanche)

4 → Банкинг и финансы (VISA и соотносящиеся/партнерсике бренды)

5 → Банкинг и финансы (Mastercard, Maestro)

6 → Мерчендайзинг и банкинг (Discover, Solo, Switch, China UnionPay)

7 → Нефтяная промышленность

8 → Телекоммуникации и другие отраслевые предназначения

9 → Государственные предназначения

Как вы, наверное, уже догадались,

в большинстве случаев уже по первой цифре вы можете правильно определить тип карты. Это значит, что нет смысла просить респондента выбирать  его вручную!

Первые 6 цифр (включая MII) определяют точного производителя карты. Да, это 1 миллион возможных эмитентов  карт. Но попытайтесь представить, сколько разных банков существует в мире, и вы поймете, что это число не так уж и велико.

Начиная с 7й цифры и заканчивая предпоследней включительно (с 7 до (n-1)), используются для определения личного счета.

У самых популярных типах карт и тех, которые поддерживаются на нашем сервисе (Visa, MasterCard, JCB, Diner’s Club, American Express, Discover) максимальная длина номера составляла 19 цифр. Для определения номера личного счета остается до 12 цифр. Это триллион возможных вариантов.

Последняя цифра номера карты нужна для валидации номера счета по LUHN Formula. Она называется чек-сумма.

Что это значит для нас?

Уже по 1-й (в редких случаях 2-м или 4-м) цифре мы можем определить тип карты.

Visa ← 4

MasterCard ← 51–55

AmericanExpress ← 34, 37

Diner’s Club ← 300–305, 36, 38

Discover ← 6011, 65

JCB ← 2131, 1800, 35

По определенному типу карты мы знаем:

1. Длину номера карты→ мы можем автоматически сместить фокус на следующее поле в нужный момент;
2. Формат номера карты→ мы можем использовать автоформатирование и вставить пробелы между блоками цифр, чтобы помочь респонденту;
3. Логотип типа карты → мы можем вставить его в поле и сразу предоставить респонденту фидбек: визуально уверить, что система успешно определила тип его карты.

Как я упоминал ранее, мы используем Stripe API, который поддерживает только самые популярные типы карт.

Поэтому у нас номер карты должен начинается с 1 или 2 (только для JCB) или 3-6. Если респондент введет любую другую цифру, мы должны сразу же сообщить, что его карта не принимается и он не может продолжить.

Ограничения

1. Обязательное для заполнения
2. Только цифры
3. Номер должен начинаться с 1, 2, 3, 4, 5 или 6
4. Длина: 16 цифр (15 для AmericanExpress)
5. Валидация:
   Visa: ^4[0–9]{6,}$
   MasterCard: ^5[1–5][0–9]{5,}$
   AmericanExpress: ^3[47][0–9]{5,}$
   Diners Club: ^3(?:0[0–5]|[68][0–9])[0–9]{4,}$
   Discover: ^6(?:011|5[0–9]{2})[0–9]{3,}$
   JCB: ^(?:2131|1800|35[0–9]{3})[0–9]{3,}$
6.  Определение типа карты:
   Visa: 4
   MasterCard: 51–55 (но есть и другие случаи)
   AmericanExpress: 34, 37
   Diner’s Club: 300–305, 36, 38
   Discover: 6011, 65
   JCB: 1800, 2131, 35
7. Автоформатирование: пробел после каждого блока с 4 цифрами
8. Автоматическое переключение на поле «Срок действия» после того, как были введены все 16 цифр  (15 для American Express).

 15. Срок действия карты

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

• Один с перечнем месяцев, написанных в полном текстовом формате (т.е. Январь, Февраль, Март, …)
• Другой с перечнем годов в формате из 4 цифр (т.е. 1900, 1901, 1902…) ?

Этот вариант нереально запутывает, потому что у срока действия карты, слава Богу,  одинаковый формат на всех типах карт: 2 цифры месяца и 2 цифры года. Все. И никаких буквенных символов здесь!

Да, есть много людей, которые просто не могут работать с клавиатурой или же им очень сложно это делать в силу ограниченных возможностей. Им нужна опция ввода данных только с помощью  трекболла или трекпэда. И выпадающие списки могут стать для них хорошим решением. Но не нужно убивать опыт использования для других людей и ограничивать их в источнике ввода данных. Вместо этого, используйте стандартное текстовое поле В СОЧЕТАНИИ с выпадающим списком. Можете организовать в такой же способ и селектор страны, например.

Ограничители

1. Обязательное для заполнения
2. Только цифры + пробел и слэш “/”
3. Автоформатирование: MM / YY (пробел+дэш+пробел вставляется автоматически)
4.  Длина: 2 цифры для месяца + 2 цифры для года.
5. Автоматическое переключение фокуса на поле «Код безопасности».

16. Код безопасности

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

VISA → CVV2 (Card Verification Value 2)

MasterCard → CVC2 (Card Validation Code)

Discover → CID (Card Identification Number)

AMEX → CID or 4DBC (4-цифры…)

Elo → CVE (Elo Verification Code)

UnionPay → CVN2 (Card Validation Number 2)

WTF? Они в своем уме?.. ?

Чтобы не сбивать с толку наших клиентов, я использую общее название «Код безопасности» (Secure code). Наиболее подходящий и понятный вариант.

Чтобы помочь респонденту, я использую подсказку, как найти код безопасности на карте в 3 вариациях:

• Если тип карты определен→ подсказка подбирается для соответствующей карты.
• Если не определен→ подсказка для двух вариантов.

Код безопасности, как и пароли, почти всегда спрятан под знаками «***». Есть смысл добавить функцию «Показать/скрыть код», чтобы уменьшить количество отказов.

Ограничения

• Обязательной для заполення
• Только цифры
• Длина: 4-цифры для AMEX, 3 — для всех остальных
• Автоматический переход на поля «Имя на карте».

17. Имя на карте

Есть смысл назвать это поле «Имя на карте», вместо «Владелец карты» или других персонифицированных именований  из-за особенностей  B2B рынка. В этом случае, респондент  не обязательно является владельцем карты, как это бывает на рынке потребительских товаров. Здесь заполнять форму может секретарь или ассистент.

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

С 2014 года, VISA and MasterCard сократили  максимальное количество символов, отведенное на имя владельца карты до 21 и 22 символов соответственно. В силу того, что поле «Имя на карте» находится в конце, мы уже знаем тип карты. Так что могли бы использовать это, как ограничитель для максимального количества символов . Но, конечно, этого делать не стоит, потому что могут использоваться карты более старого образца с длинными именами. Я ввел ограничение на 40 символов.

Ограничения

1. Обязательное для заполнения
2. Input: только буквы и пробел
3. Минимальная длина: 2 символа
4. Максимальная длина: 40 символов
5. Автоформат: верхний регистр (для визуального соответствия  между именем, напечатанным на карте, и набранным в поле).

Есть нюанс в том, почему поле «Имя на карте» стоит последним.

Это поле требует подтверждения ввода, потому что не имеет фиксированной длины. Может быть введено 5 или 15 символов, или больше. И все буквенные. Другие поля — Номер Карты, Срок Действия, Код Безопасности — наоборот, имеют точное количество символов и все они только цифровые. Поэтому мы можем автоматически переключать фокус на следующее поле, когда в текущее  будет введено нужное количество символов. Тогда респонденту, в процессе заполнения формы, не придется переключаться между мышкой (или трекпэдом) и клавиатурой . Плавный процесс заполнения.

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

ZIP код

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

Кстати, респондент уже «прошел» валидацию, когда залогинился в пробной учетной записи.

Валидация карты

Информация по карте проверяется в 2 шага:

1. Со стороны клиента, через чек-суммы с LUHN Algorithm перед любым подтверждением → это уже по части фронт-енда.
2. Со стороны банка, верификация самой кредитной карты после того, как запрос был отправлен на сервер/банк → это по части бэк-енда.

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

Когда валидация завершилась, мы, в зависимости от ответа со стороны сервера:

• В случае завершения операции → отображаем сообщение об успешном завершении процесса и в через  10 секунд редиректим его автоматически в секцию «Расчет»
• В случае отказа → отображаем понятное и четкое сообщение об ошибке, описываем, что конкретно произошло и активируем поля с информацией о кредитной карте.

Надеюсь, эта информация поможет вам при проектирование ваших форм оплаты, которые будут удобны и понятны для всех нас!

Меня можно найти в Twitter, Behance, Medium.

Референсы

Ресурсы, обязательны к прочтению

1. Baymard Institute Blog
2. Nielsen Norman Group
3. A List Apart
4. Luke Wroblewski

Сортированы по теме (все, что удалось вспомнить)

1. Обязательныей и опциональные поля
   http://static.lukew.com/webforms_lukew.pdf (страница 28)
   http://baymard.com/blog/required-optional-form-fields
   https://www.youtube.com/watch?v=ySfV919ajqI
2. Встроенная валидация в формах
   http://alistapart.com/article/inline-validation-in-web-forms
   https://baymard.com/blog/adaptive-validation-error-messages
3. Общие подсказки и советы
   https://www.smashingmagazine.com/2009/05/12-tips-for-designing-an-excellent-checkout-process/
   https://www.nngroup.com/articles/web-form-design/
   https://www.nngroup.com/reports/ecommerce-ux-shopping-carts-checkout-registration/
   https://www.nngroup.com/articles/form-design-placeholders/
   https://www.nngroup.com/articles/form-design-white-space/
   https://baymard.com/blog/accordion-checkout-usability
4. Информация о кредитной карте
   https://www.dalpay.com/en/support/card_security_code.html
   http://stackoverflow.com/questions/72768/how-do-you-detect-credit-card-type-based-on-number
   https://medium.com/user-experience-design-1/the-anatomy-of-a-credit-card-payment-form-32ec0e5708bb
   https://en.wikipedia.org/wiki/ISO/IEC_7813
   https://baymard.com/blog/credit-card-field-auto-format-spaces
   http://mahercreditcard.blogspot.com/
5. Поле «Имя»
   http://stackoverflow.com/questions/30485/what-is-a-reasonable-length-limit-on-person-name-fields
6. Поле «Адрес»
   http://baymard.com/blog/address-line-2
   http://stackoverflow.com/questions/134956/how-do-you-perform-address-validation
7. Номер телефона
   http://formvalidation.io/validators/phone/
   https://en.wikipedia.org/wiki/List_of_country_calling_codes
   https://countrycode.org
8. Селектор страны
   https://baymard.com/labs/country-selector
   http://www.freeformatter.com/iso-country-list-html-select.html
   https://www.smashingmagazine.com/2011/11/redesigning-the-country-selector/
9. Почтовый индекс
   https://baymard.com/blog/zip-code-auto-detection
   https://en.wikipedia.org/wiki/Postal_Index_Number
   http://www.makani.ae/desktop/index.html
10. Кредитная карта
    http://www.dirigodev.com/blog/ecommerce/anatomy-of-a-credit-card-number/
    https://medium.com/r/?url=http%3A%2F%2Fcunorthwest.com%2Fvisamastercard-to-shorten-cardholder-name-field%2F
    http://mahercreditcard.blogspot.com/
11. Номер телефона
    http://jxnblk.com/colorable/demos/text/
    https://snook.ca/technical/colour_contrast/colour.html
    https://bjango.com/designresources/

Особая благодарность:
Габриелю Томеску за статью «Структура информации о кредитной карте».
Люку Вроблевскому за доступ к его исследованиям и идеям. Всем, кто прочитал статью и за аплодисменты на Medium.

Начало статьи (3-я часть из цикла статей о дизайне форм) «Проектирование checkout формы: Закулисье. Часть II».

1-я часть из цикла статей о дизайне форм — «Почему покупка онлайн настолько сложный процесс?»

2-я часть из цикла статей о дизайне форм — «16 принципов, который упростят заполнение любой формы».

С оригиналом статьи можно ознакомится по ссылке.

Перевод — Павлевич Катя.