Анализ юзабилити сайта – советы по аудиту и тестированию

Анализ юзабилити сайта - советы по аудиту и тестированию Аналитика

Почему юзабилити это важно

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

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

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

С точки зрения восприятия значение юзабилити следующее:

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

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

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

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

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

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

Это первое правило e-commerce.

В интернете, если пользователь не может что-то найти, он уходит. Даже если страница не грузится в течение более 2 секунд огромная доля пользователей отказывается от её просмотра.

  • Если пользователь не понимает, что конкретно предлагает компания, чем она занимается и чем может быть ему полезна, если её сайтом неудобно пользоваться, он уходит.
  • Если информация не представлена наглядно, её сложно читать, а по содержанию она не даёт ответов на его ключевые вопросы — он уходит.

Основные критерии оценивания

Существует 5 ключевых критериев, характеризующих уровень юзабилити ресурса:

  1. Простота. Насколько легко новому посетителю ориентироваться в пространстве и выполнять элементарные действия.
  2. Эффективность. Сколько времени требуется на достижение цели.
  3. Запоминаемость. Как быстро пользователь адаптируется к нюансам работы с сайтом, сможет ли оперативно разобраться при повторных посещениях.
  4. Полезность. Соответствует ли информация на сайте ожиданиям потенциального покупателя.
  5. Лояльность. В какой мере пользователь удовлетворен взаимодействием с ресурсом, возникает ли желание вернуться.

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

Юзабилити – качественный параметр, измеряющийся поведенческими метриками. В процессе тестов в первую очередь оценивают:

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

В единую оценку метрики собирает показатель SUM – Single Usability Metric. Это стандартизированный индекс юзабилити, который рассчитывается с учетом удовлетворенности, продуктивности и эффективности. Относительную величину сравнивают с конкурентами, эталонами рынка, под углом «до/после».

Также в ходе проверок используют опросники по шкале Лайкерта. Пользователям предлагается ответить на 10 вопросов. По ответам в System Usability Scale можно оценить простоту/сложность веб-сайта.

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

  • распределение трафика по устройствам;
  • браузерная совместимость;
  • дизайн, структура и содержание страниц;
  • формы и диалоги;
  • графика и цвета;
  • функциональность поиска;
  • форматирование текста;
  • логика расположения элементов;
  • кликабельность кнопок;
  • работоспособность адаптивной верстки или мобильной версии и так далее.

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

Анализ

Во время анализа обращайте внимания на ситуации, когда пользователь:

  • понимает задачу, но не может выполнить ее в намеченный срок;
  • понимает цель задачи, но вынужден перепробовать несколько вариантов для ее достижения;
  • не достигает цели задачи и досрочно прекращает выполнение сценария;
  • выполняет задачу, но не ту, которая была поставлена;
  • выражает удивление или удовольствие;
  • выражает разочарование и замешательство;
  • говорит, что ему что-то непонятно или неправильно реализовано;
  • предлагает внести изменения в интерфейс.

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

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

Метод RBT состоит из следующих показателей:

  • Rose — то, что работает хорошо или что-то положительное; зеленая карточка.
  • Bud — область возможностей или идей, которые еще предстоит изучить; синяя карточка.
  • Thorn — что-то не работает или что-то негативное; красная карточка.

Составление диаграммы сродства — процесс группирования по значимым признакам наблюдений и выводов исследования, на которые проектировщики интерфейсов опираются во время разработки продукта.

Как это делается? Мы анализируем первую задачу одного пользователя и фиксируем конкретные замечания и цитаты на стикерах. На каждом стикере написаны имена участников. Размещаем их на стене или доске. Далее следующий пользователь вносит свои данные. После нескольких тестов появляются общие вопросы и проблемы.

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

Задайте рейтинг найденным проблемам (Thorn) по шкале:

Из чего состоит юзабилити

