Как правильно описывать юзабилити-проблемы

24 Октябрь

Определение юзабилити-проблемы

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

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

Описание проблемы

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

Плохо Хорошо
Респонденты испытывают трудности с поиском истории операций, потому что надпись «История операций» плохо заметна. Почему: Не указано, как это проявляется в поведении пользователей. Невнятно описана особенность интерфейса, из-за которой возникает проблема. Ссылка на историю операций расположена в нетипичном месте: около левого края экрана, в отрыве от главного меню. Надпись «История операций» сделана мелким белым шрифтом, который трудно читается на сером фоне. Поэтому респонденты испытывают трудности с поиском истории операций: они ищут ее в главном меню и в правой колонке, но не замечают ее слева.
При выборе некоторых курсов всплывающее окно с курсом оказывается не полностью развернутым, при этом возможность развернуть его отсутствует. Почему: Из описания проблемы непонятно, чем это мешает пользователям. При выборе некоторых курсов всплывающее окно с курсом оказывается не полностью развернуто, при этом возможность развернуть его отсутствует. Часть контента, размещенного на странице курса, не умещается в окно. Чтобы прочитать расположенный на странице текст, респонденты вынуждены использовать горизонтальную прокрутку. После выполнения задания респонденты снижали оценку удовлетворенности и отмечали неудобство, связанное с горизонтальной прокруткой.
Респонденты не читают раздел о медицинской и юридической поддержке держателей премиальных карт. Почему: Если, не ознакомившись с информацией из этих разделов, пользователь все же смог достичь своей цели (выбрать нужную карту), то это не юзабилити-проблема. В противном случае нужно указать, чем плохо то, что пользователь не получил эту информацию. Респонденты не находят информацию о преимуществах премиальной карты, которая должна дать информацию, достаточную для принятия решения о покупке. Описание преимуществ находится в разделе под названием «Медицинская и юридическая поддержка», куда 5 из 8 респондентов решили не заходить, а 3 из 8 зашли и сразу вышли.

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

Плохо Хорошо
Один из пользователей хотел бы иметь возможность вводить старый пароль наряду с новым. Почему: Это не юзабилити-проблема. Не писать в отчете о субъективных высказываниях респондента, если они не иллюстрируют какую-то реально существующую проблему. Некоторые пожелания респондентов можно включать в отчет, если они представляют потенциальную ценность для заказчика.

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

Плохо Хорошо
Название ссылки «Виртуальная карта MasterCard» непонятно для пользователей. Почему: Не указано, по каким признакам аналитик определил, что название ссылки непонятно; не указано, к каким последствиям это приводит. Неопытные респонденты, никогда не совершавшие покупки через Интернет, не знают, что такое «виртуальная карта». Пытаясь найти способ безопасно оплачивать покупки через интернет, они ищут ссылки с названием «Безопасные покупки», «Безопасная оплата через интернет», и, не найдя их, решают, что такой возможности у них нет. Название ссылки «Виртуальная карта MasterCard Virtual» непонятно для респондентов и не помогает им сделать правильный выбор.

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

Плохо Хорошо
Окно чата с консультантом раздражает пользователей. Почему: «Раздражает» — эмоционально окрашенное слово. Из описания проблемы непонятны признаки, по которым аналитик определил, что окно чата действительно раздражает пользователей и причина, по которой пользователи чувствуют раздражение. 5 респондентов из 8 отказались читать текст на странице, сказав, что им мешает окно чата с консультантом. Окно чата с консультантом мигает, издает звуки и закрывает часть текста, делая чтение практически невозможным.
Цветовое оформление системы мрачное и не нравится респондентам. Почему: «Мрачное» — ничем не подкрепленная оценка автора отчета. Все экраны системы имеют черный фон. Впервые увидев систему, 6 из 12 респондентов сообщили, что черный цвет их «напрягает». Неприятие черного цвета сохраняется на протяжении всего тестирования.

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

Критичность и встречаемость

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

Примеры проблем разной степени критичности:

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

Для проблем, обнаруженных в ходе юзабилити-тестирования, мы указываем их встречаемость, то есть количество столкнувшихся с ней пользователей. Этот показатель дает основания для того, чтобы предположить, насколько проблема распространена среди пользователей в целом. Однако его нельзя переносить на всю целевую аудиторию продукта. Если на тестировании с проблемой столкнулись 2 респондента из 8, это не значит, что в жизни с ней столкнется 25% всех пользователей. Дело в том, что выборка участников тестирования очень маленькая. Восьми-десяти человек достаточно для того, чтобы найти почти все юзабилити-проблемы в интерфейсе, но недостаточно, чтобы делать статистически значимые выводы об их встречаемости. По этой же причине мы не указываем в процентах количество респондентов, столкнувшихся с проблемой или справившихся с задачей: для группы из 8-10 человек это будет некорректно.

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

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

Иллюстрации

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

                        Скриншот проблемного элемента интерфейса с его описанием

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

Проблемная область, о которой идет речь в описании проблемы обведена в рамку

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

Рекомендации

Для того, чтобы отчет имел ценность, одного описания проблем недостаточно. Читатель отчета должен иметь представление о том, как их можно исправить. Поэтому UX-аналитики предлагают рекомендации по устранению найденных проблем.

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

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

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

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

Главное правило: из формулировки рекомендации читатель отчета должен понять, что конкретно он должен сделать, чтобы исправить проблему.

Заключение

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

Хорошее описание юзабилити-проблемы содержит:

  1. описание поведения пользователя, сигнализирующего о проблеме (негативного события);
  2. описание особенностей интерфейса, из-за которых возникла проблема;
  3. указание на критичность и встречаемость проблемы;
  4. подписанную иллюстрацию с выделенной проблемной областью;
  5. рекомендацию по ее устранению.

1) описание проблемы пользователя;
2) описание особенностей интерфейса, из-за которых возникла проблема;
3) критичность и встречаемость проблемы;
4) подписанная иллюстрация с выделенной проблемной областью;
5) рекомендация. Слайд из индивидуального отчета для одного из участников нашего ежегодного отраслевого исследования удобства банковских мобильных приложений

Если описание проблемы неубедительно, то неважно, сколько человек приняло участие в тестировании или насколько опытный аналитик проводил оценку. Читатель отчета не поверит в объективность автора и не станет внедрять изложенные в нем рекомендации. Мы хотим, чтобы наши рекомендации шли в работу, а не в стол, поэтому во всех своих отчетах описываем проблемы так, как рассказали в этой статье.

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

1450
Контакты
Россия
129085, г.Москва, ул. Годовикова д.
9, стр. 2, подъезд 2.1, офис 2.22