Сервис для перевода денег между картами. Часть 1

Хай, в целях прокачки своего скила переделываю одну страницу под мобильные девайсы. Это сервис для перевода денег между картами. Имеется возможность перевода на карту или по номеру телефона. Как мне лучше это отобразить в строке инпута? Правильно ли я делаю? А как моя подсказка работает? Как сделать форму ещё более доступной? Спасибо!

Борис, в первой части я перечислю проблемы в вашем макете и соберу свою версию. Для начала я пойду прямолинейным путём к простому интерфейсу, а во второй части совета доработаю его и сделаю умнее.

Проблемы

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

Смущает гигантская кнопка «Очистить всё». Представьте, что кто‑то случайно на неё нажмёт и сотрёт всё, что тщательно вводил. Подобные элементы могут быть источником ошибок, их нужно убирать.

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

Первый вариант редизайна

Добавим радиокнопки и раскидаем якорные объекты по разным сторонам экрана:

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

Бывают карты с номерами, разделёнными на группы по другим принципам, например, Американ Экспресс. Будет идеально, если учесть все варианты в интерфейсе. Если бы я проектировал интерфейс, то изучил бы эту тему глубже

При заполнении номера карты хорошо бы, чтобы интерфейс делил его на группы по четыре цифры.

Бывают карты с номерами, разделёнными на группы по другим принципам, например, Американ Экспресс. Будет идеально, если учесть все варианты в интерфейсе. Если бы я проектировал интерфейс, то изучил бы эту тему глубже

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

Не забудем добавить подсказку в поле «CVC 2 / CVV 2» и написать про комиссию:

В подобных формах важно не заставлять повторно вводить реквизиты при следующем использовании сервиса. Форма должна запоминать введённые реквизиты и предлагать их

Основа макета готова. Теперь нужно нарисовать состояние при переводе по номеру телефона и не забыть придать макету вид настоящего сервиса: добавить главное меню, логотип сервиса и платёжных систем, соглашение с условиями оферты и так далее.

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

  • если в полях «Карта отправителя» и «Карта получателя» ввести один и тот же номер?

  • у карты закончился срок действия?

  • написать в полях какую‑нибудь ерунду?

  • введённая сумма больше или меньше разрешённой?

  • ввести номер телефона, к которому привязано несколько карточек или, наоборот, ни одной?

Недостатки первого варианта

Теперь рассмотрим недостатки получившегося решения с радиокнопками:

  1. Модальность и модальные ошибки. Представьте ситуацию, что человек не заметил, какая радиокнопка выбрана, то есть какой режим интерфейса включён, и ввёл телефон в поле для карты или наоборот. После этого дорога дальше в интерфейсе закроется и придётся переключить режим. Такая ошибка называется модальной. Подробно о проблемах режимов пишет Джеф Раскин в третьей главе своей книги.

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

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

  4. Нет возможности перевести деньги с карты на телефон или с телефона на карту.

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

Приглашаю уважаемых советчиков предлагать свои варианты макета в комментариях. Мой макет можно забрать в Фигме. Чтобы сделать копию макета и редактировать её, создайте аккаунт, нажмите на стрелочку возле названия документа и выберите Duplicate to your Drafts.

P. S. Это был вторничный совет о дизайне интерфейсов. Присылайте вопросы.

Интерфейс
Отправить
Поделиться
Запинить

Комментарии

По стандартам платёжных систем имя владельца карты — необязательное поле. Если его убрать, форма станет компактнее.

11 фев 2020
  1. Как уже написал Александр, имя владельца — необязательное поле для локальных переводов. С другой стороны, для международных переводов должны быть Имя, Город и Адрес получателя (при переводе за границу) или отправителя (при переводы из‑за границы). Страна подтянется автоматически платежной системой. Интерфейс станет более громоздким. Добро пожаловать в длинные банковские формы :‑)

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

  3. Комиссия может отличаться от направления переводов: между картами одного банка, внутри страны, международные. Кроме того, есть лимиты на количество транзакций в день/месяц и лимиты на сумму в день/месяц. Тарифы пользователи хотят увидеть сами и ищут их на экране. А о лимитах просто неплохо бы где‑то сказать. Да, это тоже нагружает интерфейс.

11 фев 2020

Поле для ввода реквизитов карты отправителя можно собрать в одно. У Тинькова можно подсмотреть пример.

Я думал, как решить модальность предложенного решения:
Можно научить бекенд проверять поле ввода номера карты и телефона на длину символов. Длина номера карточки может быть от 14 до 19 цифр, а длина мобильного номера — до 11 цифр. Но, к сожалению, велика вероятность, что клиент введёт номер карты, а система посчитает её за номер телефона. И использовать алгоритм, который по первым цифрам определит принадлежность карты, в этом случае не получится: коды мобильных в некоторых странах совпадают с началом номеров карт.

Один из вариантов — это два пункта меню ещё до попадания на текущий экран. Например:
Переводы → Банковский перевод / С карты на карту / По номеру телефона / ...

11 фев 2020

Юрий, карта это или нет, поможет узнать контрольный алгоритм Луна:
https://ru.wikipedia.org/wiki/Алгоритм_Луна

12 фев 2020

ФИ на картах обычно написаны прописными буквами.

22 фев 2020

Рекомендуем другие советы