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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Гипотезы

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

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

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

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

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

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

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

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

6. Инсайты

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

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

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

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

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

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

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

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

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

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

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

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

Гипотезы

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

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

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

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

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

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

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

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

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

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

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

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

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

UX

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

UI

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

Бизнесовые

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

7. Финал

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

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

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

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

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

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

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

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

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

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

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