Метрика Pure Score

Эта статья открывает цикл статей о метриках помогающих оценивать Usability и удобство опыта взаимодействия. Метод хорош тем что он прост и относительно дешев.

PURE Score (Pragmatic Usability Rating by Experts) . Дословно – это практический метод оценки юзабилити экспертом. Christian Rohrer из NN Groupe приводит такое определение: это метод оценки юзабилити, при котором эксперты по юзабилити (UX-дизайнер или ресечер) присваивают дизайну одну или несколько количественных оценок на основе набора критериев, а затем объединяют их в окончательную оценку для более легкого представления. Результатом оценки будет сумма баллов всех шагов от начала (из точки А) , до успешного завершения сценария (точки B) .

Метод ориентирован на скорость и понимание пользователем конкретного флоу. Ориентирован на проверки текущих пользовательских сценариев с целью их улучшения.

Проведем аналогию с оценкой фильма в Кинопоиске: вам как эксперту предлагается оценить просмотренный фильм от 1 до 10 баллов. Тем самым, переведя субъективное мнение в количественную оценку. Чем больше голосов – тем точнее будет метрика оценки фильма: 5 человек из 10 поставили 10 баллов и 5 – 1. Или 5 из 1 000 человек поставили 5 баллов, а остальные 1. Вопрос в том, где найти еще экспертов для прохождения сценария чтобы улучшить качество данных.

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

Кроме сравнения с конкурентами, метод идеален для детального разбора сценария и выявления ошибок с Usability. Дополнительно, результаты будут аргументом в защиту выбранного дизайн-решения перед бизнесом. А для эксперта, это возможность посмотреть на весь сценарий как бы со стороны.

Время до точки входа в сценарий. Время, которое тратит юзер чтобы добраться до точки входа в замеряемый сценарий после входа в приложение. Субьективно можно договорться на берегу что 2 секунды до точки А – это ок. И будет считаться за 0 баллов. От 2 до 5 секунд – 1 балл и за каждые дополнительные 3 сек ещё 1 балл и тд. Важно рассматривать время не в вакууме, а с оглядкой на конкурентов. Если у них время входа в сценарий – 2 секунды, а у вас 20, сколько мы за это поставим баллов? Кажется, что не 1. Тут на помощь придет мнение других экспертов.

Время на выполнение самого сценария. Тут как и с примером входа, правила такие же. Например, медленный отклик системы, долгое ожидание – безусловно будет негативно сказываться на этой метрике.

Клики на выполнение пути от А до B. Считается конкретный клик на поле/кнопке. Сюда не будет входить ручной ввод данных с клавиатуры (тап на скрытии клавиатуры для мобилы, будет считаться за клик) . Каждый скролл будет считаться за клик.

Сложность прохождения шага. Где шагом будет считаться отдельное действие на экране. Рейтинг основан на простой шкале от 1 до 3:

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

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

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

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

Собираем сводную табличку. Где описываем результаты. И собираем всю красоту в небольшой отчет. Где систематизируем баги, проблемы с UX, UI. Валидируем проблемы и ваши идеи с командой и оунером. Далее, бьем на таски, приоритизируем и тащим все это дело в беклог.

Надеюсь статья была вам полезна. Хочется понять применяете ли вы данный метод для оценки удобства клиентского пути? И какие еще методы применяете?

Буду рад обратной связи и комментариям. Больше полезных материалов в моем ламповом канале @uxelno.