Ux тестирование: Как провести UX тестирование? Расскажем в Evergreen

21 метод UX-исследований: какой выбрать / Хабр

Нравится тебе оно или нет, но при создании ИТ-продукта никак не обойти тему проверки UX на прочность. Любой специалист, которому хоть сколько-нибудь не наплевать на свою работу, хочет, чтобы результаты потраченных человеко-часов были по достоинству оценены конечным пользователем.

Часть методов UX-исследований настолько очевидны и прямолинейны, что у некоторых из ИТ-шников при первом знакомстве в классификацией тестов появится логичный вопрос «А что, кто-то этого не делает?» и следующий за ним «Их ещё не поувольняли?».

Давайте признаемся, мы ведь все тестируем UX, иногда даже не ставя себе в явном виде такую задачу. Кто-то называет это пафосным словом «исследование», а кто-то вообще никак не называет, но всё-равно тестирует втихаря.

В этой статье собран 21 метод UX-исследований. Некоторые из них простые и банальные, некоторые более изощрённые. Выбирай тот, что тебе по вкусу. Но сначала посмотрим, какими характеристиками они отличаются.

Отличия методов

Количественный/качественный. Часть исследований даёт измеримый результат, например, собранный системой аналитики или посчитанный по итогам опроса. Такие исследования мы зовём количественными. В других случаях возможна только качественная оценка, т.е. состоящая из суждений исследователя или участника (удобно – неудобно, просто – запутанно и т.п.).

Логичным образом это связано и с количеством исследуемых. Чем их больше (количественный метод), тем сложнее разбирать каждый случай в отдельности и проще оперировать усреднёнными цифрами. Чем меньше тестируемых (качественный метод), тем меньше смысла полагаться на цифры, так как при маленьких выборках они могут сильно разниться. Тогда приходится прибегать к качественной оценке и выяснять не «сколько» людей сделали или сказали что-то, а «почему» они это сделали или сказали.

Поведенческий/отношенческий. Поведенческие методы отвечают на вопрос «Что делают пользователи?», отношенческие – на вопрос «Что думают пользователи?» Ответы далеко не всегда совпадают, но в зависимости от цели исследования оба одинаково важны.

Участие продукта. По степени участия продукта в исследовании выделяют методы:

• c естественным использованием продукта
• с использованием продукта по заранее созданному сценарию
• без участия продукта
• смешанные, состоящие из комбинаций выше приведённых методов

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

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

Методы UX-исследований

1. Проверка концепции
2. Сортировка карточек
3. Фокус-группа
4. Этнографическое исследование
5. Привлечение к проектированию
6. Древовидное тестирование
7. Оценка предпочтений
8. Лабораторное исследование
9. Айтрекинг
10. Исследование «дневников»
11. Удалённое исследование
12. 5-секундный тест
13. Немодерируемое панельное исследование
14. A/B-тестирование
15. Юзабилити бенчмаркинг
16. Экспертный обзор
17. Кликстрим
18. Сбор обратной связи
19. Email-опрос
20. Исследование истинного намерения
21. Интервью

1. Проверка концепции (Concept Testing)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: отношенческий
Участие продукта: смешанное
Этап: планирование

Обзор

Метод сосредоточен на выделении ключевых качеств продукта, чтобы определить, соответствуют ли они потребностям целевой аудитории. Тот, кто знаком с концепцией MVP (minimum viable product), наверняка понимает, о чём речь. Может выполняться как один-на-один, так и с большей аудиторией. Главная цель — понять, есть ли хоть какая-то потребность в таком продукте.

Когда использовать

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

2. Сортировка карточек (Card Sorting)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: отношенческий
Участие продукта: естественное
Этап: планирование

Обзор

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

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

Когда использовать

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

3. Фокус-группа (Focus Groups)

Качественный/количественный: качественный
Поведенческий/отношенческий: отношенческий
Участие продукта: без участия
Этап: планирование, разработка

Обзор

Группа из 3–10 участников под руководством модератора обсуждает свои взгляды на будущий продукт. Роль модератора — скорее поддерживать поток мнений, чем направлять его. Фокус-группа может ответить на несколько основных вопросов, но не должна превращаться в интервью (см. метод №21).

Когда использовать

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

4. Этнографическое исследование (Ethnographic Field Studies)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: возможны оба
Участие продукта: естественное
Этап: планирование, разработка

Обзор

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

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

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

Когда использовать

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

5. Привлечение к проектированию (Participatory Design)

Качественный/количественный: качественный
Поведенческий/отношенческий: отношенческий
Участие продукта: естественное или по сценарию
Этап: планирование, разработка

Обзор

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

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

Когда использовать

В качестве «мозгового штурма» при проектировании продукта. Позволяет найти неожиданные полезные идеи, которые помогут улучшить UX-решение.

