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

---

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

Fluix от Readdle. Checkout форма. 

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

В первой я описал проблему процессов оплаты.

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

Из этой же части вы узнаете, как правильно валидировать  каждое поле; как уменьшить количество ошибок, которые может сделать респондент; как различия между рынками B2C и B2B влияют на дизайн; как использовать вводные и визуальные ограничения для полей; и много других “Why and How”.

Крепитесь. Это длинная статья ??

Поехали.
Почти 6 месяцев назад я столкнулся с такими вопросами:

• Как спроектировать процесс оформления заказа в форме из 15 полей для B2B продукта — Fluix? Как это должно работать?
• Как сделать процесс четким и понятным для респондента?
• Как я могу упростить его, но все же сделать достаточно информативным и получать необходимые данные от респондента?
• Как повысить “success rate” и сократить время заполнения?
• Как свести к минимуму количество сомнений, вопросов, которые могут возникнуть у пользователя при заполнении формы?
• Как заставить респондента чувствовать себя комфортно и быть довольным от процесса оформления заказа?
• Какие есть локальные различия между странами / народами / языками? Какие из них мне следует учесть?
• Есть ли разница между рынками B2C и B2B? Если да, то как это влияет на дизайн? Как мне их учесть?

Я углубился в исследование, чтобы найти ответы на эти вопросы. Прочитал много аналитических материалов, статей, спецификаций; исследовал много разных  checkout процессов популярных и не очень интернет-магазинов; проанализировал их дизайн, преимущества и недостатки, которые описал в первой статье.

В результате я полностью переделал весь checkout flow и саму форму. Кроме того, написал 7 страниц документации для нашей команды разработчиков, где было описано:

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

Как, возможно, вы догадались, я собираюсь поделиться всеми этим инсайтами с вами, здесь.

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

Немного контекста для лучшего понимания флоу.

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

• Полное имя
• Название компании
• Номер телефона
• Электронный адрес

Поэтому мы можем предварительно заполнить соответствующие поля на этапе оформления заказа, чтобы упростить работу респондента (принцип № 2, помните?). Но есть несколько подводных камней в силу специфики рынка B2B. Я расскажу вам больше о них дальше.

Структура

Checkout форма Fluix.  5 смысловых зон.  

Саму форму можно разделить следующим образом:

1.Настройка оплаты

1.1. Название выбранного плана

1.2. Количество пользователей

1.3. Способ оплаты

1.4. Период оплаты

2. Данные плательщика :

2.1. Название компании

2.2. Полное имя

2,3. Электронный адрес

2,4. Номер телефона

3. Полный адрес:

3.1. Страна

3.2. Почтовый индекс

3.3. Город + штат (для США)

3.4. Адрес

4. Сводный блок со всеми расчетами и итоговой ценой

5. Кнопка подтверждения и ссылка на пользовательское соглашение

6. Информация о банковской карте (зависит от выбранного типа оплаты)

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

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

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

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

С первого взгляда в этих полях нет ничего особенного, верно? Но давайте погрузимся в детали каждого из них. Вероятно, вы будете немного удивлены.

1. Количество пользователей

В моей первой итерации я использовал сегментированный контроль , чтобы избежать текстового поля и дать респонденту возможность выбирать количество пользователей в один клик. Я использовал следующую сегментацию: 1-10, 11-50, 51-100, 101-200 и “Exact Amount, чтобы при необходимости, клиент мог установить точное количество пользователей.
В нашем случае есть несколько проблем с таким контролем:

1. Итоговая стоимость за любой из наших планов, в первую очередь, основана на количестве пользователей в системе. То есть, чем больше пользователей, тем выше стоимость. Следовательно, любой клиент, который заботиться о своем бюджете, всегда будет указывать точное количество пользователей. Поэтому  нет необходимости в подобном сегментировании, который ограничивает пользователя, а не ускоряет процесс.
2. Как я уже упоминал выше, текущий шаг — это оформление подписки на этапе, когда у клиента уже есть триал-аккаунт, который зарегистрировал для тестирования продукта перед покупкой. Следовательно, в системе уже наверняка есть настроенные и активные пользователи. Поэтому мы должны как-то отобразить эту информацию. Также технически мы не позволили клиенту установить меньшее количество пользователей, чем у него уже есть.
3. По сути, этот сегментированный контрол  добавляет 5 интерактивных элементов на экран вместо 1 текстового поля. Чем больше объектов на экране, тем выше когнитивная нагрузка на мозг. Следовательно, требуется больше времени, чтобы сконцентрироваться и дать правильный ответ. В контексте данной формы, это особенно актуально, поскольку “Number of Users” — первый вопрос в форме

