- PVSM.RU - https://www.pvsm.ru -
Привет, с вами снова Наталия Спрогис, руководитель направления UX-исследований в Mail.Ru Group! Это вторая часть статьи о планировании юзабилити-тестирования. В первой [1] я рассказывала о формулировке целей и гипотез, выборе метода тестирования и инструментов фиксации данных, а также об организационных моментах для исследователя. Эта часть посвящена составлению протокола (сценария) тестирования: продумыванию того, какие задания вы дадите респонденту, какие вопросы будете задавать, какие опросники предложите заполнить.
Протокол любого юзабилити-тестирования состоит из следующих частей:
Независимо от предмета тестирования, любое исследование начинается одинаково. Нужно:
Оно решает следующие задачи:
Для большинства тестов подойдёт такая структура вводного интервью. Однако если вы тестируете новый продукт, возможно, стоит пропустить вводные вопросы. Если вы слишком подробно начнёте обсуждать какую-то тему, это может создать у пользователя определённые ожидания от продукта. Поэтому оставьте только пару самых общих вопросов, чтобы наладить контакт с респондентом, и сразу же переходите к заданиям. Обсуждать сценарии, отношения и контекст в этом случае лучше после того, как пользователь первично изучит продукт.
Давайте представим, что вы хотите протестировать интернет-магазин. У вас есть важные сценарии (поиск и выбор товара, процесс оформления заказа), известные проблемы (частые ошибки в форме оплаты) и даже гипотеза, что дизайнер что-то намудрил с фильтром по цене. Как же сформулировать задания?
Сфокусированные задания. Очевидным кажется сделать примерно такое задание:
«Выберите посудомоечную машину шириной 45 сантиметров с функцией „луч на полу“ стоимостью не более 30 тысяч рублей».
Это мотивирует респондента пользоваться фильтрами и сравнивать товары между собой. Вы сможете проверить фильтр по цене на всех респондентах и посмотреть на ключевой сценарий подбора товара. Подобные задания вполне имеют право на жизнь и хороши для проверки конкретных гипотез (как с фильтром по цене). Однако если весь тест будет состоять из них, то вы рискуете следующим:
Задания с контекстом. Один из способов лучше вовлечь пользователей — добавить в сухое задание реальную историю и контекст. Например, вместо «Найдите рецепт пирога со сливами» на сайте с рецептами предложите следующее:
«Через час к вам придут гости. Найдите, что можно испечь за это время. У вас в холодильнике есть всё для бисквита, а также немножко слив. Но, к сожалению, нет сливочного масла».
Подобный подход можно использовать и с интернет-магазином. Например: «Представьте, что вы выбираете подарок сестре. У неё недавно сломался фен, и она была бы рада получить новый. Вам нужно уложиться в 7 тысяч рублей». Важно, чтобы респондент действительно выбрал реального человека, которому будет «покупаться» подарок (если нет сестры, предложите другого родственника или подругу). Ключевое для подобных заданий — реальность и понятность контекста. Легко представить, что ты выбираешь подарок родным, куда труднее — что ты «бухгалтер, составляющий годовой отчёт».
Яркий пример такого подхода — «метод Болливуда [2]», который придумала индийский UX-эксперт Апала Лахири Чаван (Apala Lahiri Chavan). Она утверждает, что индусам, как и многим азиатам, сложно открыто высказывать своё мнение об интерфейсе. Зато, представляя себя героями вымышленных драматических ситуаций (как в любимых ими фильмах), они раскрываются и начинают живо участвовать в тестировании. Поэтому задания для индусов должны выглядеть примерно так:
«Представьте, что ваша любимая юная племянница собирается замуж. И тут вы узнаёте, что будущий муж — мошенник, да ещё и женатый! Вам нужно срочно купить два билета на рейс до Бангалора для себя и жены обманщика, чтобы расстроить свадьбу и спасти семью от позора. Торопитесь!»
Задания с опорой на опыт респондентов. Напомним: для успешного тестирования респонденты должны соответствовать аудитории проекта. Поэтому для проверки интернет-магазина бытовой техники мы рекрутируем тех, кто недавно выбирал технику или выбирает её сейчас. Именно этим мы будем пользоваться, составляя задания с опорой на опыт респондентов. Есть два варианта использования такого подхода:
Подобные задания дают много реальных примеров выполнения базовых операций в продукте. Это часто порождает гораздо больший спектр проблем и находок. Кроме того, позволяет проверить продукт на новых сценариях, которые вы не считали основными или даже не продумывали. Например, когда мы тестировали проект Недвижимость Mail.Ru, именно задания с опорой на опыт респондентов помогли нам сделать много открытий. Так, мы увидели, что люди при поиске квартиры в Подмосковье указывают в геофильтре конечные станции метро, имея в виду, что это станции, до которых можно доехать из области. Мы же рассчитывали, что фильтр по метро ищет квартиру недалеко от станции. Также мы узнали, чем отличаются сценарии поиска новостроек от вторички, что помогло позже вынести поиск новостроек в другой раздел на сайте — со своими фильтрами и своей концепцией описания квартир.
Советую также прочитать отличную статью Джареда Спула [3] о пользе подобных заданий.
Задания без заданий. Иногда лучше вообще не предлагать пользователям задания на работу с проектом, а посмотреть, с чего они сами начнут знакомство с продуктом. Дайте респонденту вводную: «Представьте, что вы решили попробовать этот продукт. Я оставлю вас на несколько минут. Делайте то, что вы стали бы делать в реальной жизни. Я не даю вам никаких заданий».
Важно, чтобы модератор при этом выходил из комнаты. В противном случае у пользователя появляется соблазн сразу же что-то спросить, уточнить: «А надо ли регистрироваться? А как вот это сделать?» и т. д.
Данный тип заданий полезен для полностью новых продуктов. Мы часто применяем его для мобильных приложений и игр. Так, мы видим, читают ли пользователи обучающие материалы, какие детали сразу привлекают внимание, что люди понимают в концепции продукта, как потом описывают его возможности. Уже после свободного задания идут запланированные конкретные сценарии.
Ещё одна область применения свободных заданий — контентные проекты. Если вы хотите понять, как читают ваши статьи, где надолго задерживаются, что пропускают, на какие элементы на странице обращают внимание и пр., то просто оставьте респондента на несколько минут наедине с проектом. Только без модератора, смотрящего через плечо, пользователь расслабится и будет читать текст так же, как обычно, в реальной жизни. Так мы тестируем проекты Новости Mail.Ru, Леди Mail.Ru и др. Этот подход позволил выделить разные модели поведения на сайте, разные паттерны чтения статей и понять, какие типы материалов стоит оформлять по-другому.
Первое задание — простое. Начинайте тестирование с ознакомительных и несложных заданий. Респондент должен освоиться с форматом тестирования, особенно если вы используете метод «мысли вслух»: на первом задании человеку нужно привыкнуть к необходимости озвучивать свои мысли и чувства. Не стоит сразу вываливать на него всю боль и страдания интерфейса.
Не подсказывайте. Сформулируйте задания так, чтобы не подсказывать правильных действий респонденту. Например, если вы хотите протестировать возможность добавления в избранное товаров в интернет-магазине, обойдитесь без задания «Давайте добавим вот этот телевизор в избранное», особенно если кнопка так и называется. Респондент, прочитав задание, будет просто находить кнопку с нужной подписью на экране, возможно даже не понимая, что именно он делает. Лучше объяснить смысл задания, не прибегая к терминам в интерфейсе. Например: «На сайте есть возможность сохранить понравившиеся товары и потом выбрать, что из них заказать. Давайте попробуем сделать это с таким-то телевизором».
Следите за терминологией. Не используйте непонятные слова и обозначения. Это кажется очевидным, но мы часто, привыкнув к каким-то терминам, забываем, что их мало кто знает за пределами IT-тусовки. Например, при тестировании нового функционала тредов (цепочек писем) в Почте Mail.Ru нам пришлось достаточно сложно. Ведь у пользователей, незнакомых с подобным функционалом, просто нет в голове термина, который бы обозначал треды. В итоге мы никак их не называли. Мы просто показывали респондентам ящик с подключёнными цепочками и обсуждали эту новую возможность. В рамках обсуждения давали пользователям самим подобрать слово для обозначения тредов. Это помогло нам позже использовать наиболее понятные тексты в обучающих промоматериалах. Следите не только за заданиями, но и за вопросами модератора, особенно за теми, которые приходят от команды во время тестирования. Не стоит, например, использовать слово «тулбар» при обсуждении функций: оно не всем знакомо. Ещё несколько лет назад даже слово «браузер» знали далеко не все пользователи. То, как именно лучше сформулировать задания, зависит от аудитории тестирования. Не стоит кидаться и в обратную крайность, объясняя все термины подряд. Например, опытным игрокам не надо растолковывать, что такое «баф», «фраг», «респаун» и пр.
Меньше тестового. Часто очень велик соблазн сделать респонденту тестовый аккаунт в системе и проводить тестирование на нём. Ведь можно заранее всё обкатать в этом аккаунте, избежать накладок и не тратить время на регистрацию или авторизацию респондента. Часто ещё и технически гораздо легче включить новый дизайн на тестовых, а не на реальных данных. Однако при таком подходе вы рискуете получить гораздо меньше полезных результатов. Ведь у тестовых действий нет реальных последствий. Ситуация становится совсем искусственной, пользователям сложно проецировать её на реальный опыт. Например, при работе в собственном аккаунте в соцсети респонденты, как и в реальной жизни, будут аккуратно делать всё, что могут увидеть их друзья (публиковать ссылки, отправлять сообщения). При настройках собственного ящика в почте — стараться не удалить важные письма. При тестировании интернет-магазинов иногда применяют подход, когда вознаграждение нужно потратить прямо на тесте. В таком случае респондент не ткнёт в первый подходящий по заданию товар, а подберёт то, что ему на самом деле нужно.
Плюс, имея одни лишь тестовые данные, вы найдёте проблемы, связанные только с ними, а не проверите функционал на разных вариациях. Например, когда мы тестировали социальную панель браузера Амиго, один из респондентов, подключивший в панель свой аккаунт «ВКонтакте», сразу отметил, что так читать ему неудобно. Почти вся лента состояла из подписок на группы с эротическими фотографиями. А в узкой панели на картинках было просто ничего не разглядеть.
Ещё одна проблема тестовых данных — сложно разобраться в системе, так как всё вокруг непривычное. Например, пользователь соцсети привык узнавать свою страницу по собственной фотографии. Даже тестируя прототипы, мы стараемся максимально персонализировать их. Например, при тестировании кликабельных прототипов в «Одноклассниках» мы всегда адаптируем их для каждого пользователя, вставляя на страницу его имя и фотографию, а иногда и последние новости.
Не ограничивайтесь только интерфейсом. Не забывайте о том, что взаимодействие с продуктом часто не ограничивается одним лишь интерфейсом. Если есть возможность, тестируйте сопутствующие продукты или сервисы и связи между ними. Например, при тестировании игр мы стараемся проверить не только игру, но и её сайт и связанные с ним загрузку, регистрацию в игре, поиск информации на форуме. А при тестировании одного интернет-магазина я также проверяла звонок оператора после оформления заказа, что дало рекомендации для колл-центра.
Думайте о тайминге. Для хорошего сценария важно расставлять приоритеты задач. Скорее всего, если система большая и целей у теста много, вам захочется сделать очень много заданий. Однако уставший респондент уже не будет полезен. Хороший тест длится не больше полутора часов, два — это максимум. Исключение разве что игры. И помните, что ваши цели — не только задания, но и интервью, опросники, настройка оборудования и подписание документов. Всё это обычно занимает не менее получаса. Если заданий слишком много, а отказаться от каких-то очень не хочется, можете наименее приоритетные пустить в ротацию, т. е. показывать только части респондентов. Или сделать часть теста обязательной для всех, а остальное смотреть только с теми, с кем хватит времени. Но это, скорее всего, будут наиболее успешные респонденты.
Оценивайте полезность задания. Подумайте, действительно ли оно соответствует вашим гипотезам. Например, вы хотите проверить функцию подписки на новости на сайте. Задание «Подпишитесь на новостную рассылку» позволит проверить только то, смогут ли найти рассылку те, кто будет её искать. Однако мы понимаем, что люди редко приходят на сайт, чтобы подписаться на новости. Задание не относится к реальной жизни. Вам же нужно понять, замечают ли возможность подписки те, кто выполняет совсем другие задачи. Проверять это можно разными способами — в зависимости от реализации функции. Если человек занимался заданиями, в которых ему на глаза могла попасть возможность подписки, спросите его, есть ли она на сайте. Только обязательно уточните, где он видел эту возможность или как она реализована, чтобы удостовериться, что респондент не просто с вами соглашается. Если предложение подписки встроено в процесс регистрации или оформления заказа, посмотрите, воспользуется ли им респондент, а после задания обсудите это. Очень мало шансов, что в лабораторных условиях люди реально подпишутся на рассылки, но можно проверить, обратил ли человек внимание на такую возможность, чего он ожидает от рассылки и т. п.
Цель заключительной фазы тестирования — собрать впечатления от работы с продуктом, понять, что понравилось пользователю, а что его расстроило, оценить субъективную удовлетворённость. Как правило, в этой части теста используется сочетание интервью с модератором и заполнения формальных опросников.
В итоговом интервью мы всегда задаём респондентам примерно одни и те же вопросы: «Какие впечатления остались?», «Что понравилось, а что нет?», «Было ли что-то, что показалось сложным или неудобным?», «Чего не хватало?», «Что хотелось бы изменить в продукте?» и т. п. Самое время уточнить непонятные моменты поведения респондента, если вы не сделали этого в процессе теста. А если вы узнавали у пользователей отношение к бренду или продукту и ожидания от него до теста — выясните, изменилось ли что-нибудь. При интервью обращайте внимание на следующее:
Часто по словам респондента в финальном интервью сложно понять, понравился ему в итоге продукт или нет. А уж тем более трудно сравнить отношение нескольких респондентов, которые и плюсы отмечали, и недостатки находили. Тут на помощь исследователю приходят опросники. Во-первых, при заполнении опросника (особенно до разговора с модератором) чуть меньше влияние пресловутой социальной желательности, хотя полностью вы от него не избавитесь. Во-вторых, опросник даёт вам чёткие параметры, позволяющие сравнивать сценарии, продукты или стадии проекта.
Составление хорошего опросника — это отдельная и очень большая тема. Тут важны и формулировки, и шкалы, и многое другое. Поэтому хорошим подспорьем могут стать готовые и проверенные опросники. Они уже отточены и многократно протестированы. Проблема только в том, что почти у всех этих анкет нет официальных переводов на русский. Естественно, вы можете перевести их самостоятельно, но с методологической точки зрения переводы нужно протестировать, чтобы проверить корректность формулировок. Тем не менее анкеты могут стать ориентиром при составлении собственных опросников.
Есть опросники, которые даются после каждого задания, чтобы оценить удовлетворённость от конкретных сценариев. Например:
А есть анкеты, которые применяются уже в заключительной фазе тестирования. Вот несколько примеров, которые мы используем при необходимости:
Вы можете воспользоваться предложенными анкетами или создать свои опросники, актуальные для вашего продукта.
Хорошее планирование позволит вам провести исследование, точно отвечающее целям заказчика и максимально полезное для проектной команды. Также грамотный план сокращает время подготовки отчёта. Однако, как бы хорошо вы ни подготовились, обязательно проведите пилотный тест на ком-нибудь из коллег или знакомых. Это позволит избежать казусов с неправильно настроенным оборудованием, покажет, укладываетесь ли вы в тайминг, понятны ли тексты заданий и нет ли опечаток в опросах.
Автор: Mail.Ru Group
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/interfejsy/175032
Ссылки в тексте:
[1] первой: https://habrahabr.ru/company/mailru/blog/307556/
[2] метод Болливуда: https://books.google.ru/books?id=Jc5VyXbkymwC&pg=PA129&lpg=PA129&dq=Apala+Lahiri+Chavan+bollywood&source=bl&ots=Q7DvQJ30ek&sig=bP9JfWR4K8P1zjehz4jW0HHi630&hl=ru&sa=X&ved=0ahUKEwj78LXmufHNAhVQahoKHQF4BooQ6AEIIzAB#v=onepage&q=Apala%20Lahiri%20Chavan%20bollywood&f=false
[3] статью Джареда Спула: https://articles.uie.com/interview_based_tasks
[4] After Scenario Questionnaire (ASQ): http://michaelyeap.blogspot.ru/2009/10/oct-9-after-scenario-questionnaire-asq.html
[5] Single Ease Question (SEQ): http://www.measuringu.com/blog/seq10.php
[6] System Usability Scale (SUS): https://www.usability.gov/how-to-and-tools/methods/system-usability-scale.html
[7] Post-Study System Usability Questionnaire (PSSUQ): http://www.conetrees.com/2010/12/ux-glossary/post-study-system-usability-questionnaire-pssuq
[8] Microsoft Desirability Toolkit: https://www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwibr_SA0f_NAhWCkiwKHSjSCO4QFggbMAA&url=http%3A%2F%2Fwww.microsoft.com%2Fusability%2FUEPostings%2FDesirabilityToolkit.doc&usg=AFQjCNEJJtNcsHJSoqOMtC1YZBB_8j8rKQ&sig2=fGu9g4FBmLrwGxEHtJVMxw&bvm=bv.127521224,d.bGg
[9] Game Experience Questionnaire: https://pure.tue.nl/ws/files/21666907/Game_Experience_Questionnaire_English.pdf
[10] Источник: https://habrahabr.ru/post/308054/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.