10 основных показателей юзабилити Перевод

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

Вместо этого мы полагаемся на влияние хорошего и плохого юзабилити для оценки качества пользовательского опыта.

Вот 10 показателей, с которыми вы должны быть знакомы и готовы использовать при любой оценке юзабилити.

Показатели завершения: часто называемые фундаментальной метрикой юзабилити или метрикой шлюза. Показатели завершения являются простой мерой юзабилити. Обычно он записывается как двоичная метрика (1 = успешная задача и 0 = сбой задачи). Если пользователи не могут достичь своих целей, все остальное не имеет значения.

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

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

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

Удовлетворенность уровня тестирования. По завершении теста удобства использования попросите участников ответить на несколько вопросов об их впечатлении от общей простоты использования. Для общего программного обеспечения, оборудования и мобильных устройств используйте шкалу удобства использования системы (SUS), для веб-сайтов используйте SUPR-Q.

Ресурсы:

• См. Почему SUPR-Q лучше, чем SUS для веб-сайтов (англ.)
• Ист: 10 Essential Usability Metrics

Проверка подписки на посты.

Временно кнопка подписаться расположена внизу поста (над редактором). Кто публикует пост, автоматически подписывается на него.

В планах (на этом сайте):

• Протестировать изменение имен таблиц (mysql)
• Протестировать данную подписку
• Сделать страницу предпочтений

Где можно будет посмотреть на что подписан участник, и отписаться.

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

А еще в планах, с css тут заняться. Есть много идей, что можно сделат. Я говорю не только о дизайне самого сайта, но больше думаю над структурой css файла, имен там и т.д. Рефакторинг и его касается. Он хоть 20кб. всего (без css иконок), но он содержит много лишнего и сумбурно был написан. Структуры нет. Исправить надо.

И если кто-то уйдет случайно в немой режим, то через почту можно связаться по поводу этого: dev@libarea.ru

Модуль один тестирую, он может отправлять в немой режим по ошибке. «Немой режим» — это когда пользователь не может отвечать на этом сайте (и создавать посты). Это не бан, он авторизирован, но не может проявлять активность. Модуль автоматический, работает по одному алгоритму, «довожу до ума». Если ему не понравится некоторое поведение, он отправляет участника в этот режим.