Один из основоположников направления — специалист по интерфейсам Якоб Нильсен (Jakob Nielsen) — определил следующие компоненты юзабилити с точки зрения пользователя:

  • Усваиваемость — то, насколько легко пользователям выполнять базовые задачи, сценарии использования, когда они столкнулись с интерфейсом впервые;
  • Эффективность — насколько быстро пользователи могут выполнять задачи, когда они уже ознакомились с дизайном;
  • Запоминаемость — насколько просто пользователям восстановить навыки работы с интерфейсом, когда они возвращаются к нему после длительного периода;
  • Ошибки — частота возникновения ошибок в использовании, насколько они серьёзны и насколько легко пользователю восстановиться после них;
  • Удовлетворённость — насколько дизайн приятен в использовании.

Также Нильсен предлагает оценивать Пользу интерфейсов и определять Полезность по формуле:

Полезность = Юзабилити Функциональность, где

Функциональность — даёт ли интерфейс то, что вам нужно;

Юзабилити — насколько легко и приятно с ним работать.

Также Нильсен описал 10 принципов хорошего юзабилити:

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

Когда нужны метрики

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

  • Доказать. Часто, особенно в крупных компаниях, необходимость внесения в продукт изменений необходимо доказать. Цифры наглядны, понятны и привычны для лиц, принимающих решения. Поэтому когда вы показываете, что 10 из 12 респондентов не смогли оплатить товар, или что регистрация в системе в среднем занимает в два раза больше, чем у конкурентов, это придает результатам исследования больший вес.
  • Сравнить. Если вы сравниваете свой продукт с другими на рынке, вам также не обойтись без метрик. Иначе вы сможете увидеть достоинства и недостатки разных проектов, но не сможете оценить, какое место ваш продукт занимает среди них.
  • Увидеть изменения. Метрики хороши для регулярных тестов одного и того же продукта после внесения изменений. Они позволяют увидеть прогресс после редизайна, обратить внимание на те места, которые остались без улучшений. Использовать эти цифры вы можете опять же, как доказательную базу для руководства, показывающую вес вложений в редизайн. Или просто для понимания того, что вы достигли результатов и двигаетесь в нужном направлении.
  • Иллюстрировать, сделать акцент. Цифры хорошо помогают иллюстрировать важные проблемы. Иногда даже если мы не используем метрики во всех заданиях, мы считаем их для наиболее ярких и важных моментов теста.


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

Определение количества исследователей

Для качественного проведения наблюдения необходимо иметь следующие роли:

  • Интервьюер — проводит юзабилити-тестирование, используя UX testing plan & script. Часто такая роль достается самому проектировщику интерфейса.
  • Наблюдатель — уточняет детали и углубляется в них по мере протекания тестирования. В данной роли могут выступить продакт-оунер, эксперты предметной области или проектировщики интерфейса.
  • Модератор — должен придерживаться тайминга и следить за тем, чтобы все сценарии были воспроизведены пользователем. С этим хорошо справляются проджект- и продакт-менеджеры, скрам-мастеры. Еще приглашают на эту роль проектировщика интерфейсов.

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

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

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

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

Определение целевой аудитории

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

Например, вы работаете над финансовым продуктом и планируете изучить деятельность брокера в рамках создания CLO (collateralized loan obligation) бизнеса на американском рынке. В данном случае нужно понять алгоритмы взаимодействия инвест-банкира с другими финансовыми ролями.

Определиться с целевой аудиторией помогут предварительные опросники. Их создают как в бесплатных сервисах, например Google Forms, так и в платных — SurveyMonkey, Typeform и других.

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

Сопоставив план тестирования и предварительный опросник, вы сможете правильно выбрать потенциальных кандидатов для исследования.

Правила создания таких опросников очень просты:

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

Можно использовать дихотомические вопросы («да»/«нет» ответы), чтобы определить, на какой следующий вопрос будет отвечать респондент. Это несложно делается, к примеру, с помощью Google Forms.

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