После нескольких итераций, я пришел к обычному текстовому полю, но в сочетании со стэпперами.

Преимущества такого подхода

Благодаря стэпперу можно легко добавить несколько пользователей, прибегая к меньшему количеству действий и временных затрат, чем при использовании текстового поля. Например, предположим, что 20 пользователей уже сконфигурированы в системе. . Общее количество пользователей после оформления подписки должно быть 24. В этом случае клиент должен просто 4 раза нажать на кнопку «+», НО без изменения источника ввода (мышь / трекпад > клавиатура). Возможно, даже не переводя глаза с дисплея на клавиатуру.

Кроме того, это будет более простым решением для пожилых людей, которым нужно просто оформить и оплатить подписку.

В случаях, когда необходимое количество пользователей существенно отличается от значения в поле, клиент может легко ввести точное значение.

Ограничения:

1. Обязательно для заполнения. Это очевидно, ведь итоговая цена подписки зависит от количества пользователей.
2. Input: только цифры. Нет необходимости вводить буквы или другие символы. Следовательно, разрешен ввод только цифр 0-9.
3. Минимальное значение — 5. Мы не разрешаем настраивать план с меньшим количеством пользователей.
4. Максимальное значение – 9999. Будем честными, никто не будет покупать больше 10 тыс. пользователей за раз.
5. Устанавливаемое количество пользователей должно быть больше, чем уже сконфигурировано. Все потому что на них уже могут быть «завязаны» документы, которые просто так мы удалить не имеем права.
6. Кнопки “—”,  “+”
   6.1. деактивированы, если нельзя  увеличить или уменьшить значение
   6.2. Единичный шаг — один клик, один пользователь

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

2. Способ и период оплаты

Из-за специфики B2B рынка, многие компании требуют способ оплаты ACH/Wire Transfer. Поэтому и мы должны поддерживать его. Но он используется только для ежеквартальных и годовых платежных периодов. Вот почему селектор периода оплаты находится под способом.

После множества итераций я пришел к сегментированному контролу для выбора периода и способа оплаты. Всего 2 клика — и все выбрано.

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

Ограничения и зависимости:

• Банковская карта → доступный любой период оплаты

• Банковская карта → надпись на кнопке подтверждения «Перейти к информации о карте»

• ACH / Денежный перевод → Только квартальные / годовые платежные периоды

• ACH / Денежный перевод → надпись на кнопке подтверждения «Отправить платеж»

• Влияет на итоговую сумму  в режиме реального времени.

Информация об оплате

При регистрации пробного аккаунта, клиент должен заполнить следующие обязательные поля:

•  Электронный адрес
•  Полное имя
•  Номер телефона
•  Название компании

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

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

3. Название компании

Название компании является важной информацией для нас. Мы должны знать отрасль, из которой пришел клиент, и соответствующе оптимизировать наши процессы продажи.

С психологической  точки зрения, если вы хотите «подмазаться» к клиенту, локализуйте также подсказки внутри полей. Например, если клиент из Швеции, то  подсказками для поля «Название компании» могут быть, например, Volvo или Spotify. Обе компании из Швеции.

Конечно, вы не можете это делать для всех 196 стран мира,  но:

• я уверен, что ваш B2B продукт не нацелен на весь мир;
• вы можете разделить страны на семантические группы, такие как Европа, США + Канада, Азия и т. д.

Ограничения

• Обязательно для заполнения

• Предварительно заполнены (данные из триал-аккаунта )

• Input: все символы разрешены

• Placeholders: зависимость от страны . Например, Apple (для США), Volvo (для Швеции), Fly Norwegian (для Норвегии), BMW (для Европы), Siemens (для всех остальных).

• Минимальная длина: 2 символа

• Максимальная длина: 60 символов. На данный момент, эта цифра достаточно эмпирическая, потому что у нас много клиентов из скандинавских стран и Германии. Следовательно, мы должны рассчитывать на действительно длинные названия.

