Школа
Интерфейс

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

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

Борис Женихов
11 фев 2020
👁 7546   🗩5
Интерфейс

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

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

Борис Женихов
11 фев 2020
👁 7546   🗩5
Константин Мозговой
Дизайнер бюро
Полезно
Непонятно
Войдите в Бюросферу, чтобы голосовать

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

Проблемы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интерфейс
Полезно
Непонятно
Войдите в Бюросферу, чтобы голосовать
Отправить
Поделиться
Поделиться
Запинить
Твитнуть

Комментариев пока нет

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

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