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