«Волшебник страны Оз» или как провести юзабилити-тестирование голосового интерфейса

Голосовые интерфейсы начинают активно проникать в нашу жизнь. Многие из нас сейчас взаимодействуют с голосовыми помощниками для того, чтобы узнать погоду, новости или завести будильник. Но за ростом рынка идет рост и ожиданий пользователей от взаимодействия, поэтому так важно проводить юзабилити-тестирования голосовых интерфейсов, чтобы формировать положительный пользовательский опыт. Однако не всем известно, как можно провести пользовательское исследование продуктов, управляемых с помощью голоса, без разработки. О том, как организовать юзабилити-исследование для подобных продуктов, расскажет UX-аналитик «Риалвеб» Сергей Алексеев.

Cегодня мы наблюдаем стремительный рост голосовых технологий. Так, согласно исследованию Juniper Research, пользоваться голосовыми интерфейсами будут миллиарды людей с помощью:

1. смартфонов и носимых устройств;

2. умных колонок;

3. Smart TV.

По данным аналитической компании OC&C, к 2022 году в США с помощью голосовых помощников будет совершаться до 6% всех покупок в онлайне, что составит примерно 40 млрд долларов. В связи с этим, продукты, использующие в качестве способа взаимодействия голосовые технологии, требуют к себе такого же активного внимания со стороны исследователей, как и продукты с графическим интерфейсом.

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

А как же можно тестировать пользовательские сценарии в продуктах с голосовыми функциями? Если для графических интерфейсов применяется как правило юзабилити-тестирование, где для проведения можно использовать уже готовый продукт или прототипы, реализованные с помощью Axure/Figma/Invision или других сред прототипирования, то не совсем понятно, как можно исследовать голосовые интерфейсы, не реализуя их в коде. Безусловно, анализировать голосовые сценарии возможно с помощью экспертной оценки, используя, например, эвристики Нильсена, адаптированные под голосовые интерфейсы, однако никакая экспертиза не даст понимания и видения реального пользовательского опыта.

Выход есть, и заключается он в применении такого подхода как Wizard of Oz. Своей историей Wizard of Oz уходит еще в 80-е годы XX века, но особую актуальность начинает приобретать именно сейчас на фоне бурного развития, в том числе голосовых интерфейсов. Wizard of Oz позволяет очень быстро и просто прототипировать голосовые сценарии, используя для этого человека, который и становится тем самым “волшебником”, заменяя ваш продукт.

“Волшебник” может как напрямую выступать в роли голосового помощника, озвучивая тот или иной сценарий, так и просто запускать готовые аудиофайлы в зависимости от запроса пользователя, записанные, например, с помощью Яндекс SpeechKit. Кроме того, возможно использование и “перевернутого” варианта Wizard of Oz, когда роль “волшебника” выполняется самим респондентом, такой подход позволяет определить наиболее релевантные ответы вашей системы для пользователей.

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

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

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

● используйте контекст, в котором у ваших пользователей возникла потребность в использовании сценария продукта;

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

Пример плохого задания для активации сценария по запуску фильма:

Пример хорошего задания для активации сценария по запуску фильма:

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

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

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

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

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

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

1. задания для респондентов;

2. шаблоны ответов вашей системы;

3. техническую базу для проведения исследования.

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