Все методы
    ПрототипПродуктПроблемы

    Тестирование голосовых интерфейсов

    Voice User Interface Testing

    Тестирование голосовых интерфейсов (Voice User Interface Testing) проверяет умные колонки, голосовых ассистентов, навыки и телефонные меню с настоящими людьми. Участник получает задачу вслух и выполняет её голосом. Исследователь смотрит, какими словами люди обращаются к системе, где теряются и что происходит, когда система не поняла.

    Сроки
    7–21 день
    Респонденты
    5–15 человек
    Команда
    2–3 человека
    Бюджет
    Средний
    Сложность
    Сложный
    Популярность
    Редко
    Содержание

    Когда использовать

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

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

    Что нужно для старта

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

    Как провести

    1. Задания

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

    2. Прототип

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

    3. Участники

      Берите людей, которые не знают навык. Ведущий, играющий систему, должен его знать. Среди участников нужны и те, кто говорит не на родном языке, потому что их понимают хуже.

    4. Сессия

      Дайте задачу и не подсказывайте формулировки. Записывайте разговор. После задачи попросите описать опыт своими словами. Оценивайте удобство, а не мнение о продукте.

    5. Что слушать

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

    6. Ошибки диалога

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

    7. Готовая система

      Проверяйте в симуляторе платформы и на устройстве, а ещё пусть попробуют те, кто не участвовал в разработке. Смотрите по областям. Распознавание голоса, понимание фразы, голосовой ответ, правильное толкование запроса и связь с другими сервисами.

    8. Разбор

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

    Результат

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

    Пример сводки по тесту голосовой колонки. Данные выдуманы, формат — задача, доля выполнивших, типичная фраза и что чинить по описаниям тестирования у Google и NN/g

    Типичные ошибки

    • Слова из задания в речи участника

      Если в задании названа функция, респондент повторит название. Описывайте ситуацию.

    • Проверять только успешный сценарий

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

    • Одно и то же повторное приглашение

      Одинаковый переспрос звучит механически. Меняйте формулировку и добавляйте подсказку.

    • Длинные ответы

      Человек не может их повторить или перебить, и нагрузка на память растёт. Делайте ответы короткими.

    • Списки вариантов голосом

      Сравнивать последовательные варианты трудно, люди берут первый подходящий. Вынесите сравнение на экран, если он есть.

    • Пауза считается концом запроса

      Участники делают паузы, и система обрывает их. Проверьте такие реплики отдельно.

    • Только носители языка

      Говорящих не на родном языке понимают хуже. Включите таких участников.

    • Мнения вместо удобства

      Спрашивайте о том, что было непонятно, а не нравится ли продукт.

    Российская специфика

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

    Кто использует

    Исследователи NN/g пригласили 17 постоянных пользователей Alexa, Google Assistant и Siri. Каждый выполнял задания от простых запросов о погоде до составных вопросов и отвечал на вопросы интервью. Вывод: простые вопросы с коротким ответом работают, остальное вызывает затруднения. Авторы сравнили ситуацию с ранними мобильными интерфейсами 2000-х. Разбор исследования.

    Место в процессе

    Сначала