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

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

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

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

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

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

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

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

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

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

Помимо сообщений об ошибках, проблемы с понятностью очень часто встречаются в истории операций: названия операций могут быть написаны по-английски или латиницей, с использованием банковских терминов или сокращений. Возможно, разработчикам каждая строчка в истории операций кажется очевидной и понятной, но не все пользователи знают английский, некоторые пугаются сложных слов и слабо представляют, что такое «Visa» или «MasterCard». Надпись вроде «Card2Card/Visa Direct/Rus» будет для них совершенно непонятна. В лучшем случае они смогут догадаться, что это была за операция, по ее сумме и дате.

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

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

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

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

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

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

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

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

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