6. Древовидное тестирование (Tree Testing)

Качественный/количественный: количественный
Поведенческий/отношенческий: поведенческий
Участие продукта: без участия
Этап: планирование, разработка

Обзор

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

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

Когда использовать

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

7. Оценка предпочтений (Desirability Studies)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: отношенческий
Участие продукта: естественное, по сценарию
Этап: планирование, разработка

Обзор

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

Когда использовать

Когда необходимо понять, какие субъективные ощущения вызывает у пользователей дизайн. Целесообразно проводить на ранних стадиях разработки продукта.

8. Лабораторное исследование (Usability-Lab Studies)

Качественный/количественный: качественный
Поведенческий/отношенческий: поведенческий
Участие продукта: по сценарию
Этап: разработка

Обзор

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

Подробнее о том, как подобное исследование проводится, можно почитать в статье «UX-исследование ДБО: наш опыт, ошибки и открытия».

Когда использовать

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

9. Айтрекинг (Eyetracking)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: поведенческий
Участие продукта: естественное или по сценарию
Этап: разработка

Обзор

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

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

Когда использовать

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

10. Исследование «дневников» (Diary/Camera Studies)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: отношенческий
Участие продукта: естественное
Этап: разработка

Обзор

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

Реализовать это можно разными способами: с помощью «бумажного» журнала, приложения для заметок или аудио- и видеосообщений. Пользователей инструктируют о ведении записей и по возможности настраивают ежедневные напоминания.

Когда использовать

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

11. Удалённое исследование (Remote Usability Studies)

Качественный/количественный: скорее качественный
Поведенческий/отношенческий: поведенческий
Участие продукта: по сценарию
Этап: разработка, подведение итогов

Обзор

Аналог лабораторного исследования, проводящийся удалённо, например, с использованием ПО для удаленного доступа. Бывает модерируемым, когда участники получают комментарии и вопросы от специалиста, и немодерируемым, когда задания выполняются самостоятельно.

Когда использовать

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

12. 5-секундный тест (Five second test)

Качественный/количественный: качественный
Поведенческий/отношенческий: отношенческий
Участие продукта: без участия
Этап: разработка, подведение итогов

Обзор

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

Когда использовать

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

13. Немодерируемое панельное исследование (Unmoderated Remote Panel Studies)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: возможны оба
Участие продукта: естественное или по сценарию
Этап: разработка, подведение итогов

Обзор

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

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

Когда использовать

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

14. A/B-тестирование (A/B Testing)

Качественный/количественный: количественный
Поведенческий/отношенческий: поведенческий
Участие продукта: естественное
Этап: разработка, подведение итогов

Обзор

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

После достижения статистической значимости делается вывод, какой вариант победил по выбранному KPI (например, покупки в приложении). Проводится в специальных сервисах, таких как Google Optimize для сайтов и Optimizely для приложений.

Когда использовать

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

15. Юзабилити бенчмаркинг (Usability Benchmarking)

Качественный/количественный: количественный
Поведенческий/отношенческий: поведенческий
Участие продукта: по сценарию
Этап: разработка, подведение итогов

Обзор

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

Когда использовать

Когда нужно отследить или продемонстрировать прогресс в оптимизации продукта. Для оценки эффективности решения как такового, в особенности при переходе между циклами разработки.

16. Экспертный обзор (Expert Review)

Качественный/количественный: качественный
Поведенческий/отношенческий: отношенческий
Участие продукта: естественное или по сценарию
Этап: разработка, подведение итогов

Обзор

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

Когда использовать

Для получения свежего взгляда со стороны — помогает заметить мелочи, на которые «замыленный» глаз не обращал внимания. Также подходит, когда команде UX-дизайнеров не хватает собственной экспертизы.

17. Анализ кликстрима (Clickstream Analysis)

Качественный/количественный: количественный
Поведенческий/отношенческий: поведенческий
Участие продукта: естественное
Этап: разработка, подведение итогов

Обзор

Анализ данных о том, какие страницы и в каком порядке посещал пользователь. Легко провести с помощью системы аналитики Google Analytics, Яндекс.Метрика, Firebase, Mixpanel. Позволяет выявить проблемы, связанные с навигацией по сайту или приложению. Не помогает с поиском их причин. Для выяснения причин стоит использовать юзабилити-исследования (методы №8, №11).

Когда использовать

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

18. Сбор обратной связи (Customer Feedback)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: отношенческий
Участие продукта: естественное
Этап: подведение итогов

Обзор

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

Когда использовать

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

19. Email-опрос (Email Survey)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: отношенческий
Участие продукта: без участия
Этап: подведение итогов

Обзор