В случае скользящей шкалы варианты 6-9 принадлежат категории «частично согласен», однако нет возможности понять, чем они отличаются. Здесь стоит избегать большого количества ответов без надобности.

Если хотите узнать, согласен или не согласен пользователь с чем-то, используйте четное количество оценок. Если же вас интересует также нейтралитет — применяйте нечетное количество оценок.

Выборка пользователей зависит от многих факторов:

  • вероятности появления ошибки у определенного процента респондентов;
  • однородности в выборке пользователя каждой роли;
  • наличия альтернативных путей прохождения сценариев;
  • степени сложности выполнения сценариев.

Давайте поговорим о вероятности возникновения ошибки у пользователя. Если у всех юзеров возникает одна и та же ошибка, то для тестирования вам понадобится всего лишь один пользователь, который с вероятностью 100% обнаружит эту проблему.

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

На сегодня есть калькуляторы для вычисления количества пользователей. Они базируются на средней вероятности обнаружения ошибки в одном исследовании. Однако проблема в том, что разные исследователи получают разные показатели этой вероятности. К примеру, Якоб Нильсен в свое время получил значение, равное p=0.31, в то же время исследования Спула и Шредера приводят к результату p=0.16.

Выбор вероятности — это всегда большой риск. Вы можете полагаться на свои исследования и провести расчет своей вероятности или использовать значения p=0.31 для простых сценариев и p=0.16 для сложных и разнообразных, полагаясь на исследования других.

При анализе различных исследований вытекает один бесспорный факт — чем больше пользователей вы протестируете, тем более точные получите результаты. Но что делать, когда вы ограничены количеством конечных пользователей?

До сих пор в мире спорят о том, какое же минимальное количество участников подходит для тестирования. По мнению Якоба Нильсена, это 5 человек, а по мнению Лауры Фолкнер — 10.

Я рекомендую начинать с 5-10 тестирований одного прототипа для проверки гипотез в качественных исследованиях и 10-20 тестирований — для количественных. Если ошибки начинают повторяться, это свидетельствует о том, что выборка пользователей однородная.

Если группа исследователей уверена, что понимает суть обнаруженных проблем, то она принимает решение исправлять их или нет. Если же нет, она продолжает тестировать текущий интерфейс, пока суть не будет ясна. После внесения правок тестирование начинается заново. Обычно подход RITE требует 5-6 итераций.

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

Получение пользовательского согласия

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

Я стараюсь делать в своих наблюдениях видео- и аудиозаписи. Это позволяет максимально точно зафиксировать все ответы и реакцию пользователя на выполнение задач. Как организатор тестирования вы должны всегда уведомлять человека об осуществлении записи в письменной или электронной форме.

Между тем в нескольких случаях у меня был отказ со стороны пользователей на применение каких-либо записей и приходилось документировать сессию вручную.

Пример:

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

Сеанс будет снят, но только для целей записи моих ответов (записи голоса) и для проверки моего поведения (видео), например, что я нажимаю и где на веб-сайте. Мое лицо будет видно интервьюеру и исследователям во время физического присутствия, но не будет присутствовать на видео.

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

Я понимаю, что участие является добровольным, и согласен немедленно задать любые вопросы, которые у меня могут возникнуть.

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

У меня было достаточно времени для принятия решения, участвовать ли в этом исследовании.

Я понимаю, что могу принять решение отказаться от участия или прекратить участие в любое время.

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

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

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

Предоставление необходимой информации

Дальше вам нужно посетителю представить всю необходимую информацию. Если это коммерческий проект, то человека будет интересовать следующее:

  • Цены
  • Скидки
  • Наличие
  • Условия оплаты
  • Срок отгрузки
  • Описание и характеристики
  • Дополнительные опции

Ведь люди не идут специально искать по сайту чтобы узнать, а почему же стоит купить именно у этой компании.

Тут все как в обычном магазине или бизнесе. Если человек что-то у вас спрашивает, то с рассказом о товаре нужно будет параллельно убеждать почему ему стоит купить именно у вас.

