Юзабилити-проблемы мобильных банков (часть I)

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

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

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

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

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

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

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

Наверное, распространенная проблема из этой категории — это оформление поля для ввода номера телефона. Очень плохо, когда на этом поле нет маски вида «() — – ” или хотя бы надписи «+7» перед ним. Многие пользователи, не видя маски, начинают вводить номер с семерки или восьмерки, и даже если в подсказке написать, что вводить нужно 10 цифр, это не поможет, потому что не все могут сразу сказать, сколько цифр в их номере телефона.

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

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

Эта категория проблем связана со случаями, когда пользователь не понимает последовательность шагов, необходимых для выполнения операций, или когда действия, которые он совершает, не приносят ожидаемых результатов. Частично проблемы из этой категории созвучны проблемам из первой («Элементы управления»), но здесь корень проблемы не в названиях разделов и кнопок, а в самой логике, заложенной в приложение.

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

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

Здесь мы рассмотрели первые четыре категории юзабилити-проблем, которые встречаются в мобильных банков. Каждая категория объединяет юзабилити-проблемы в зависимости от того, с какой областью интерфейса (навигационными элементами, подсказками, вводом данных или логикой действий) они связаны. В следующей статье мы рассматриваем еще четыре категории, объединяющие юзабилити-проблемы по их характеру (например, «отсутствие или нехватка информации»).

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

1. вход в приложение;
2. просмотр информации по счетам;
3. просмотр истории операций по карте;
4. перевод между своими счетами;
5. перевод в другой банк;
6. оплата мобильной связи;
7. оплата коммунального платежа по ЕПД;
8. поиск ближайшего банкомата.

Информацию о самых ярких юзабилити-проблемах и удачных решениях, связанных с реализацией каждого сценария, мы собрали в отчете об исследовании. Более подробно узнать об исследовании и заказать отчет можно на сайте www.rating.usabilitylab.ru или написав Дмитрию Силаеву: d.silaev@usabilitylab.net