В этой статье расскажу о своём опыте проведения модерируемых юзабилити-тестирований и о том, что стоит делать после их проведения. Статья будет полезна тем, кто не проводил тестирования или имеет мало опыта. Мой опыт юзабилити-тестирования(ЮТ) состоит из проектов разной сложности: от небольших стартапов, до энтерпрайз b2b приложений.

Вы так же можете посмотреть моё выступление на DUMP с этой темой.

---

Повторим основы

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

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

Юзабилити-тестирования делятся на разные виды:

• модерируемое и немодерируемое

• очное и заочное

• эксплораторные, проверочные и сравнительные

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

Все активности, о которых я буду сегодня говорить, подойдут под любой вид ЮТ, но могут быть немного доработаны.

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

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

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

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

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

Вам понадобится пройти четыре этапа:

• Подобрать аудитория

• Оформить решение

• Сформулировать гипотезы

• Написать сценарий и легенду

Последние два пункта чаще всего идут вместе.

Правильно подобранная аудитория респондентов

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

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

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

Решение, которое будете тестировать

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

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

В самом файле советую создавать страницы с осмысленными названиями и датами проведения тестирования.

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

Гипотезы для проверки

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

«Вариант А лучше» или «пользователь использует такую-то фичу» - не самые лучшие формулировки. Они могут подойти для A/B тестирования или для подтверждения одного точечного решения. Для тестирования лучше описать гипотезу шире и получить на неё развёрнутый ответ.

Мой пример из реального проекта:

«Для создания показателя Администратору достаточно названия, сокращения и принадлежности».

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

Во время проведения ЮТ советую дополнять проверку гипотезы вопросами:

• «Всё ли мы учли?»,

• «Что важно? Почему?»,

• «Как вы решаете эту задачу, если не так?»,

• «Что бы могло помочь вам в решении этой задачи?».

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

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

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

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

Сценарий и легенда

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

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

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

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

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

Ну что же. Вы полностью готовы к тестированию. Наступает самый интересный и сложный момент — его проведение.

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

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

Если интерфейс вашего продукта достаточно прост и сам продукт рассчитан на широкую аудиторию вы можете взять меньшую выборку - 5 человек. Согласно статье Нильсена, они находят примерно 75% всех проблем, вероятность обнаружения которых в среднем равняется 31%.

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

В некоторых компаниях проводят тестирования до 3 подтверждений или опровержений, если это маленькая фича (то есть не более 5 человек), если сценарий большой есть мобильная и десктоп версия, есть сравнения версий, то может быть и 16 и более респондентов. но учтите, что на обработку каждого тестирования у вас будет уходить около 1.5-2 часов.

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

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

Поделюсь лишь своим опытом и небольшими советами:

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

• Всегда спрашивайте о записи экрана — это очень сильно поможет вам при расшифровке и вы не будете отвлекаться на запись «инсайтов».

• Разрядите обстановку небольшой вовлекающей беседой — респонденту будет проще с вами общаться и это даст лучшие результаты.

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

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

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

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

Подводим итоги тестирования

Исходя из моей практики я советую подводить итоги в три этапа:

• Составляем отчёт по каждому респонденту

• Составляем общий отчёт на основе индивидуальных

• Готовим презентацию для команды

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

Что стоит добавить в отчёт по респонденту

Я в своей практике стараюсь не раздувать количество страниц и разделяю отчёт на:

1. Дату проведения + Фамилию и Имя респондента (иногда должность)

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

2. Ссылку на запись

Чтобы можно было всегда её пересмотреть и поделиться с коллегами

3. Гипотезы

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

4. «Хорошие» решения в интерфейсе

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

О том, что что-то хорошо респонденты говорят редко. Как тогда найти хорошее решение? Смотрите на поведение респондента и задавайте вопросы.Если респондент легко находит кнопки и пункты меню, значит навигация хорошая, а если на вопрос «Чего вам не хватает в карточке объекта?» отвечает что всё ок, значит карточка объекта достаточно информативна (но это не точно).

5. Что нужно исправить

Это то, где у респондента больше всего «болело». Иногда люди не говорят об этом напрямую, поэтому проанализируйте речь и поведение респондента. Под поведением я говорю о курсоре, так как мало кто снимает респондентов или включает в своё тестирование Eye-tracking.

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

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

В исправлениях я чаще всего описываю два вида изменений:

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

• Общие — требуют дальнейшего изучения и затронут больше частей продукта«Структура отчёта не ясна и имеет мало информативности»«Фильтрация карточек неудобна и вызывает сложности.»«Не ясно как применить несколько фильтров»«Когда создаётся новая запись о клиенте сначала всегда заполняется его телефон, а не ФИО»

6. Инсайты

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

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

Что стоит добавить в общий отчёт по тестированию

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

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

1. Дисклеймер

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

2. Вступление дизайн-исследования

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

3. Краткое резюме

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

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

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

Процесс принятия заявки и смены её статуса не до конца ясен

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

4. Результаты

Гипотезы

Показываем статистику по подтверждённым и неподтверждённым гипотезам и даём пояснения по необходимости.

Полезные решения

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

Общие исправления

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

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

Бывают случаи, когда точно не ясно насколько хорошее или плохое решение, особенно, если у вас чётное количество респондентов. В таких случаях вы можете усложнить оценку прохождения и оценивать не в рамках «Прошёл/Не прошёл», а «Прошёл/Были сложности/Не прошёл». Если процент прохождения задачи >70%, то всё хорошо. Таким образом вам будет проще понять есть ли в вашем решении проблемы.

Важные инсайты

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

5. Проблемы и сложности

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

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

6. Рекомендации

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

UX

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

UI

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

Бизнесовые

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

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

7. Финал

Завершить отчёт можно аппендиксом со ссылками и дополнениями или каким-то выводом, если он необходим.

Ещё вы можете сделать презентацию и кратко рассказать всей команде о проведённом вами тестировании. Это увеличит эмпатию всех членов команды по отношению к конечному пользователю и придаст мотивации.

Планируем работы

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

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

Существует много разных способов приоритизации и планирования работ. Я бы советовал не усложнять и пойти по модели MoSCoW и понять какие рекомендации вам стоит взять в работу (здесь я говорю рекомендациях из общего отчёта). Обязательно оцените временные затраты дизайнеров и разработчиков на реализацию каждой рекомендации.

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

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

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

Итог

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

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

Подписывайтесь на мой канал в телеграм, там много интересного ;)