Артефакты: отчет по юзабилити-аудиту

Описание

Юзабилити-аудит (usability review) – это процесс и результат экспертной оценки информационной системы (веб-сайт, веб-приложение, мобильное, настольное приложение и т.п.) либо ее прототипа на предмет удобства использования.

В процессе оценки могут быть использованы самые разные техники, но самая популярная – оценка по эвристикам (де-факто в большинстве случаев – по эвристикам Якоба Нильсена). В этом случае вместо «аудит» говорят «эвристическая оценка» (heuristic evaluation).

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

К более сложным и полезным техникам можно отнести экспертизу компонентов (feature inspection). В этом случае эксперту на вход дается описание пользователей (желательно – в формате персонажей), описание контекста использования, а также список основных пользовательских сценариев. Затем эксперт проходит последовательно по всем сценариям и отвечает на следующие вопросы:

  1. Как ускорить работу данных пользователей в данном контексте?
  2. Как снизить число ошибок данных пользователей в данном контексте?
  3. Как повысить удовлетворенность данных пользователей в данном контексте?
  4. Как сделать интерфейс понятнее данным пользователям, чтобы повысить скорость обучения в данном контексте?

Главное преимущество этого метода – учет особенностей пользователей и контекста в процессе оценки.

Разумеется, это не все существующие техники, но как показывает мой опыт, чаще всего используются именно они.

Примеры

Вместо примера привожу шаблон отчета, который используем мы.

Зачем использовать
  1. Для выявления проблемных мест в интерфейсе быстро и относительно дешево. Юзабилити-аудит – хороший способ оценки интерфейса с той позиции, что требует он относительно немного усилий (в сравнении с юзабилити-тестированием), занимает меньше времени, а также может проводиться на самых ранних этапах. В то же время лучше всего работает комбинация экспертной оценки и оценки с пользователями: проведение юзабилити-аудита поможет убрать «грабли», раскиданные по поверхности, и пользователи о них не споткнутся, а обнаружат более глубокие проблемы.
  2. Для диагностики  текущего состояния системы и  определение потенциального направления для развития.
  3. Хороший эксперт посмотрит не только на саму систему, но и на состояние дел на рынке. И в отчете по аудиту подскажет, кроме того, что кнопку «войти» неплохо бы передвинуть, что пользователи часто жалуются на форуме на отсутствие фичи Y у конкурентов, так что неплохо бы ее добавить в систему.
  4. Для плавного входа в UX мир. Из всех возможных активностей в этой области именно экспертная оценка позволит принести полезный результат сравнительно быстро.
Подводные камни
  1. Экспертные методы оценки выявляют не более 50% проблем. Увы, остальное можно обнаружить только с привлечением пользователей.
  2. Результат сильно зависит от квалификации эксперта. Поэтому крайне желательно привлекать несколько человек: это позволит избежать субъективизма.
  3. Трудно определить приоритет обнаруженных проблем.
  4. Существует очень мало правил и хороших практик проектирования, которые не имели бы исключений. На практике это означает, что даже если вы обнаружили нарушение известного вам принципа, не факт, что его исправление действительно окажет положительный эффект. Если бы существовал набор таких законов, все системы бы были очень похожи одна на другую.