Анкетирование пользователей по email, в отличие от сбора обратной связи, общее и не триггерное. Касается предыдущих взаимодействий с продуктом, поэтому оценивает только его восприятие аудиторией. Проще для проведения, чем интервью (см. метод №21), но выше вероятность отказа. Количество вопросов обычно не превышает 10, чтобы не отпугнуть респондентов.

Когда использовать

Для анализа эффективности действующего продукта и сравнения с конкурентами.

20. Исследование истинного намерения (True-Intent Studies)

Качественный/количественный: количественный
Поведенческий/отношенческий: возможны оба
Участие продукта: естественное
Этап: подведение итогов

Обзор

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

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

Когда использовать

После запуска продукта, когда достаточный объём трафика достигнут. Чтобы узнать, отвечает ли разработка запросам пользователей, и выполняет ли задуманные функции.

21. Интервью (Interviews)

Качественный/количественный: качественный
Поведенческий/отношенческий: отношенческий
Участие продукта: без участия
Этап: подведение итогов

Обзор

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

Когда использовать

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

Итог

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

Статью для вас написали: Денис Элиановский, Станислав Лушин.

Спасибо Елене Ефимовой за инфографику, Татьяне Китаевой за редактуру.

Читать на английском

Список источников:
When to Use Which User-Experience Research Methods
7 Great, Tried and Tested UX Research Techniques
Five second tests
Tree Testing: Fast, Iterative Evaluation of Menu Labels and Categories

подробный гид / Блог компании Luxoft / Хабр

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

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

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

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

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

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

В проведении юзабилити-тестирования выделим следующие этапы:

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

Определение цели

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

• Что для вас в исследовании будет важным? Какие роли пользователей или их конкретные задачи стремитесь протестировать?
• Что надеетесь зафиксировать в заметках? К примеру, хотите использовать видеосъемку, а в протоколах помечать интересные моменты с привязкой к видео для быстрого поиска и обработки обратной связи.
• Планируете ли изучить рабочее пространство пользователей? Есть случаи, когда оно влияет на организацию интерфейса.
• Есть ли необходимость в фото- или видеосъемке в процессе наблюдения за пользователем? Возможно, какие-то сценарии проще записать на видео. Например, при проектировании мониторинговой системы скважин необходимо понять, с какими устройствами передачи данных взаимодействует Service Supervisor и какое количество мониторов он использует.
• Какие метрики будут использованы в тестировании? Количественные и/или качественные? Это зависит от того, что вам в исследовании интересно и что проверяете. Если работаете над приложением, предназначенным для рабочего процесса пользователя, вряд ли вас будет интересовать степень его вовлеченности. Вы, очень вероятно, будете заинтересованы в скорости прохождения сценариев, количестве пользовательских ошибок, выполненных сценариев и степени удовлетворенности пользователя.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В качественных исследованиях мы поймем пользовательское предпочтение user-flow, а в количественных — разъясним, все ли шаги конкретного user-flow понятны пользователю. Качественные и количественные исследования должны дополнять друг друга, а не противопоставляться.

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

Пример сценария: клиент попросил вас подготовить отчет, и вы хотите начать с поиска информации в рамках сайта www.sample.com.

Задача: пожалуйста, войдите в систему, используя свой логин и пароль.

Шаги:

• Открыть браузер.
• Ввести в адресную строку www.sample.com.
• Ввести электронную почту в поле Email.
• Ввести символы в поле Password.
• Нажать кнопку «Вход».

Альтернативные шаги:

• Открыть браузер.
• Ввести в адресную строку www.sample.com.
• Нажать ссылку «Забыли пароль».
• Ввести свою электронную почту.
• Открыть почтовый клиент.
• Найти письмо от сервера об авторизации.
• Перейти по ссылке.
• Ввести новый пароль.
• Повторить пароль.
• Нажать кнопку «Сменить пароль».

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

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

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

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

• Интервьюер — проводит юзабилити-тестирование, используя 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, когда правки вносятся в интерфейс по мере обнаружения проблем. Проводится тестирование одного пользователя.

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

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

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

Организация доступа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Анализ

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

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

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

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

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

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

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

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

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

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

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

• Критическая ошибка. Не работает какая-то кнопка, если это не исправить, пользователи не смогут завершить сценарий. Например, человек ищет отели на сайте-агрегаторе, но не может залогиниться или не отображается результат.
• Серьезная ошибка. Пользователи будут расстроены, если мы не исправим ошибку. Также есть вероятность, что они сдадутся и не пройдут сценарий. Например, выдача в поиске на сайте бронирования отелей занимает 10 секунд. Многие юзеры не заходят ждать и уйдут на другие ресурсы.
• Минорная ошибка. Пользователи будут раздражены, но это не помешает им завершить сценарий. Например, ожидание отображения результатов сократится до 5 секунд. Это продолжит раздражать, но человек, скорее всего, останется на сайте, так как он уже потратил свое время и не пойдет искать другой сайт, несмотря на то, что ожидание результатов на нем может быть немного меньшим.

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

