Все статьи

Быстрые методы юзабилити-оценки для банков

Такой подход кажется мне неконструктивным. Давайте поговорим о том, как исправить ситуацию. Как сделать так, чтобы работа над юзабилити поспевала за бизнесом, технологиями и дизайнерами?

Нет юзабилити — нет проблем?

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

Тратиться на юзабилити-исследования не хочется, но при этом хочется высоких оценок и признания пользователей

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

По данным IPSOS, между NPS (индексом лояльности клиентов) и качеством интернет- и мобильного банка есть четкая связь. Банки с самыми удобными каналами ДБО имеют самый высокий NPS. При этом, по результатам наших собственных исследований, между удобством (юзабилити) и функциональностью нет корреляции, то есть самый функциональный интернет- или мобильный банк не обязательно будет самым удобным. Поэтому очевидно, что забывать о юзабилити или заменить его богатой функциональностью нельзя.

Нет интерфейса — нет проблем?

Давайте вообще уберем графический интерфейс. Все эти кнопки, поля, меню — от них сплошные проблемы, то называются неправильно, то расположены не там. Пусть пользователи управляют своими деньгами голосом. Существует столько голосовых помощников: Google Assistant, Cortana, Alexa, Алиса, Siri... Так пусть пользователь говорит: “Привет, Сири! Открой приложение Моего Любимого Банка и переведи мне на телефон 500 рублей”. Всё просто. Кстати, зарубежные банки уже осваивают эту технологию — например, Первый Гавайский Банк запустил голосовое управление через Алексу.

Первый Гавайский Банк и управление через Алексу

Проблема в том, что голосовой интерфейс — это все равно интерфейс (простите за тавтологию), хоть его и не видно. Его точно так же надо проектировать и продумывать. А ещё всё упирается в несовершенство технологии. NNGroup в недавнем отчете писали, что на данный момент голосовые помощники хорошо понимают простые запросы, но плохо понимают естественную речь, в том числе потому, что не умеют учитывать контекст. К тому же на данный момент они практически не умеют интегрироваться с приложениями, например, на мобильном устройстве.

Некоторые российские банки (например, Промсвязьбанк и Рокетбанк) сейчас пытаются осваивать Siri, но пока всё работает не так, как надо, что еще раз подтверждает мою мысль. В лучшем случае обращение к Сири открывает приложение, а значит, пользователю все равно приходится брать в руки телефон и работать с графическим интерфейсом. В худшем случае Сири не понимает, чего от нее хотят, в том числе не может распознать название банковского приложения.

Отрывок из отчета по мониторингу банковских приложений за июнь. Денежный перевод через приложение Промсвязьбанка при помощи Siri. На последних шагах пользователь все равно должен взаимодействовать с приложением

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

Есть быстрые исследования — нет проблем

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

Технологии всегда будут на первом месте, но юзабилити должна идти сразу следом за ними

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

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

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

Что это за методы такие — расскажу дальше.

 

Быстрые методы юзабилити-исследований: FCT, удаленное немодерируемое тестирование, парные сравнения и другие

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

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

Тепловые карты, которые можно получить в результате first-click теста (подробнее о методе читайте в нашей статье)

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

Один из экранов с результатами удаленного немодерируемого тестирования

Третий быстрый метод — парные сравнения (вы можете прочитать нашу статью или посмотреть вебинар про этот метод). Вы предъявляете пользователю пары изображений и просите быстро выбрать то из них, которое ему больше нравится. Говорят, что автор метода, Луи Терстоун, придумал его в 1914 году, чтобы составить шкалу тяжести преступлений. С тех пор метод активно используется в различных областях науки и бизнеса. По нашему опыту, метод хорошо подходит для быстрой оценки графического дизайна: например, когда ваш дизайнер нарисовал пять восхитительных вариантов главной страницы, и вы не можете решить, какой же выбрать.

Быстрый рекрутинг для исследования методом парных сравнений

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

Быстрые методы выигрывают у классических методов юзабилити-исследований за счет того, что на их проведение и обработку нужно существенно меньше времени. Но есть и важное ограничение. “Быстрые исследования” должны быть быстрыми не только для исследователя, но и для респондентов. Мало у кого хватит терпения и времени сидеть за компьютером больше 15-20 минут, если его не контролирует юзабилити-специалист. Поэтому масштабное исследование, которое позволит всесторонне изучить интерфейс, понять природу затруднений пользователей или мотивацию их действий, “быстрыми методами” провести не получится. Если вам надо понять, почему у вашего мобильного приложения низкие оценки в App Store, будет разумно сначала провести лабораторное юзабилити-тестирование. Затем, по результатам этого исследования, необходимо будет составить список работ для улучшения. А вот конкретные изменения экранов, которые будут происходить в ходе переделки интерфейса, уже можно будет проверять при помощи FCT или другими способами.

Единый сервис для быстрых юзабилити-исследований

Разные компании предлагают разные сервисы для каждого метода исследований. Например, массовые опросы можно проводить через SurveyGizmo, а удаленные тестирования — через Loop11. Проблема в том, что компания, регулярно проводящая такие исследования (например, наша) постепенно обрастает “зоопарком” подобных сервисов, и это неудобно: приходится держать в голове или где-то записывать, где что хранится. Поэтому я считаю, что настоящий профессиональный юзабилити-сервис должен давать возможность использовать разные методы, а не быть заточенным под один-единственный. А еще такой сервис должен давать возможность тегировать проекты, раскладывать их по папочкам, дублировать и корректировать их.

Макет библиотеки проектов (сервис Oprosso, в разработке)

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

Макет библиотеки проектов (сервис Oprosso, в разработке)

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

Макет экрана с результатами одного из исследований (сервис Oprosso, в разработке)

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

Мы можем помочь вам настроить такую библиотеку, а также научить самостоятельно планировать и проводить исследования. Чтобы узнать подробнее об этой услуге, напишите мне: d.silaev@usabilitylab.net

Исследуйте, тестируйте, и хороших вам интерфейсов!

Презентация о банковском юзабилити и быстрых методах исследований

Тэги

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

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