Источники информации для проведения аудита
  1. Сама система (или ее макеты, прототип, бумажные наброски). Это, пожалуй, пункт, который не требует пояснений :). Если этого нет, оценивать нечего.
  2. Рекомендации (guidelines) и стандарты. В некоторых случаях полезно будет заглянуть в рекомендации по платформе или в государственные стандарты. Где их искать: рекомендации разных стран, рекомендации разных компаний, рекомендации по мобильным платформам: Android, iOS и iOS 7, Windows Phone, Blackberry
  3. Руководства по стилю (Style Guides). Если вдруг такой документ для вашей системы есть (например, если у компании есть целая линейка продуктов + общее руководство), полезно будет с ним познакомиться до проведения аудита. Соблюдение правил из руководства уже само по себе способно избавить от некоторых проблем с юзабилити.
  4. Конкуренты. Никто не заставляет проводить полноценный конкурентный анализ, но глянуть, как обстоят дела у конкурентов, лишним не будет. Особенно если конкурент старый и популярный, а ваш продукт – молодой и непопулярный. Во-первых, стоит обратить внимание на отраслевые стандарты де-факто. Тем самым упростите для пользователей переход на новую систему. Во-вторых, подсматривайте хорошие идеи и особенно обращайте внимание на те из них, которые реализованы плохо.
  5. Веб-аналитика (Google Analytics, Yandex.Метрика). Пункт, разумеется, актуален только для веб проектов. В каждом конкретном случае внимание стоит обращать на разные вещи, поэтому универсального рецепта я тут не предложу. Однако полезно посмотреть, как минимум, на количество посещений (а то вдруг пеняете на юзабилити, а на самом деле посетителей пшик), источники трафика (мало ли, пользователи приходят не по тем запросам), информацию по девайсам (разрешение, браузеры, мобильные устройства), длительность пребывания на сайте в целом, статистику страниц. Здорово, если у вас в команде есть выделенный веб-аналитик, т.к. это все же отдельная область знаний. У нас, кстати, есть :).
  6. Запросы пользователей в службу поддержки. Если таковая существует, конечно. Под службой поддержки я понимаю колл-центры, онлайн-чаты, системы тикетов, в которые пользователи могут отправлять свои жалобы. Если у вас есть специально обученный человек, который напрямую общается с разгневанными пользователями, поговорите с ним. Зачем это нужно: посмотрите, на что чаще всего жалуются, и подумайте над тем, что с этим можно сделать. Это хоть каким-то образом компенсирует тот факт, что экспертная оценка не предполагает привлечения пользователей.
  7. Опросы пользователей. Если по предыдущему пункту информации не получить, никто не мешает вам инициировать опрос. Для этого можно встроить специальный сервис непосредственно на ресурс (опять же, для веб), отправить ссылку на Google Docs, запостить опрос в соц. сетях (если у продукта есть своя группа в них), в конце концов – взять электронные адреса зарегистрированных пользователей и выслать им опросник.
  8. Обратная связь от пользователей на форумах и любых других сайтах. Особо недовольные пользователи любят жаловаться на всякие особенно докучающие им системы. Если ваша система достаточно широко известна, попробуйте поискать запросы вроде «создатели Y козлы». Можно также поискать подобное о конкурентах.
  9. Обзоры системы от третьей стороны. Если ваша система настолько известна, что о ней пишут не только разгневанные пользователи, но и критики, есть смысл почитать, что же они пишут. Особенно полезны будут сравнительные обзоры, где вам могу прямо указать на полезные вещи у конкурентов, которые неплохо бы завести себе.
Общие рекомендации

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

Цели системы: для чего она существует и какую пользу приносит ее создателям?

Цели пользователей: зачем система им?

Цели аудита: чего мы хотим добиться и как будем определять, что добились? Ценность аудита ради аудита – ничтожна. Практически всегда аудит проводится не просто так. Скорее всего, существуют симптомы проблем с интерфейсом, но причины неясны (например, конверсия низкая, но почему – тайна).

2) Ищите и проблемы, и удачные решения. Во-первых, когда вы ищите удачные решения, проблемы вылазят одна за другой. Во-вторых, вам они понадобятся для следующего пункта.

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

4) Предлагайте решение проблем в картинках. Если опыт позволяет – в Photoshop и максимально приближенно к дизайну. Если нет – хоть в Paint, но так, чтобы было понятно. Можно даже на бумаге набросать карандашом – это будет в миллиард раз лучше, чем описание текстом. Можно, на худой конец, вставить скриншот чужой системы, чтобы проиллюстрировать свою мысль. Но могу сказать точно: отчеты без иллюстраций решений полетят в мусорку.

5) Формулируйте пункты так, чтобы они могли стать задачей для разработчика (дизайнера, копирайтера, аналитика и т.п.). Т.е. чтобы можно было скопировать текст из документа, вставить в любую систему отслеживания задач и назначить на исполнителя. Так вы в разы увеличите шанс того, что проблему исправят.

Полезные ссылки и инструменты

1) Colour contrast check: очень простая проверка контраста текста и фона. Можно вставлять в отчет скриншот прямо оттуда (только не забудьте порекомендовать цвета, на которые нужно заменить текущие).

2) http://www.checkmycolours.com/  - более навороченный инструмент по проверке контраста (делает это сразу для всего сайта). Бесполезен для систем, требующих обязательную авторизацию.

3) http://colorfilter.wickline.org – хотели узнать, как увидят ваш сайт дальтоники? Вам сюда. Плохо работает с кириллицей, но я его люблю не за это.

3) http://wave.webaim.org/  – валидатор html разметки, который расскажет вам о нарушениях стандартов W3C.

4) Spurapp  для оценки дизайна. Ресурс предлагает сразу несколько интересных инструментов: можно посмотреть на страницу (или макет) в черно-белом варианте, с размытием, с выкрученным контрастом; проверить выравнивание и расстояние между блоками т.п. Внутри есть инструкция по использованию каждого инструмента.

5) http://www.techsmith.com/snagit.html: самый удобный инструмент для снятия скриншотов

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>