В процессе анализа также будьте готовы получить интересные факты, которые не были связаны с тестирующими сценариями. Например, при тестировании сценария «создание чата» в Microsoft Teams веб-версии вы поймете, что у пользователя несколько разных рабочих аккаунтов. Ему приходится быть авторизованным в системе под разными аккаунтами в разных вкладках браузера. Сделать такое в desktop-версии невозможно, соответственно, вы получите новый инсайт о том, как пользователи с разными учетными записями «решают» эту задачу, используя ваш продукт.

При анализе обратной связи стоит задуматься над такими вопросами:

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

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

Заключение

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

Анализ и обнаружение ошибок — это всегда субъективный процесс. Те результаты, к которым придете, — это исключительно ваше понимание ситуации. Поэтому чем разнообразней будете подбирать команду исследователей, тем разностороннее истолкуете суть проблемы.

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

Автор: Eugenia Grubaya, Senior Usability Architect
Источник

Руководство по юзабилити-тестированиям — опыт Mail.Ru Group — Офтоп на vc.ru

План тестирования — это, с одной стороны набор заданий, вопросов и опросников, которые вы даете каждому респонденту, а с другой — методологическая база исследования: метрики и гипотезы, которые вы проверяете и фиксируете, выбранный инструментарий.

Точно ли нужно тестирование

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

Например, мы никогда не беремся в качественных исследованиях проверять «привлекательность» какой-то функции или варианта дизайна. Мы можем собрать с пользователей отзывы, но слишком велик риск, что на их ответы повлияет социальная желательность. Люди всегда склонны сказать, что стали бы пользоваться даже тем, чем пользоваться не будут. Да и маленький размер выборки не позволяет доверять таким ответам. Например, у нас был неудачный опыт тестирования игровых лендингов: лендинг, который выбирали как наиболее привлекательный на тесте, при A/B-тестировании отработал гораздо хуже.

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

Основа для составления сценария юзабилити-теста

Планирование тестирования начинается не с составления текста заданий, а с детальной проработки целей и вопросов исследования совместно с проектной командой. Вот основа для составления плана:

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

Юзабилити тестирование — как проводить тестирование usability сайта

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

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

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

С чего начать

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

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

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

1. 
   Откуда пришел пользователь?
2. 
   Что он должен увидеть на этой странице?
3. 
   С какой целью он пришел на страницу?
4. 
   Чем должно закончиться посещение?

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

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

Что можно померить

Количественные исследования всегда конкретны и сфокусированы, нацелены на получение числовых показателей. Это может быть время выполнения действий на сайте или доля респондентов, выполнивших задание. Результаты «да/нет» тоже можно представить в виде цифр. Например, привести их в бинарную систему: да — 1 балл, нет — 0 баллов.

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

• 
  выполнил самостоятельно — 100%;
• 
  выполним с помощью модератора — 50%;
• 
  не выполнил — 0%.

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

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

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

• 
  само собой разумеющимся;
• 
  конкурентным преимуществом сайта;
• 
  функциями, которые вызывают у них восторг;
• 
  неважным.

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

Какой выбрать метод

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

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

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

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

Теневой метод. Одновременно работают три участника: респондент, модератор и эксперт. Респондент свободно и независимо выполняет задания, модератор фиксирует, эксперт комментируют действия респондента.

Ретроспектива. Это метод, который сочетает в себе наблюдение и «мысли вслух». Сначала респондент выполняет задания, затем — смотрит видеозапись своих действия и комментирует их. Основной недостаток — значительное увеличение времени тестирования.

Что подготовить к тестированию

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

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

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

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

• 
  Задания без конкретики дают простор для респондентов. Их цель — посмотреть, с чего вообще начинается взаимодействие пользователя с сайтом. Предоставьте респондентам свободный выбор, не отвечайте на их вопросы, чтобы не нарушать естественность реакций. Лучше всего, если респондент будет находиться один. Такие задания подходят для новых продуктов и контентных сайтов. Модератор видит, что привлекает внимание, как используют навигацию, читают ли ознакомительные материалы или инструкции.

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

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

Увеличение количества человек приведет к уменьшению разброса результатов. Обычно 85% проблем обнаруживаются первыми пятью респондентами. Поэтому для оптимизации затрат на тестирование чередуйте тесты и доработки. Сначала проведите тестирование, затем доработайте продукт с учетом найденных проблем. Снова проведите тестирование и снова доработайте. Трех подходов будет достаточно.

Как проводить тестирование

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

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

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

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

