Все статьи

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

1. Элементы управления (навигация в приложении)

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

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

Кнопка «Платежи», расположенная в нижнем меню, ведет на экран с переводами (раздел с платежами находится за «сгибом» экрана)

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

Кнопка «Переводы» ведет на экран, где есть и платежи тоже

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

В 2017 году, чтобы найти раздел с банкоматами, надо было нажать на кнопку «еще». В 2018 году надо нажать «Еще» и перейти на вкладку «Инфо»

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

2. Информационные элементы (подсказки и сообщения об ошибках)

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

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

Примеры бесполезных подсказок: короткая и очевидная (слева), длинная и запутанная (справа)

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

Ошибки, которые появляются при опечатке в коде плательщика, никак не помогают пользователю решить проблему

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

3. Редактируемые элементы (ввод информации)

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

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

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

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

Иногда с полем на первый взгляд все в порядке: есть маска, открывается правильный тип клавиатуры, — но пользователи все равно делают ошибки при вводе. Проблема может заключаться в том, что сам формат данных или последовательность их ввода не соответствует логике пользователей. Например, если период оплаты услуг ЖКУ требуется вводить в формате «ГГГГ-ММ», то пользователи будут забывать вводить дефис, что мы и наблюдали на тестированиях.

Проблема при вводе периода оплаты: пользователи забывают поставить дефис

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

4. Логика последовательности действий (соответствие результатов действий ожиданиям пользователя)

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

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

Проблема логики действий: выбрав пункт «пополнить карту», пользователь попадает на экран перевода с карты на карту

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

Пример нарушения логики последовательности действий: чтобы найти банкоматы, надо разлогиниться

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

Отчет об исследовании мобильных банковских приложений

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

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

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

Тэги

Поделиться статьёй

Поделитесь своим мнением
Стоила ли статья потраченного времени?