Специально для вас мы провели несколько десятков юзабилити-тестирований интернет-банков. Выявленные проблемы мы разбили на 8 категорий. Ниже мы приведем примеры из рейтингового юзабилити-исследования интернет-банков 2018 для того, чтобы вы взяли их на вооружение. Как это вам поможет:
- изучите примеры проблем из каждой категории для того, чтобы понимать, каких решений стоит избегать;
- выберите пользовательский сценарий, который хотите оценить;
- проведите быструю экспертную оценку на предмет:
- отсутствия подобных проблем
- поиска удачных решений (которые элегантно решают описанные проблемы или позволяют избежать их)
- при выявлении новых примеров (а может быть и подтипов) проблем пополните свою “антиюзабилити-библиотеку”
Наш новый отчёт о сравнительном исследовании интернет-банков как раз представлен в виде такой библиотеки. Чтобы более подробнее узнать о содержании, цене и возможности персонализации отчёта, напишите нам на info@usabilitylab.ru.
Итак, переходим к первому шагу: изучите категории и примеры проблем, чтобы использовать в дальнейшей работе.
Элементы управления
Элементы управления — это различные кнопки, ссылки, вкладки, селекторы, переключатели и т.п. Если пользователь не замечает кнопку или не понимает, как работает переключатель, он не может сделать правильное действие, чтобы решить свою задачу.
Пример проблемного элемента управления: переключатель (тоггл) в интернет-банке ВТБ. На разных экранах он используется для разных действий. Например, на экране «Подтверждение операции» он выполняет функцию селектора: если «ползунок» сдвинут вправо, проведенный платеж будет сохранен как шаблон. При этом левая часть переключателя закрашивается синим. На наш взгляд, в данном случае было бы корректнее использовать чекбокс, но и в таком варианте принцип работы этого элемента пользователям понятен.
В других случаях такой же переключатель служит для переходов между подразделами на одном экране. Во-первых, для такого типа взаимодействия этот элемент интерфейса не подходит, потому что в таких случаях необходимо использовать вкладки. Во-вторых, он ведет себя нестандартным образом: при переключении слева направо не закрашивается синим, как на тех экранах, где выполняет свою прямую функцию, а остается серым, как будто он не выбран или не активирован. И это порождает юзабилити-проблему. Пользователи не понимают, как работает этот элемент интерфейса и чего от него ждать на каждом экране.
Вывод. Важно использовать элементы управления в соответствии с их общепринятыми функциями и оформлять их так, чтобы пользователь понимал, что произойдет, если он начнет с ними взаимодействовать.Функциональность и внешний вид элементов интерфейса должны быть унифицированы: если определенный элемент выполняет одну функцию на одном экране, на других экранах он не должен выполнять другие функции.
Редактируемые элементы
Редактируемые элементы — это любые элементы интерфейса, при помощи которых пользователь вводит в систему какие-либо данные: поля ввода, списки выбора, календари, чекбоксы и т.п. Если редактируемый элемент оформлен неправильно, пользователь совершает ошибки при вводе данных.
Пример юзабилити-проблемы, связанной с редактируемыми элементами — ввод периода оплаты услуг ЖКХ в интернет-банке Банка Санкт Петербург. Система требует, чтобы пользователь вводил месяц и год оплаты в одно поле в формате ГГГГ-ММ, например, 2018-09. Но на бумажной квитанции период оплаты обозначен совсем по-другому: “сентябрь 2018”. Поэтому пользователям неудобно и непривычно вводить данные в том формате, который требует интернет-банк.
Проблема усугубляется тем, что маска «ГГГГ-ММ» находится внутри поля и исчезает, когда пользователь начинает вводить данные. Невнимательный пользователь, который введет в поле месяц оплаты и будет гадать, куда же вводить год, окажется в таком случае совершенно беспомощным. Если нажать на вопросительный знак, появится подсказка, но она тоже будет бесполезна, потому что на ней показан участок бумажной квитанции с датой, которая написана не так, как указано в квитанции на самом деле.
Вывод. Пользователь должен вводить данные в том виде, в котором это удобно ему, а не банку. Лучше всего, если система автоматически будет автоматически подставлять некоторые данные — это уменьшит вероятность ошибки со со стороны пользователя. Например, даже если у банка нет технической возможности проверить задолженность по введенному номеру квитанции, можно как минимум автоматически заполнить год и месяц платежа, предоставив пользователю возможность изменить их при необходимости.
Понятность информации
Как следует из названия, эта категория юзабилити-проблем связана с любыми текстами, надписями, названиями полей, диаграммами, если они не понятны пользователю.
Наш любимый пример проблемы из этой категории — названия операций в выписке и истории операций. Например, в интернет-банке Райффайзенбанка операции обозначены латиницей с использованием банковских терминов, что совершенно непонятно для многих пользователей.
Еще один пример, также связанный с историей операций. В интернет-банке Росбанка (бета-версия) информация об одной и той же операции в выписке и в истории операций может различаться. На скриншоте ниже операция от 06.11 в истории операций обозначена как доход, а в выписке — как расход. Дело в том, что в разделе “История операций” выводятся операции по всем счетам и картам клиента, а любое движение между счетами клиента показано как доход (черный). В выписке показаны операции только по одному выбранному продукту (например, по карте), поэтому, если с этого продукта деньги были переведены куда-то, это будет отображаться как расход. Звучит логично, но пользователи сразу разобраться в этой логике не могут. Положение усугубляется еще и тем, что набор данных в выписке и истории операций отличается, и на основе имеющейся информации пользователю трудно разобраться, что к чему.
Вывод. Мы никогда не устанем писать о том, что информация должна быть логичной, консистентной и понятной для пользователя. В продуктах, ориентированных на широкую аудиторию, лучше не использовать узкую терминологию и тем более не нужно использовать латиницу.
Нехватка или отсутствие информации
Ещё одна группа проблем, связанная с представлением информации на сайте. Как следует из названия, в данном случае проблемы связаны с тем, что информации недостаточно, поэтому пользователь не может принять правильное решение, чтобы выполнить свою задачу в интерфейсе.
Яркий пример — оформление заявки на кредитную карту в банке Хоум Кредит. Пользователь может подать заявку на оформление «Револьверной карты», но в интернет-банке нет даже минимального описания карты, не говоря уж о тарифах. В итоге оформлять такую карту пользователь будет, только если уже узнал о ней из каких-то других источников.
Можно обратить внимание, что здесь есть и проблема из категории «Понятность информации»: «револьверная карта» — это специфический банковский термин, и вряд ли он понятен неподготовленному пользователю. Кстати говоря, на сайте Хоум Кредит Банка раздела под названием «револьверные карты» нет, поэтому пользователь сможет найти нужную ему информацию, только если как-то догадается, что под этим термином подразумеваются обычные кредитные карты.
Вывод. Независимо, идёт ли речь о рекламе, сообщении об ошибке, подсказке или выписки со счёта, информации должно быть достаточно, чтобы пользователь получил ответы на вопросы, которые у него могут возникнуть.
Логика последовательности действий
Эта категория объединяет проблемы, связанные с последовательностью шагов в интерфейсе. При столкновении с проблемами из этой категории пользователь не понимает, что должен сделать, чтобы достичь цели, или его действия не приносят ожидаемых результатов.
Один из примеров — оплата ЖКУ в интернет-банке РоссельхозБанка. Обычно последовательность действий при выполнении этой задачи через интернет-банк выглядит так: ввести код плательщика и период оплаты, узнать сумму задолженности (или ввести ее вручную), подтвердить операцию. Но в РоссельхозБанке последовательность другая:
- ввести сумму платежа;
- ввести код плательщика и период оплаты;
- нажать кнопку “Далее”;
- увидеть сумму задолженности по оплате;
- при необходимости отредактировать сумму, введенную на шаге 1;
- провести платеж.
Такая последовательность действий контринуитивна, она противоречит ожиданиям и привычкам пользователей. Более того, она лишает смысла функцию автоматической проверки задолженности.
Вывод. Последовательность действий в интерфейсе должна совпадать с логикой пользователя. Поэтому мы рекомендуем до начала проектирования интерфейса продумать пользовательские сценарии, а перед внедрением новых интерфейсов провести юзабилити-тестирование макетов на целевой аудитории.
Шумовые элементы
Шумовые элементы — всё, что отвлекает пользователя от выполнения его основной задачи. В первую очередь, это различные рекламные баннеры и всплывающие окна с рекламой. Мы понимаем, что банкам надо продавать свои продукты, в том числе и через интернет-банк, но если реклама продукта неуместна, она раздражает пользователя и мешает ему.
Например, ЮниКредит Банк при переводе средств через интернет-банк на карту другого банка показывает модальное окно с рекламой мобильного приложения, причем оно появляется несколько раз за одну сессию. Юзабилити-тестирование показало, что пользователи негативно реагируют на это окно, в том числе из-за того, что им приходится отвлекаться от основной задачи и делать лишний клик, чтобы его закрыть.
Вывод. Интернет-банк — не место для агрессивной рекламы. Лучше рекламировать свои продукты менее навязчиво и не отвлекать пользователей от выполнения их основной задачи.
Дизайн
В категорию «дизайн» мы собрали все проблемы, связанные с визуальным оформлением интерфейса. Это размеры и цвета надписей и кнопок, использованные в интерфейсе пиктограммы и т.п.
В некоторых случаях неудачный дизайн может ухудшить доступность (accessibility) интерфейса, в первую очередь для людей с плохим зрением. Например, банк «Открытие» в своем интернет-банке использует мелкие бледно-серые шрифты. Участники наших юзабилити-тестирований не являются слабовидящими — у каждого из них было нормальное или скорректированное до нормального зрение. Тем не менее, даже они жаловались на то, что им тяжело читать тексты в этом интернет-банке. Пользователям с ограничениями по зрению, скорее всего, работать с этим интерфейсом будет совсем трудно.
Иногда безобидные и даже хорошие на первый взгляд дизайнерские решения порождают совершенно неожиданные проблемы. Например, в интернет-банке Тинькофф Банка в верхней части страницы платежа есть цветная полоса, окрашенная в брендовые цвета получателя платежа. Пользователи не обращают на это внимание ровно до тех пор, пока им не приходится оплачивать услуги оператора, у которого главный цвет бренда — красный, как, например, у МТС. Они благополучно вводят данные, не обращая внимания на цвет «шапки» в верхней части страницы, но, оказавшись на странице с информацией о совершении платежа, вдруг видят большую красную полосу и принимают ее за индикатор ошибки. Это не критичная проблема, потому что текст ниже на экране убеждает пользователей, что услуга благополучно оплачена. Тем не менее, некоторые пользователи переживают неприятные моменты из-за такого дизайнерского хода.
Вывод. Визуальное оформление не менее важно, чем продуманная система навигации или правильный выбор элементов для ввода данных. Оно может облегчать или затруднять взаимодействие с системой и даже, как мы видели, порождать новые неожиданные смыслы.
Технические проблемы
Последняя категория проблем находится не совсем в зоне ответственности специалистов по UX, но написать о ней нужно. В нее входит всё, что связано с работоспособностью системы: время загрузки страниц, правильное отображение страниц, корректное проведение операций и т.п.
Критичные технические проблемы приводят к тому, что вся система или какая-то ее часть перестают работать. Тогда пользователи в принципе не могут выполнить свою задачу. Если менее критичны, система работает, но само их наличие как минимум подрывает доверие пользователей к ней — особенно если речь идет об интернет-банке, где технические сбои могут привести к потере денег.
Например, в интернет-банке РоссельхозБанка при оплате ЖКУ система подгружает информацию о долговых начислениях. Но вместе с ней автоматически загружается другой текст, который перекрывает поля и кнопки на экране. Из-за этого пользователям трудно довести операцию до конца. Это явная техническая недоработка, но из-за нее у пользователей возникает ощущение, что система “сырая” и не вызывает доверия.
Вывод. Технические проблемы бывают у всех банков, но тестирование новых функций перед запуском поможет вовремя обнаружить и устранить самые явные из них.
Заключение
Мы считаем, что наша классификация юзабилити-проблем будет полезна всем, чья работа так или иначе связана с пользовательскими интерфейсами. Мы видим такой сценарий ее использования: сотрудники продуктовых команд создают на основании нашей классификации “библиотеку” проблем и удачных решений, а потом оценивают в соответствии с этой библиотекой удобство собственного интерфейса.
Дмитрий Силаев, коммерческий директор USABILITYLAB:
Мы видим, что продуктовые команды сами успешно и на хорошем уровне проводят юзабилити-тестирования, однако и в этих командах возникают задачи быстрой юзабилити-оценки. Примерами методов быстрой оценки с привлечением пользователей мы уже делились в своем блоге, а сейчас мы предложили подход к проведению структурированной экспертной юзабилити-оценки собственными силами. При внедрении и использовании “библиотеки проблем” вы получаете не только отчеты и обоснование для своих решений, вы повышаете юзабилити-компетенции всей команды.
Если вы хотите, чтобы мы оценили юзабилити вашего продукта, напишите нам на info@usabilitylab.ru. Мы выберем подходящий для вас метод оценки и формат отчёта — традиционный, где проблемы представлены по сценариям, или новый, где проблемы представлены по описанным в этой статье категориям.
Подписывайтесь на наш канал в Телеграме, чтобы не пропустить появление новых полезных статей в нашем блоге