Юзабилити-тестирование: как проводить и не подсказывать пользователю

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

Артём, UX-исследователь в Aski. Юзабилити тестирование я гоняю уже лет шесть, и до сих пор почти каждый тест ломает какую-нибудь мою уверенность в том, что «тут всё понятно». Ниже разберём, как провести юзабилити тест по-человечески: чем он отличается от интервью, как собрать сценарии задач, что мерить и сколько людей реально звать. Без академизма, с граблями, на которые наступал сам.

Что такое юзабилити-тестирование простыми словами

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

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

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

Чем юзабилити-тест отличается от интервью

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

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

Грубо говоря, разница такая.

• Что изучаем — Интервью: мысли, мотивы, прошлый опыт — Юзабилити-тест: действия в интерфейсе здесь и сейчас
• Главный вопрос — Интервью: «почему вы так делаете» — Юзабилити-тест: «получится ли у вас сделать вот это»
• Роль исследователя — Интервью: задаёт вопросы, копает вглубь — Юзабилити-тест: даёт задачу и молчит
• Что на выходе — Интервью: боли, потребности, инсайты — Юзабилити-тест: где люди спотыкаются в интерфейсе
• Когда применять — Интервью: до дизайна, чтобы понять проблему — Юзабилити-тест: на макете или готовом продукте

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

Модерируемое и немодерируемое тестирование

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

Модерируемое это когда ты сидишь рядом (вживую или по видеосвязи) и ведёшь сессию. Можешь попросить «расскажите, о чём думаете сейчас», заметить замешательство, аккуратно копнуть, почему человек завис. Дороже по времени, зато глубже. Видишь не только что человек ошибся, но и почему.

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

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

Как составить сценарии задач

Сценарий это конкретное задание, которое вы даёте человеку. И вот тут чаще всего всё ломается ещё до старта теста.

Главная ловушка: не подсказывать в формулировке. Если вы говорите «нажмите на кнопку Профиль в правом верхнем углу и измените телефон», вы не тестируете интерфейс, вы тестируете, умеет ли человек выполнять инструкции. А надо проверить, найдёт ли он сам.

Поэтому задача описывается через цель, а не через шаги. Сравните:

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

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

Несколько вещей, которые я держу в голове, когда пишу сценарии:

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

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

Правило «не подсказывать»: самое трудное на тесте

Если из всей статьи запомнить одно, пусть будет это. Молчать тяжело. По-настоящему тяжело.

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

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

И просите думать вслух. В начале сессии прямо говорите: «комментируйте, пожалуйста, всё, что делаете и о чём думаете, даже если кажется ерундой». Поначалу люди стесняются, потом расходятся. Этот поток бормотания и есть золото: «так, где у них тут… наверное в меню… нет, тут только это… странно».

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

Какие метрики считать

Юзабилити тест это не только «посмотрели и поохали». Есть цифры, по которым видно, насколько всё плохо или хорошо. Их немного, и они простые.

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

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

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

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

Сколько респондентов нужно: правило пяти

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

Это не я придумал. Якоб Нильсен, один из самых известных людей в области юзабилити, ещё в 1990-х показал на собственных данных, что пять пользователей вылавливают около 85% проблем интерфейса. Логика простая: первый же человек спотыкается о самые грубые косяки, второй и третий повторяют многие из них плюс ловят что-то своё, а к пятому новые проблемы почти перестают появляться. Те же грабли идут по кругу.

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

Пара оговорок, без них нечестно. Пять это на один тип пользователей. Если у вас новички и опытные ведут себя по-разному, берите по пять на каждую группу. И правило про «85% за пять» это усреднение Нильсена, на конкретном продукте цифра гуляет. Иногда пятерых мало, иногда и трёх хватает, чтобы увидеть, что экран надо переделывать целиком.

Как разбирать результаты

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

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

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

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

И вот тут, кстати, всплывает кое-что важное. Юзабилити тест отлично показывает, ГДЕ человек спотыкается. Но не всегда объясняет, ПОЧЕМУ. Вы видите, что на экране оплаты половина людей замирает, а что у них в этот момент в голове, тест не скажет. Поэтому я почти всегда довешиваю к тесту короткое интервью.

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

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

Коротко

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

FAQ

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

Сколько пользователей нужно для юзабилити-теста? Обычно достаточно пяти на один сегмент пользователей. По данным Якоба Нильсена, пятеро вылавливают около 85% проблем интерфейса, дальше новые почти не появляются. Если у вас разные группы (например новички и опытные), берите по пять на каждую. Выгоднее не звать десятерых сразу, а сделать два цикла по пять: протестировали, починили, протестировали снова.

Что считается метриками в usability testing? Базовые четыре: успех задачи (дошёл до цели или нет), время на задачу, число ошибок и количество запросов о помощи. Главная из них успех задачи. На маленькой выборке точные проценты обманчивы, поэтому цифры используют как ориентир и способ заметить тренд между итерациями, а не как строгую статистику.

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

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

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

Источники

• Jakob Nielsen. «Why You Only Need to Test with 5 Users» (Nielsen Norman Group), 2000. Обоснование правила пяти респондентов и оценки 85% найденных проблем.
• Jakob Nielsen, Thomas Landauer. «A mathematical model of the finding of usability problems», 1993. Та самая математическая модель, из которой выросло правило пяти.
• Steve Krug. «Don't Make Me Think». Классика про юзабилити и про то, как давать задачи и не подсказывать на тесте.