Запомните

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

Для более глубокого погружения в тему советуем посмотреть видео с последней конференции eTarget 2018.

Материал подготовила Светлана Сирвида-Льорентэ.

UX-исследования — что это и как провести, виды и аналитика UI-тестирований

Можно бесконечно круто дизайнерить, но ваш продукт так и останется невостребованным. И тут два варианта: либо вы непризнанный гений, либо плохо изучили (или не изучили) потребности пользователей. Для решения второй проблемы как раз и созданы UX-исследования. Если вы хотите сделать продукт, который нужен пользователю и прибылен для вас (компании), то UX-исследования — неотъемлемая часть проектирования.

Если представить процесс проектирования как айсберг, то UX-исследования и анализ UI — это его скрытая часть. Процесс изучения потребностей пользователей, их поведения, эмоций остаются «под водой», но без этой подводной части верхушка айсберга (итоговый дизайн) не сложится.

Все начинается с пользователя

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

Любое исследование, такое как UI или UX, важно правильно спланировать. Томер Шарон, старший научный сотрудник UX в Google, на этапе планирования предлагает задать себе 5 вопросов:

1. 
   Какую информацию вы хотите получить?

2. 
   Зачем/что дадут вам эти данные?

3. 
   Какие пробелы вы намерены заполнить этими знаниями?

4. 
   Каковы решения?

5. 
   Каковы ваши текущие предположения?

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

Когда нужны UX-исследования

Очевидно, что UX-исследования всегда должны проводится на этапе запуска нового продукта, а также в процессе работы, если вы видите какие-либо проблемы. Например, вы выгрузили аналитику и увидели, что пользователи бросают корзину. Ответ на вопрос «почему?» дают UX-исследования.

UX-исследования отвечают на вопросы:

• Что люди делают?
• Как они себе это представляют?
• Что люди говорят?
• Как исправить?
• Сколько?
• Почему?

Стоит заметить, что UX-исследования — это история не про «нравится ваш продукт или нет», а про «закрывает он потребности пользователя или нет».

Методы UX-исследований

Методов UI- и UX-исследований множество. Наиболее используемые: интервью, опросы, UX-тестирования, карточная сортировка, A/B тестирования. К этой информации мы еще вернемся и расскажем подробнее.

Методы исследований UX делятся на два больших лагеря: количественные и качественные.

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

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

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

Методы UX-исследований

Интервью

Интервью является проверенным и надежным способом общения исследователя и пользователя. Выделяют три основных типа интервью:

1. 
   Направленные интервью. Это наиболее распространенный вид. Представляет собой формат вопрос-ответ. Исследователь задает конкретные вопросы. Такое интервью полезно, если предстоит общение с большим количеством пользователей для удобного сопоставления ответов.

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

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

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

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

Сортировка карточек

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

Юзабилити-тестирование

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

Древовидные тесты

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

А/В-тестирование

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

Еще раз о том, зачем все это нужно?

У UX-дизайна две основные задачи:

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

2. 
   Повысить лояльность пользователей (продлить подписку, сделать так, чтобы пользователи возвращались на сайт/в приложение).

Чтобы реализовать эти цели, рекомендуется проводить UX-исследования, которые помогают сделать ваш продукт полезным, удобным и реально используемым.

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

И в качестве вывода предлагаем вам запомнить 5 главных правил эффективных UX-исследований:

1. 
   Знать вопрос, на который вы хотите получить ответ.

2. 
   Понимать, зачем вам нужны эти ответы.

3. 
   Подобрать нужные методы и методики.

4. 
   Оценить ресурсы: деньги и время.

5. 
   Определить условия проведения исследования: где, когда, с кем.

Закажи юзабилити-тестирование прямо сейчас

Заказать

наш опыт, ошибки и открытия / Хабр

Привет. Я Денис Элиановский, дизайн-директор в JTC и руководитель в Opium Pro. Мы работаем в очень узких сегментах рынка IT, связанных с финансами и документооборотом. Вы точно ещё не слышали об этих компаниях и сегодня мало что о них узнаете, ведь эта статья про UX-исследования.

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

Что такое ДБО? Расшифровывается как Дистанционное Банковское Обслуживание. Ещё эти приложения называют онлайн-банками. Наверняка у всех вас уже есть такое в телефоне. Вот мы одни из тех, кто такие приложения дизайнит и разрабатывает.

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

Кому удобнее смотреть видео, тут запись выступления

Какие бывают тесты?

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

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

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

Ещё исследования можно поделить на поведенческие и отношенческие. Когда мы проводим поведенческие тестирования, то следим за тем, что человек делает с нашим приложением. В отношенческих же важно, что человек говорит про наше приложение.