4. Полное имя

Именно в нашем случае я не разделяю ФИО на 3 отдельных поля (First / Given / Fore-, Middle, Last / Family Name), потому что для нас не важно разделять имя и фамилию. Но вот что важно здесь. Я сохранил однострочное отображение полного имени. Потому что для нас полное имя — это единое понятие. Если я попрошу вас написать его на пустой странице, вы сделаете это в одной строке без переносов, не так ли?

Да, в некоторых случаях вам, возможно, нужно четко различать имя и фамилию. И самый простой способ сделать это — использовать два и больше полей. Но это не очень хорошо с точки зрения UX. Как минимум, потому что это еще один дополнительный вопрос, поле, клик и т.д.

Конечно, вы можете использовать пробел между словами в качестве триггера. Например, «Джон¶Смит», где ¶ — естественный делитель. Но проблема в том, что вы не можете быть уверены, что респондент обязательно укажет первым словом свое имя, а вторым — фамилию. . Это особенно острый вопрос с пользователями с двойными или даже тройными именами, как Джонатан Бенджамин Кристофер Смит.

Ограничения

• Предварительно заполнено (данные взяты из триал-аккаунт)

• Input: разрешены только буквенные символы, пробел, дефис, точка.

• Максимальная длина: 70 символов (по каталогу UK Gov.Data Standards)

• Минимальная длина: 3 символа (не менее 2 букв, или 1 буква +1 пробел + еще 1 буква после (например, Samuel L.))

5. E-mail

Часто вам, как поставщику услуг, уже известна электронная почта клиента. Он может попасть в вашу checkout форму из email рассылки или пробной учетной записи, как в нашем случае. Следовательно, вы также можете заполнить это поле наперед.

Ограничения

•предварительно заполнено (данные взяты из триал-аккаунт)

• обязательно для заполнения

• Input: 255 символов

