Как белорусским банкам развивать свои мобильные приложения: взгляд юзабилити-эксперта

Готовясь к выступлению, я попросил наших сотрудников изучить, насколько активно белорусские банки обновляют свои iOS-приложения для физических лиц. Оказалось, что сравнению с российскими, белорусские мобильные банки в целом обновляются реже и меньше. Мы следим за приложениями 16 крупнейших российских банков, и за прошедшие полгода они обновились 203 раза. А 22 крупнейших белорусских банка обновились суммарно 131 раз. Но интересно не это, а то, что белорусские банки, входящие в топ-3 по размеру активов, свои приложения практически не обновляют.

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы можете организовать такой же процесс в своём банке: выберите приложения за которыми хотите следить, проверяйте их обновления, отмечайте то, что можно позаимствовать и то, что вы можете сделать лучше, чем конкуренты. Или переложите эту работу на нас. Для этого напишите мне, чтобы обсудить условия сотрудничества: d.silaev@usabilitylab.net

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

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

Возможная локализация юзабилити-проблем:

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

Возможное содержание (характер) юзабилити-проблем:

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

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

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

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

Если вы хотите увидеть больше примеров юзабилити-проблем или вам нужно, чтобы мы провели для вас аналогичное исследование — напишите мне: d.silaev@usabilitylab.net

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

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

Конечно, можно, и для этого предназначены так называемые «быстрые» методы юзабилити-оценки. Один из быстрых методов — First Click Test (FCT), тест первого клика. Вы показываете своим респондентам один экран и даете им задание, например: «Где вы будете искать возможность пополнить счет?». Вас будет интересовать, куда в первую очередь будут нажимать респонденты. Автор метода, Боб Бэйли (Bob Bailey), установил, что если первый клик был правильным, то вероятность успешного выполнения задания составляет 0.87 (от 0.72 до 1, согласно его исследованиям). А если неправильным — то всего 0.46. Поэтому, если, приступив к заданию, большинство ваших респондентов нажмут «не туда», это повод задуматься, вспомнить классификацию юзабилити-проблем, о которой я рассказывал выше, определить, в чем корень проблемы и как ее можно исправить.

Преимущество метода заключается в том, что на выполнение одного задания респондент тратит всего несколько секунд. Поэтому в ходе одного исследования можно оценить несколько экранов. А поскольку FCT — исследование автоматизированные, не требующее постоянного присутствия специалиста, вы можете буквально за день собрать достаточное количество ответов, чтобы делать выводы о наличии или отсутствии юзабилити-проблем.

Я проводил мини-FCT, когда готовился к выступлению на конференции. Я взял скриншот приложения банка Дабрабыт, загрузил его в сервис Oprosso, позволяющий проводить такого рода исследования, а ссылку на исследование распространил через интернет. Вопрос, на который отвечали респонденты: «Куда бы вы нажали, чтобы найти ранее созданный шаблон платежа?». Правильный ответ — кнопка «Быстрые платежи», но на нее нажали всего 40% респондентов. Это говорит о том, что как минимум российская аудитория столкнулась бы с проблемой на этом экране, и скорее всего проблема связана с названием кнопки, то есть ее можно отнести к категории «Элементы управления/ понятность информации».

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

• параллельно вести работу над развитием функциональности и юзабилити;
• быстро проверять гипотезы про ваш интерфейс или интерфейсы конкурентов.