В этой статье мы сосредоточимся на Usability-тестах. Они относятся к поведенческим качественным тестам. В данном случае к тестированию привлекается небольшое количество человек и внимательно изучается в основном то, что они делают с приложением.

Процесс создания дизайна хорошо отражается графиком Дэмиена Ньюмана.

И поскольку выше я говорил, что дизайн и тестирование должны быть единым целым, то график отражает как процесс создания дизайна, так и его тестирование. Из этого графика можно сделать два вывода. 1) Дизайн и его тестирование — процесс нелинейный. 2) И еще это процесс итерационный. Это же очевидно при первом взгляде на график, не правда ли?

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

Называя процесс итерационным, я имею в виду то, что нельзя провести тестирование один раз и на этом остановиться. Тестирование нужно проводить регулярно. Именно тогда в нём есть смысл. Особенно учитывая то, что дизайн в процессе тоже сильно меняется.

Как подготовиться к UX-исследованию?

1. Usability-тест начинается с выдвижения гипотезы. Что такое гипотеза? Это наше предположение, как конкретный человек будет пользоваться нашим приложением. То есть по какому сценарию он пойдёт. Выдвигая гипотезу, мы изучаем постановку от аналитиков, стараемся учесть наш личный опыт использования подобных приложений (если он есть), составляем User Story Map. На основании User Story Map создаётся кликабельный прототип приложения.
2. Составляем опросник. Важно, чтобы он был небольшим. Если тестировать людей подолгу, они просто начнут уставать. Идеально, если на одну сессию с одним человеком уйдёт 10–15 минут, максимум 20 (после этого для удержания внимания респондента возможно придётся прибегать к крайним мерам: брать в заложники его родных, одурманивать, апеллировать к чести и богу). Чтобы уложиться в нужное время, нам обычно хватает 5–7 вопросов-сценариев. Вопросы должны быть открытыми, это важно. То есть это те вопросы, на которые нельзя просто ответить «да» или «нет», мы должны спровоцировать человека поделиться с нами чем-то, открыть нам душу.
3. Собираем группу людей. Она также должна быть небольшой (5–7 человек). Ведь мы проводим качественные тесты, что предполагает использование небольших выборок. Набирать людей можно тоже по-разному. Интервью мы можем назначать заранее и некоторым людям даже немного приплачивать за это, а можем выходить «в поля» и искать подходящих людей в кафе и прочих общественных местах.

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

Давайте для закрепления ещё раз повторим, что нужно для подготовки.

1. Выдвижение гипотезы

На картинке ниже представлено несколько возможных вариантов визуализации данного процесса.

Самый левый скрин — это то, как можно подручными средствами сделать User Story Map. Для этого достаточно просто использовать бумажные стикеры. Соединяя их ниточками, мы показываем предположения относительно того, как пользователь будет ходить по приложению.

Второй вариант — User Story Map, нарисованная в Miro. По сути те же самые бумажки, только перенесены в электронный вид для удобства.

И третий скрин — кликабельный прототип в Figma.

Выше указаны конкретные инструменты, но на самом деле к ним привязки нет, и строить гипотезы можно в чём вам удобно. Например, в нашей команде есть энтузиасты, которые всё тестирование проводили на бумажках. Кликабельный прототип у них был тоже на бумажках, — и с этого тоже можно начать.

2. Составление вопросов

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

Пример:

3. Сбор респондентов

Этот график составил Якоб Нильсен еще в 1990-х годах. Уже тогда UX-исследования проводились.

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

Более эффективно делать маленькие выборки, но делать это часто.

Сначала хотел посоветовать книжку Якоба, но вообще она уже старая. Есть кое-что получше. Автор продолжает заниматься UX-исследованиями, и вот его сайт, там много статей: nngroup.com

Процесс тестирования

Чертовски важно все тестирования записывать на видео. Видео — это самый главный артефакт тестов. Если у вас нет видео, то можно сказать, что тестирование вы не проводили.

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

Во-вторых, и мы называем это правило «5 почему?», в процессе прохождения сценария нужно провоцировать человека объяснять любую свою остановку или сомнение в своих действиях. Тут очень помогают такие вопросы: «Что Вы ожидали увидеть на этом экране?», «Почему Вы нажали на вот эту кнопку?». Не всегда это именно 5 почему, но стремление задать как можно больше вопросов и как можно сильнее погрузиться в голову человека всегда помогает.

И третье. По результатам тестов мы спрашиваем «Считаете ли Вы, что справились с задачей?». Причем на этот вопрос отвечает не только респондент, но и человек, который тестирует. Почему мы это делаем, я расскажу ниже.

Теперь перейдём непосредственно к нашим тестам. В таблице представлено, как могут выглядеть сводные результаты исследований. Это реальные результаты нашего первого теста.

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

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