• валидация: проверка на уровне браузера или используйте js-паттерн. (/^[a-zA-Z0-9.!#$%&’*+/=?^_`{|}~-]+@[a-zA- Z0-9 -] + (?:. [A-Za-Z0-9 -] +) * $ /)

6. Номер телефона

Большинство онлайн-сервисов могут запрашивать номер телефона в качестве дополнительной информации. В нашем случае, это важная информация при  оформлении подписки по той же причине, что и название компании. Поскольку люди не ожидают, что им придется указывать номер телефона в обязательном порядке, мы должны объяснить им, почему запрашиваем такую информацию (принцип № 15, помните?). Я скрываю объяснение под иконкой “?”. Но нам предстоит протестировать это решение.  Вероятно, будет лучше вывести эту информацию под поле.

Это поле с автоматическим форматированием. В зависимости от страны, мы соответствующим образом подбираем маску и автоматически вставляем символы (+, дефис, пробел). Поэтому клиенту не нужно думать, как правильно написать номер телефона.

Вот несколько отличных источников, где можно найти все коды стран: https://countrycode.org/ или https://en.wikipedia.org/wiki/List_of_country_calling_codes

Ограничения

• Поле может быть предварительно заполнено (данные взяты из триал-аккуант)

• Обязательно для заполнения

• Автоматическое форматирование

• Валидация: http://formvalidation.io/validators/phone/

7. Страна

Это одно из ключевых полей. Определив страну, вы сможете сразу локализовать форму:

• использовать правильную валюту
• использовать правильную формулировку имен полей
• использовать соответствующие маски и подсказки

Например, ваш клиент из Швеции. Итоговая цена в USD не релевантна для него. Очевидно, будет гораздо удобнее использовать SEK (шведская крона).

Вот список пунктов, которые мы меняем в зависимости от страны:

Надписи:

• ZIP Code(почтовый индекс, США) <> Postal Code (Европа)

• Город, штат <> Город

Подсказки в полях :

• Название компании

• Электронный адрес

• Телефон

• Почтовый индекс

• Город / штат

Маски для:

• Почтового индекса

• Номера телефона

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

Вот основные изменения:

1. АвтодополнениеПерепроектированный селектор стран. Fluix от Readdle.Основным преимуществом является автодополнение со списком вариантов. Это примерно тоже самое, что поиск в Google. Мы показываем список предложений, релевантных тому , что вводит пользователь.
2. Автокоррекция
   Мы также должны учитывать случаи, когда у страны есть два или более названия и разные варианты их написания, включая стандартные 2-х или 3-х буквенные обозначения. Например, Great Britain/England/United Kingdom/UK/GB — все это названия одной и той же страны. В разных местах вы можете встретить разные названия.
3. СписокПерепроектированный селектор стран. Fluix от Readdle.Разумеется, необходимо не забыть и о ручном выборе. Но есть одна коварная ловушка.Сейчас многие сервисы совершают одну и ту же ошибку касательно списка стран. Они ставят наиболее используемые страны без разделения в верхней части списка, который отсортирован в алфавитном порядке. Так, если вы ищете, например, The United Kingdom в списке с алфавитным порядком, то скорей всего проскроллите сразу к букве U. Но вашей страны там нет. Тогда вы подумаете, что авторы указали ее как Great Britain. Прокрутите назад к G и … тот же результат. И только когда вы вернетесь в начало списка, то заметите, что The United Kingdom находится там, сразу после The United States.Или иногда их дублируют сверху.

Я же разделяю список на две части:

– Часто используемые страны (Frequently Used)

– Алфавитный список всех стран (Alphabetical List)

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

Если вы используете jQuery в своем проекте, можете попробовать этот плагин.

Ограничения

• Определение  по IP-адресу. Если не получается определить, используйте умные-стандартные значения (smart defaults), т.е. подставляйте одну из самых популярных стран
• Обязательно для заполнения
• Input : алфавитный, разрешены только пробелы
• При активировании поля, автоматически селектируйте введенное значение  в поле и покажите список стран
• Изменение страны приводит к другим изменениям: смена валюты, названий полей, подсказок, масок, и т.д.
• Сразу после того, как страна была определена/выбрана, автоматически переключите фокус на поле “Почтовый индекс”.
• Вадилация: http://www.freeformatter.com/iso-country-list-html-select.html. Плюс поддержка 2-х и 3-х буквенных аббревиатур .

Теперь давайте перейдем к самому сложному и запутанному полю.

8. Почтовый индекс (ZIP Code / Postcode)

ZIP (Zone Improvement Plan – план почтовых зон) Code  — это система почтовых адресов. Разработана Почтовой службой США в 1963 году. Также существует ZIP+4 код — расширенная система почтовых индексов, которая определяет не только штат, город и район, но и точный номер здания. В США используется ZIP код из 5 или 5+4 цифр.

Канада также использует ZIP Code, но он состоит из 6 буквенных и цифровых символов (например, A1A, 1A1…).

Европа, Ближний Восток ⤑ Postal Code. Код из 3-4 цифр.

Австралия ⤑ Postcode. Код из 3-4 цифр.

Ирландия ⤑ Eircode, или Loc8 Code (неофициальный) (прим. автора)

Бразилия ⤑ CEP (Código de Endereçamento Postal)

Индия ⤑ PIN (Postal Index Number). Только цифры.

ОАЭ ⤑ P.O.Box (Post Box Number). В ближайщем будущем ОАЭ планируют перейти на систему Макани.

Также, советую принять во внимание следующие аббревиатуры, которые используются для клиентов, которые получают 200 и более предметов на Стандартный/Короткий или Длинный автоматический почтовый ящик каждый рабочий день:

• LVR (Large Volume Receiver) — Австралия

• CEDEX (Courrier d’Entreprise à Distribution EXceptionnelle («специальная почта для бизнеса»)) — Франция

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

В нашем случае, 95% рынка — это США и Европа. Поэтому смысла тратить много времени и усилий, чтобы больше изучить другие системы кодов и варианты их поддержки не было. Так что перейдем к следующему вопросу.

Ограничения

1.  США

1.0. Называется ZIP Code или ZIP+4 Code

1.1. Цифры + пробел или дефис (“–”)

1.2. Минимальная длина: 5 цифр

1.3. Максимальная длина: 10 цифр и дефис

1.4. Если пользователь ввел 6 символов (это значит, он напечатает ZIP+4 code), используйте автоформатирование и добавляйте дефис автоматически

1.5. Формат: 12345 (ZIP), 12345–6789 (ZIP+4)

2. Канада

2.0. Называется ZIP Code

2.1. Цифровые и буквенные символы

2.2. Длина: 6 символов + пробел

2.3. Формат: A1A 1A1

3. Норвегия+Швейцария+Германия+Австрия+ЛИхтенштайн (обслуживает Posten):

3.0. Называется Postal Code

3.1. Только цифры

3.2. Длина: 4 цифры

3.3. Формат: 0001

4. Нидерланды

4.0 Называется Postal Code

4.1. Буквы и цифры

4.2. Длина: 6 символов + дефис/пробел

4.3. Формат: NL-1000 (не используют комбинацию букв “SS/SD/SA” из-за ассоциаций с нацистской оккупацией во время Второй мировой Войны).

5. Франция

5.0. Называется Postal Code

5.1. Только цифы

5.2. Длина: 5 цифр

5.3. Формат: 12345

5. Швеция

5.0. Называется Postal Code

5.1. Цифры и пробел

5.2. Длина: 5 цифр и пробел

5.3. Формат: 123 45

6. Великобритания

6.0. Называется Postcode

6.1. Только буквы и цифры

6.2. Минимальная длина: 6 символов

6.3. Максимальная длина: 8 символов

6.4. Формат кода для наружного использования: AN, ANN, AAN, AANN, ANA, AANA и AAA (буквы I и Z не используются во второй альфа позиции (за исключением GIR 0AA))

6.5. Формат кода для использования внутри: всегда NAA (буквы C, I, K, M, O и V никогда не используются)

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

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

 

Как вы могли уже заметить, с помощью  ZIP/Postal коды можно определить город, штат и в некоторых случаях даже точный адрес. Это может очень сильно сэкономить время. Особенно, для стран, где граждане знают свои почтовые индексы достаточно хорошо. Как в Великобритании и США.

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

Так что есть смысл поставить поле ZIP/Postal код сразу после страны и перед названием города, штата и улицы. Так, после введения пользователем индекса, мы можем автоматически определить город, штат и адрес, если речь идет о ZIP+4 коде или полном почтовом индексе.

Например, вот checkout форма Apple. После введения ZIP кода они определяют ваш город и штат, но изначально не дают возможности ввести их отдельно от индекса.

Apple.com. Город и Штат зависят от ZIP Code и могут вводиться вручную только если ZIP Code неправильный.

Кстати, если бы мы проектировали форму для B2C продукта, можно было бы свести все эти 5 полей для указания полного адреса лишь к ZIP/Postol коду.  — ZIP/Postal код.

В любом случае нужно предусмотреть для этих вопросов возможность введения ответа вручную без обязательного указания zip/postal кода вначале. Вы все равно сможете определить его в обратном порядке, при необходимости.

Давайте теперь рассмотрим поля: Город, Штат и Адрес.

10. Город

Взглянем, например, как комбинацию полей ZIP кода, города и штата оформила Apple. Да, снова они. В этом случае из-за «особенного подхода».

Checkout в Apple

Они спрятали поля Город и Штат под ZIP код. Так вы обязаны  сначала ввести индекс, после чего они без проблем определяют город и штат автоматически. Если система не распознает код, они показывают  оба поля, чтобы пользователь мог вручную ввести правильный город и штат.

Apple.com. Город и Штат зависят от ZIP Code и могут вводиться вручную только если ZIP Code неправильный.

Кроме того, при неправильном определении ZIP Code, они меняют его позицию. Ставят на 3-е место, после города и штата, из-за формата адреса  (например, Miami FL, 33131), оставляют в фокусе.
Кстати, они не определяют полный адрес при использовании ZIP+4 кода. Поэтому даже, если вы знаете его, вам придется печатать адрес улицы вручную.

Мне кажется такой подход совсем неудобным по ряду причин:

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

В нашей checkout форме я оставил поля Город и Штат всегда видимыми и активными. Так любой пользователь из любой страны, вне зависимости от того, знает он почтовый индекс или нет, может вручную ввести свой город и штат (в случае с США). Или же исправить их, если произошла ошибка в системе автоопределения.

Ограничения

1. Обязательное для заполнения
2. Буквы, цифры, пробел и дефис разрешены.
3. Минимальная длина: 2 символа
4. Максимальная длина: 24 символа
5. Placeholder: e.g %Country Capital%

В идеальном мире, хорошо было бы сделать поля Страна и Город зависимыми для правильной валидации. Но думаю, что это задание потребовало бы много неоправданных усилий и времени на правильное воплощение.

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

11. Штат

 

Существует два дизайн решения для этих полей:

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

Для проектирования поля Штат, я использовал те же принципы, что и для поля выбора страны: автозаполнение + автокоррекция + выпадающий список со всеми штатами, в случае ручного выбора. Например, если пользователь напишет «orida», он скорей всего подразумевает «Florida». Соответственно, мы предлагаем ему наиболее подходящий вариант.

Штаты в списке указаны в следующем формате: Florida (FL), California (CA), и т.д.

Ограничения

1. Доступно только для США.
2. Минимальная длина: 2 символа
3.  Только буквы
4. Автоформат: 2 буквы, верхний регистр.
5. Валидация http://www.freeformatter.com/usa-state-list-html-select.html
6. Placeholder: e.g. CA

12. Адрес

Поле Адрес тоже не простое. Во многих сервисах вы можете заметить 2 отдельных поля для адреса без стандартизированного названия. Вероятней всего, вы встречали:

• Address Line 1 / Address Line 2
• Address 1 / Address 2
• Street Address 1 / Street Address 2
• Address / no name, etc.

Слева: Amazon. Справа: eBay

Такое деление  и формулировка сбивают с толку респондента (если он только не работает с оформлением заказов  дни напролет). Особенно, это усложняет процесс, если респондент заполняет такую форму впервые. На это есть несколько причин:

Восприятие: всегда создается впечатление, что эти 2 поля для 2 разных адресов. Что первый, вроде как, основной, а второй — дополнительный.

Вызывает такие вопросы:

• Что нужно вписать в первое поле, а что во второе?
• В чем смысл разделять адрес на 2 строки?
• Можно ли все вписать  в первое поле? Или во второе?
• Или продублировать информацию в оба поля?
• Что, если я не заполню второе поле?

И так далее…

Слева: NETATMO. Справа: Apple.com

Главная причина всего вышеперечисленного в том, что мы привыкли видеть, писать и читать наш адрес — название улицы, номер дома и квартиры — как единое целое. Мы переносим на следующую строку  только почтовый индекс, город и страну. И делаем это лишь для лучшего восприятия информации.

Кто-то может предложить сделать 1 большое поле для всего  адреса вместо 5 разделенных. Тогда пользователю будет удобно ввести адрес так, как он привык, не отрывая рук от клавиатуры.

Но и с таким подходом есть проблемы:

• Будет очень трудно вычленить нужную информацию
• Форматы написания адресов отличаются в разных странах
• Выше вероятность того, что респондент допустит ошибку
• Невозможна валидация данных

Так зачем использовать два отдельных поля для ввода адреса?

• Первый для названия улицы, почтового отделения (P.O. box)
• Второй для номера квартиры, офиса, корпуса, здания, этажа и т.п.

Как же быть?? Ребята из Baymard Institute утверждают: если вам действительно нужно знать отдельно название улицы, отдельно номер дома, то оставляйте оба поля, но лейбл ставьте только к первому.. Подпишите ее как Address. Не Address Line. (прим.автора) Но вам все равно нужно как-то пометить второе поле, как опционное.

Чтобы решить, что делать с этими полями в нашей форме, я провел внутреннее исследование. Я хотел понять, как уже имеющиеся клиенты Fluix заполнили поля в нашей текущей форме. И вот, что я обнаружил:

87% из 400 имеющихся клиентов не заполняют вторую строку вообще. 65% вводят в Address Line 1 данные для Address Line 2. Только 7 компаний (7 человек, чтобы быть точными) заполнили Address Line 2. Остальные заполнили ее неправильно или же продублировали информацию с первой строки.

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

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

1. Обязательное для заполнения
2. Все стандартные символы разрешены
3. Минимальная длина: 5 символов
4. Максимальная длина: 120 символов
5. Возможная валидация: http://stackoverflow.com/questions/134956/how-do-you-perform-address-validation

Хорошо, думаю для этой части достаточно ?. В следующей и последней части вы узнаете:

1. Как работает подтверждение
2. Какие хитрости стоят за полями, которые относятся к информации о карте
3. Как легко определять тип карт
4. Почему лучше использовать названия полей «Имя на карте» и «Код безопасности»
5. Какой тип валидации можно применить на этом этапе

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

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

 

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

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

 

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

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