Например, если человек купил у вас велосипед, то обязательно нужно упомянуть ему про наличие сервиса по обслуживанию этого товара.

Расскажите, что ему будет очень удобно.

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

И в таком случае человек понимает, что лучше купить велосипед здесь, чем идти в другой магазин.

Поэтому пока пользователь ищет необходимую ему информацию, вам нужно параллельно показать свои преимущества. Вот какую информацию нужно дополнительно показывать посетителям:

Есть информация, которая нужна человеку чтобы к вам обратиться. А есть информация, которую вам нужно донести. И вы должны понимать, что такой контент не просто имеется на сайте, а что люди ее видят.

Посмотрите, доходят ли люди туда. Какая часть из них доходит до этой информации. Посмотрите, с каких страниц посетители уходят с сайта. Обратите внимание на поведение пользователей на этих страницах.

Важно понимать, что есть два типа страниц выхода с сайта:

  1. Посетитель сайта нашел нужную информацию и ушел для принятия решения
  2. Пользователь сайта не нашел нужную информацию и покинул сайт

Проведение наблюдения

Важный момент во время всего процесса тестирования — наблюдение за пользователем. Существует множество причин, для чего это может понадобиться, но выделим две основные:

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

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

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

Во время выполнения задач попросите участников комментировать свои действия и делиться мыслями вслух. Это позволит точнее понять их действия. Не кивайте, если респондент дает правильный ответ и тем более не демонстрируйте отчаяние, если он не справляется с задачей.

Не используйте профессиональные термины в беседе, так как пользователь может не понять, что такое, к примеру, «кастомные контролы», «нативный алерт» или «мегаменю». Слушайте, что он говорит, и употребляйте понятные слова и объяснения.

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

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

Видео-, аудиозапись для фиксации ответа не исключает личного протоколирования сессии на случай, если записи потеряются или сотрутся.

Делайте заметки с помощью предварительно подготовленной структуры. В UX testing plan & script обычно использую колонку для записи пользовательских комментариев к каждому шагу сценария. Во время выполнения задач делаю небольшие заметки в виде «прошел/не прошел сценарий», «возникали/не возникали сложности». Эти заметки можно привязать к соответствующим моментам видео, и вы сможете легко вернуться к ним позже.

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

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

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

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

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

Сервисы «яндекс.метрики»

Система аналитики «Яндекс.Метрика» включает несколько бесплатных инструментов для юзабилити-тестирования:

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

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

  • тепловая. Отображает наиболее кликабельные места теплыми цветами, зоны с редким взаимодействием – холодными;
  • монохромная. Отмечает частые клики более насыщенным оттенком на фоне основного;
  • карта прозрачности. Со светлыми пятнами в местах сосредоточения кликов;
  • по ссылкам и кнопкам. Со статистикой только по этим элементам.

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

4. Аналитика форм. Сервис для анализа взаимодействия пользователей с формами и строкой поиска на сайте.

Данные представляются в 2 вариантах:

  1. Конверсия. Информация о числовых и процентных показателях относительно визитов на страницу, заполнений и отправок данных, доли конверсий.
  2. Поля. Информация о заполняемых полях и времени, затрачиваемом на каждую строку.

Отчеты помогают отследить периодичность просмотра элементов, выявить частоту заполнения форм и строки, которые зачастую игнорируют.

Сервисы google

В Google есть целый комплекс инструментов, с помощью которых можно оценивать и тестировать уровень удобства восприятия ресурса:

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

2. Optimize. Инструмент для настройки A/B тестов, сравнения разных вариантов страниц, оценки однородности трафика. Работает совместно с системой аналитики и входит в состав платформы для маркетинга.

3. Mobile-Friendly Test. Сервис для проверки оптимизации страниц под мобильные устройства. Показывает корректность отображения и оповещает о критических ошибках. Для этого достаточно ввести url-адрес сайта.

