Всем привет. Я Павел Шечков Старший продуктовый дизайнер. И я решил начать публиковать тут материалы. Обычно, делюсь интересным контентом в своем ламповом канале @Uxelno. Однако, я решил что будет полезнее если это не будет лонгрид – а хорошая статья.
Что такое Pure
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. Вопрос в том, где найти еще экспертов для прохождения сценария чтобы улучшить качество данных.
Что оценивает?
Метод оценивает, сложность пользовательского сценария. Прелесть его в том, что без особых затрат на дорогостоящие исследования, можно быстро сравнить себя с конкурентами или другой версией своего продукта.
Какие задачи можно решить с помощью PURE? Кроме сравнения с конкурентами, метод идеален для детального разбора сценария и выявления ошибок с Usability. Дополнительно, результаты будут аргументом в защиту выбранного дизайн-решения перед бизнесом. А для эксперта, это возможность посмотреть на весь сценарий как бы со стороны.
Как рассчитывается?
Время до точки входа в сценарий. Время, которое тратит юзер чтобы добраться до точки входа в замеряемый сценарий после входа в приложение. Субьективно можно договорться на берегу что 2 секунды до точки А – это ок. И будет считаться за 0 баллов. От 2 до 5 секунд – 1 балл и за каждые дополнительные 3 сек ещё 1 балл и тд. Важно рассматривать время не в вакууме, а с оглядкой на конкурентов. Если у них время входа в сценарий – 2 секунды, а у вас 20, сколько мы за это поставим баллов? Кажется, что не 1. Тут на помощь придет мнение других экспертов.
Время на выполнение самого сценария. Тут как и с примером входа, правила такие же. Например, медленный отклик системы, долгое ожидание –безусловно будет негативно сказываться на этой метрике.
Клики на выполнение пути от А до B. Считается конкретный клик на поле/кнопке. Сюда не будет входить ручной ввод данных с клавиатуры (тап на скрытии клавиатуры для мобилы, будет считаться за клик). Каждый скролл будет считаться за клик.
Сложность прохождения шага
Где шагом будет считаться отдельное действие на экране. Рейтинг основан на простой шкале от 1 до 3:
- 1 балл и зеленый цвет – этот шаг легко пройти, он обладает низкой когнитивной нагрузкой, паттерн знаком нашему пользователю.
- 2 балла и желтый цвет – шаг создает когнитивную нагрузку и требует усилий, но всё же может быть выполнен в большинстве случаев.
- 3 балла и красный цвет – сложный шаг для пользователя, обладает высокой когнитивной нагрузкой, замешательством, с ним не вышло справиться или на решение было потрачено существенное время.
Результат для данной задачи – это просто сумма баллов всех шагов. Если в сценарии были желтые отметки – весь сценарий красится в тот же цвет. Таким образом, если в вашем сценарии были красные метки – надо их исправлять, так как есть большой риск, что пользователи могут не справиться с задачей и покинуть ресурс.
Как проводить?
Берем текущий или обновленный сценарий по экранам и считаем время до точки входа плюс время на прохождение, клики (не забываем про скроллы), сложность выполнения каждого шага. В конце получится общее время на выполнение сценария, сумма баллов за клики и сложность. Лучше всего делать скринкаст экрана, который потом можно порезать на шаги и проставить метки.
Теперь замеряем сценарий у конкурентов. Чем больше конкурентов – тем взвешеннее будет исследование. Важно не предвзято относиться, но тут на помощь придет упомянутый видеозахват экрана. Получаем сумму баллов и время для них.
Параллельно записываем идеи о том что можно улучшить. Гипотезу можно обернуть сразу в прототип. Современные возможности фигмы уже позволяют эмулировать прототип как будто вы работаете с живым интерфейсом. Паузы в отклике можно взять с текущего текущего сценария, если мы не можем повлиять на быстродействие. Конечно, в этом случае мы говорим о условности. Чтобы честно посчитать, замер нужно проводить на хотя бы тестовом стенде.
Собираем сводную табличку. Где описываем результаты. И собираем всю красоту в небольшой отчет. Где систематизируем баги, проблемы с UX, UI. Валидируем проблемы и ваши идеи с командой и оунером. Далее, бьем на таски, приоритизируем и тащим все это дело в беклог.
Спасибо за внимание. Расскажите в комментах используете ли вы такой метод в своей работе? Залетайте в канал @Uxelno – там кроме пользы, я публикую интересные примеры из жизни.