Мы тестировали наше мобильное приложение ДБО для физических лиц. В общей сложности на момент создания этого отчёта прошло две итерации тестов, в каждой из которых было протестировано по 6 человек. Всего 7 женщин, 5 мужчин в возрасте от 20 до 50 лет.

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

Благодаря просьбе нашего клиента, во второй сессии в выборку было включено больше людей в возрасте 40+. И именно в этой аудитории было выявлено больше всего ошибок. Они чаще всего где-то запинались, где-то останавливались, и им приходилось задавать больше всего вопросов.

Итоги теста

Итоги теста с точки зрения «справились / не справились»:

Получилось, что тестируемые справились с 93% задач. При этом сами они считали, что справились только с 83%. Эта разница в 10% — те моменты, когда человек прошёл по нужному сценарию, наш тестировщик видит, что он с задачей справился, но респондент в результатах не уверен. И это тоже проблемы, над которыми нужно работать. Ведь мы понимаем, что в таких моментах приложение не даёт человеку нужного фидбека и это необходимо исправить. В среднем на одну сессию ушло 12 минут. Неплохой результат, с учётом того, что мы ориентировались на 10-15 минут.

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

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

Допустим, мне необходимо оплатить мобильный телефон. Наверное, должна быть где-то кнопка «оплатить». Не нахожу кнопку и ухожу ее искать в бургер-меню слева в верхнем углу.

В чём проблема? На экране две кнопки «оплатить», ни одну из них человек не заметил. Это было в 3 случаях из 6.

Ещё проблема. Раздел аналитики, который мы посчитали очень полезным, к сожалению, пользователи не сочли таковым. Он только сбивал людей с толку.

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

Второй экран — экран оплаты/переводов:

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

Третий экран — экран с продуктами банка:

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

Сейчас телефоны стали большие, могут выпасть, и мы решили, что это для нас проблема, мы будем с этим работать. Кстати, угадайте, почему автор статьи ходит с разбитым телефоном?

На следующих картинках представлен существенно изменившийся дизайн второй итерации.

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

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

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

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

Ещё некоторые наблюдения и выводы, которые мы сделали в ходе тестирования.

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

Ещё есть люди с плохим зрением. Все об этом знают, и все об этом забывают (имею в виду дизайнеров). Как можно помочь людям с плохим зрением? Во-первых, можно увеличивать объекты в дизайне. Во-вторых, можно увеличивать контрастность в дизайне. И есть ещё один менее очевидный момент: можно отделять информацию, увеличивать расстояние между блоками, что тоже поможет людям лучше читать интерфейсы.

По самым скромным оценкам, которые можно найти в Википедии, левшей у нас 10%, а людей с плохим зрением — 13%. По нескромным — левшей где-то 15%, а людей с плохим зрением — 30%.

А ещё у некоторых девушек есть длинные ногти. Такие девушки тоже по-другому пользуются телефоном. Им тяжело нажимать что-то в правом нижнем углу, потому что вместо нажатия подушечкой пальца они упираются ногтем, в связи с чем им тоже приходится как-то перехватываться. Здесь официальная статистика отсутствует, но могу предположить, что время от времени до 50% взрослого населения планеты могут оказаться в такой ситуации.

Помимо освещённых выше Usability-тестов, есть много разных способов тестировать UX. Среди них:

• Eyetracking
• A/B-тесты
• Онлайн-опросы
• Глубинные интервью

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

Для тех, кто хочет в этом закопаться, советую книгу Даниеля Канимана «Thinking, Fast and Slow» (Думай медленно, решай быстро). Она ничего не расскажет вам про тесты, но даст хорошую почву для размышлений, показав, как на один и тот же вопрос одни и те же люди могут отвечать по-разному.

Помогла ли тебе эта статья приблизиться к тому, чтобы начать тестировать интерфейсы самому? Что оказалось полезным (если что-то всё-таки оказалось), а что неуместным?

Спасибо всем, кто помогал провести исследование и подготовить доклад

Проведение UX-исследования:
Команда JTC — бизнес-анализ, дизайн, UX-исследование
Денис Красильников — дизайн
Антон Казаков — UX-исследование
Екатерина Кашковская — UX-исследование
Дмитрий Добродеев — UX-исследование
Ирина Пономарёва — съёмки и монтаж

Подготовка доклада:

Команда JTC — формирование доклада

Максим Блохин — дизайн

Ирина Пономарёва — съёмки и монтаж

Надежда Молодцова — съёмки

Татьяна Китаева — редактура

Юзабилити-тестирование по шагам или оценка дизайна HCD / Хабр

Согласно стандарту HCD (Сайт: ISO 9241-210: Human-centered design) есть этап оценки дизайна, именно в нем может проводится качественное юзабилити-тестирование.

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

