1. Отсутствие маски при вводе номера телефона
Одна из самых старых и часто встречающихся проблем. Приложения, как правило, требуют вводить последовательность из 10 цифр, без кода оператора и разделительных знаков. В типичном случае поле для ввода номера не содержит маски, а под полем расположена подсказка о том, что надо ввести 10 цифр. Наши наблюдения показывают, что такие подсказки не очень полезны, потому что требуют определенных умственных усилий, чтобы вычислить, что в эти 10 цифр входит.
Разные пользователи привыкли вводить номер телефона по разному, начиная с «+7», с восьмерки или вовсе без международного кода, со скобками, с пробелами, с дефисами или без них. Поэтому, даже несмотря на наличие подсказок, некоторые из них начинают вводить номер телефона неправильно и не сразу осознают свою ошибку.
Рекомендация. В полях для ввода номера телефона используйте маску вида +7( )___-__-__. Маска, как правило, снимает вопросы у пользователей, и редко кто делает ошибки при вводе номера телефона в такие поля. В лучших реализациях приложение само исправляет ошибки, например, когда пользователь начинает ввод номера с восьмерки.
2. Неинформативные сообщения об ошибках
Каждый год на юзабилити-тестированиях мы видим проблемные сообщения об ошибках. Как правило, они содержат технические термины, иногда даже написанные латиницей. При этом в них не указывается причина ошибки и способ ее исправления. В совсем грустных случаях сообщение об ошибке располагается над или под формой ввода, так что пользователь даже не может понять, с каким полем оно связано.
Рекомендация. Постарайтесь предусмотреть все возможные проблемы при заполнении и предложить пользователю адекватную помощь, особенно в формах с больших количеством сложных реквизитов:
- располагайте сообщение об ошибке рядом с тем полем, где ошибка возникла;
- избегайте технических терминов;
- в сообщении четко описывайте суть проблемы и, если это не очевидно — способ ее исправления.
3. Неинформативные подсказки
Почти в каждом банковском приложении встречаются проблемы с подсказками в формах. Это:
- отсутствие подсказок там, где необходимо;
- подсказки, дублирующие название поля;
- подсказки с очевидным содержанием;
- подсказки, которые содержат термины, непонятные для пользователей.
Рекомендация. Подсказка должна помогать пользователю правильно заполнить поле. В зависимости от того, какое поле заполняет пользователь, будет полезно разместить в подсказке информацию:
- что означает название поля;
- в каком формате требуется вводить данные (и показать пример правильно введенных данных);
- сколько символов необходимо ввести в поле (в таком случае будет полезно, если количество символов будет подсчитываться автоматически по мере ввода);
- откуда брать данные.
4. Исчезающие подсказки и названия полей
Иногда названия полей или подсказки располагаются внутри поля и пропадают после начала ввода. На юзабилити-тестированиях мы видим, что в таком случае некоторых пользователи быстро забывают содержание подсказки и вводят некорректные данные. Получив сообщение об ошибке, они вынуждены полностью стирать введенное, чтобы снова увидеть подсказку.
Рекомендация. Постарайтесь не располагать подсказку внутри поля. Используйте другие решения: расположите подсказку под полем, вынесите её в заголовок после начала ввода или покажите маску ввода.
5. Отсутствие возможности проверить введенный пароль
Во многих приложениях при вводе пароля символы маскируются звездочками, а после ввода нет возможности посмотреть содержимое. Пароли бывают сложные. При их вводе пользователи ошибаются, после нескольких неудачных попыток приложение может быть заблокировано.
Рекомендация. Дайте пользователю возможность посмотреть пароль. Для безопасности можно показывать введенные символы временно, при нажатии на значок отображения.
6. Ручной выбор вместо автозаполнения
Часто значение поля можно заполнить автоматически на основе данных, которые есть в распоряжении банка. Но приложение вынуждает пользователя тратить время на ручной ввод: выбирать оператора, хотя приложение может определить его автоматически; вводить полные реквизиты при совершении платежей по квитанции, хотя часть из них приложение могло бы подставить автоматически, и т. п. Из-за этого пользователи тратят больше времени на решение своих задач и делают больше ошибок.
Рекомендация. Постарайтесь, чтобы ваше приложение максимально использовало автозаполнение значений, там где оно уместно и возможно.
7. Некорректное автозаполнение
В попытке облегчить жизнь пользователю приложения порой оказывают медвежью услугу: подставляют в поле некоторое «подходящее» значение, например, сумму платежа. А пользователю значение не подходит, и он вынужден сначала стереть подставленное, а затем вводить нужное.
Не всегда автозаполнение уместно. Помочь пользователю при вводе данных можно другими, менее директивными способами.
Рекомендация. Используйте автозаполнение там, где оно действительно будет уместно:
- операции, при которых ввод данных занимает слишком много времени (например, платежи по квитанции);
- операции, при которых пользователь наверняка не захочет ничего менять (например, сумма оплаты за услуги ЖКХ) — при этом оставить возможность редактирования все-таки необходимо;
- операции, где скорректировать автоматически подставленное значение можно буквально в пару нажатий (например, выбор счета-источника и счета-получателя платежа при переводе между своими счетами);
- подумайте о том, чтобы не заполнять поле, а предложить пользователю варианты автоподстановки, как на скриншоте выше.
8. Активная кнопка отправки формы при незаполненных полях
Когда кнопка отправки формы выглядит кликабельной, пользователь полагает, что форма заполнена корректно, и можно переходить к следующему шагу. Если не все обязательные поля заполнены, отправка формы приведет к ошибке.
Рекомендация. Обеспечьте пользователям привычный паттерн взаимодействия: позаботьтесь, чтобы кнопка отправки формы выглядела некликабельной до заполнения всех необходимых полей.
9. Перегруженная форма
Проблема, характерная в основном для платежей по квитанциям. Формы для таких платежей содержат множество полей, но в большинстве случаев пользователю нужна только малая их часть. Тем не менее, часто бывает так, что на странице платежа показаны все возможные поля, при этом самые важные из них никак не выделены и часто не видны.
Рекомендация. Подумайте о том, что важно для вашего пользователя. Какие поля он будет заполнять? Какую информацию будет искать? Выделите это на экране, а ненужные поля скройте.
10. Буквенная клавиатура вместо цифровой при вводе чисел
Иногда для ввода сумм или числовых кодов банковские приложения предлагают буквенную клавиатуру. Пользователь вынужден переключаться на цифровой ввод или пользоваться узким рядом цифр в верхнем ряду буквенной клавиатуры. В последнем случае пользователи, как правило, промахиваются мимо клавиш и делают много опечаток.
Рекомендация. Предложите пользователю сразу подходящий способ ввода. Оптимальное решение предлагается в одном из приложений для учета расходов: сумму можно ввести с помощью мини-калькулятора.
Заключение
Это самые типичные проблемы, которые встречаются в формах в мобильных банковских приложениях. Банковское приложение почти целиком состоит из форм, и поэтому может содержать десятки таких проблем. Поэтому их нельзя игнорировать.
Юзабилити-проблемы, о которых я здесь рассказал, встречаются не только в банковских, но и в любых других приложениях, где встречаются формы. Тем не менее, у каждого приложения есть своя специфика, в зависимости от которой набор проблем может меняться. Юзабилити-тестирование поможет выявить проблемы, из-за которых пользователи вашего приложения испытывают неудобства или вообще не могут выполнить некоторые задачи.
Если вы хотите улучшить своё приложение, напишите нам на info@usabilitylab.ru или оставьте заявку на сайте.
Подписывайтесь на наш Телеграм, чтобы не пропустить выход новых интересных статей.