4. Tag Manager. Система управления тегами, которая позволяет устанавливать и обновлять код отслеживания на сайте и в мобильном приложении. Связывает сайт, аналитику и другие юзабилити-инструменты.

5. Google Forms. Онлайн-инструмент для проведения опросов. Хороший способ услышать мнение первоисточника. Для этого нужно создать небольшую анкету с вопросами об удобстве сайта и вставить ссылку на ее в сообщения для email или мессенджеров. Из ответов можно будет узнать много полезной информации о сильных и слабых сторонах проекта.

6. PageSpeed Insights. Сервис, который анализирует наполнение веб-страниц и составляет отчеты о скорости загрузки на компьютерах и мобильных устройствах. В отчетах дается общая оценка в баллах и рекомендации для ускорения показателей.

Создание плана тестирования


Для формирования плана тестирования нужно прежде всего определить:

  • Какой продукт или продукты планируете изучить? Например, закрытая Product Experience Management веб-платформа, обеспечивающая управление всей информацией о товаре/изделии.
  • Что будет предметом тестирования? К примеру, та же веб-платформа или кликабельный адаптивный прототип ее новой версии.
  • Какие типы устройств будут использованы? Например, персональный компьютер (ПК), планшет и мобильный телефон.
  • Какие роли и функции пользователей будут протестированы? Допустим, роль: PDM-администратор. Функции/задачи: создание шаблона для товара или изделия, проверка шаблона товара, утверждение шаблона.

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

Для наблюдения я, как правило, готовлю документ для каждого пользователя — дорожную карту, которая рассказывает, что и как делать и на какие вопросы отвечать. Документ называется UX testing plan & script и состоит из таких элементов:

  • вступление;
  • погружение пользователя в контекст решаемых задач;
  • описание задач и список шагов с возможностью занесения комментариев по каждому из них;
  • список вопросов к каждой задаче;
  • заключительный раунд вопросов.

Не пытайтесь выявить все проблемы юзабилити в большом продукте сразу. Гораздо эффективнее раздробить сценарии на отдельные небольшие исследования по ролям с определенной целью в каждом из них.

Обычно при формировании задач провожу их декомпозицию. Что это такое? Я заменяю решение одной задачи на серию мелких простых и связанных между собой подзадач с конкретной целью в каждой.

Давайте рассмотрим пример. Сценарий задачи «Как пользователь я могу забронировать понравившийся отель» на самом деле состоит из ряда мелких подзадач:

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

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

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

Не стоит забывать, что задачи для качественных и количественных методов разные. Давайте рассмотрим примеры задач для каждого из них.

Задача для качественных исследований: найдите на сайте отчет за первый квартал 2021 года.

Задачи для количественных исследований:

А. Используя глобальный поиск на сайте, найдите отчет за первый квартал 2021 года.В. Используя раздел Reports на сайте, найдите отчет за первый квартал 2021 года.

Способ фиксации данных

Анализ юзабилити сайта - советы по аудиту и тестированию

Казалось бы, чем плох блокнотик и ручка или просто открытый документ Word? В современном Agile мире разработки UX-исследователи должны стараться максимально быстро выдавать команде результаты своих наблюдений. Чтобы оптимизировать время на анализ, хорошо заранее заготовить шаблон для ввода ваших заметок в процессе теста.

Мы пробовали делать это в специализированном ПО (например, Noldus Observer или Morae Manager), но на практике наиболее гибкими и универсальными оказались таблицы. Заранее разметьте в таблице вопросы, которые точно планируете задавать, места под ввод проблем, обнаруженных в различных заданиях, а также гипотезы (вы будете помечать, подтвердилась она или нет на каждом респонденте). Наши таблички выглядят подобным образом:

Респондент 1Респондент 2Респондент 3Респондент 4
Задание 1
Заметил ли функцию А?
В каком месте искал возможность Б?
Проблемы и наблюдения по заданию

Вы также можете воспользоваться:

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

Оцените статью
Аналитик-эксперт
Добавить комментарий