Когда стоит проводить юзабилити-тестирование и что ему предшествует?

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

Следующим шагом должно быть определение KPI (Wikipedia: Key Performance Indicators — ключевые показатели эффективности). Необходимо проанализировать, что важно для бизнеса, определить цели, которые должны быть достигнуты сайтам.

Пример: для кого-то это могут быть заказы товара, для кого-то обращения через форму обратной связи с какими-либо вопросами и т.д.

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

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

Подготовка к юзабилити-тестированию

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

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

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

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

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

Далее идет подбор респондентов исходя из выбранного персонажа. Чем больше респондент соответствует портрету персонажа, тем лучше. Достаточное количество респондентов – 5-8 человек. В выборе количества я основываюсь на рекомендации Якоба Нильсена и собственный опыт.

Проведение юзабилити-тестирования

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

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

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

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

Обработка данных юзабилити-тестирования

Далее необходимо просмотреть собранные видео материалы, проанализировать результаты юзабилит-тестирования и определить требования к интерфейсу для перепроектирования (книга: Web-дизайн. Удобство использования Web-сайтов). Изменения, которые будут внесены, исходя из определенных требований, стоит проверить при следующем юзабилити-тестировании. Количество таких итераций во многом должно зависеть от целей и бюджета, выделенного на перепроектирование сайта.

Примеры: добавить подсказки в форму регистрации, выделить кнопку покупки, добавить поле “платформа” в форму подбора телефона по параметрам и т.д.

Если проектирование проводилось по стандарту ISO 9241-210, то проведение юзабилити-тестирования не должно быть затратным и трудоемким процессом в связи с подготовленной аналитической базой. Основные этапы юзабилити-тестирования при проектирования сайта с нуля остаются такими же, как описаны выше, за исключением некоторых аспектов:

1. Формирование гипотез
2. Определение метрик для тестирования
3. Определение персонажей и сценариев
4. Подбор респондентов
5. Заполнение анкеты
6. Вводный инструктаж
7. Проведение юзабилити-тестирования
8. Опрос респондентов
9. Анализ результатов
10. Определение требований для проектирования сайта

Основной проблемой, с которой я столкнулся при юзабилити-тестировании в данном случае, это тестирование статического дизайна, а не полноценного сайта. В действительности лучше протестировать сверстанный и даже запрограммированный сайт, однако цена итерации в дизайн будет уже высока. Чем раньше найдена проблема в интерфейсе, тем меньше затрат на ее устранение. Как провести полноценное юзабилити-тестирование статической картинки? Решением данной проблемы явилась программа Axure. Самым дешевым и удачным способом было искусственно расставить ссылки на статической картинке дизайна сайта и сгенерировать его в HTML страницы. Данный способ дает возможность протестировать сайт, не затрачивая ресурсов даже на верстку. Конечно, в сгенерированных страницах почти нет функционала, он отображается только в определенном виде, однако для определения большего количества проблем этого достаточно.

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

P.S. Жду конструктивной критики по поводу предложенного решения качественного юзабилити-тестирования дизайна, так как подобного решения я нигде не видел. Если есть предложения, как дешево и сердито провести полноценное качественное юзабилити-тестирование, то буду рад ознакомиться.

Что такое юзабилити-тестирование? UX (User Experience) Пример тестирования

• Home

• Testing

  • • Back
    • Agile Testing
    • BugZilla
    • Cucumber
    • Тестирование базы данных
    • 9000 J27 Тестирование базы данных
    • 9000 J27
    • JUnit
    • LoadRunner
    • Ручное тестирование
    • Мобильное тестирование
    • Mantis
    • Почтальон
    • QTP
    • Назад
    • Центр контроля качества (ALM)
    • 000
    • RPA Управление тестированием
    • TestLink

• SAP

  • • Назад
    • ABAP

    900 03 APO

    • Начинающий
    • Basis
    • BODS
    • BI
    • BPC
    • CO
    • Назад
    • CRM
    • Crystal Reports
    • MMO

    HAN

    • Назад
    • PI / PO
    • PP
    • SD
    • SAPUI5
    • Безопасность
    • Менеджер решений
    • Successfactors
    • SAP Tutorials
• Web
• AngularJS
• ASP.Net
• C
• C #
• C ++
• CodeIgniter
• СУБД
• JavaScript

• Назад
• Java
• JSP
• Kotlin
• Linux
• Linux
• Kotlin
• Linux

js

• Perl

• Назад
• PHP
• PL / SQL
• PostgreSQL
• Python
• ReactJS
• Ruby & Rails
• Scala
• SQL

000

• SQL

000

0003 SQL

000

0003 SQL

000

• UML
• VB.Net
• VBScript
• Веб-службы
• WPF