Все методы
    ИсследованиеПрототип

    Метод Волшебника Страны Оз

    Wizard of Oz Testing

    Метод Волшебника Страны Оз (Wizard of Oz Testing) проверяет идею продукта до разработки. Участник работает с системой, которая выглядит рабочей, а ответы вручную даёт скрытый человек, «волшебник». Так видно, как люди будут вести себя с функцией, которой ещё нет.

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

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

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

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

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

    • Вопрос, на который нужен ответ, и список задач для участников
    • Сценарии заданий с контекстом, без слов, которые подсказывают, как называется функция
    • Заготовленные ответы «системы», включая ответ на запрос, который она не распознала или не может выполнить
    • Прототип или материалы, из которых собирается видимость системы. Бумага, картон, кликабельные макеты, консоль для оператора
    • Способ скрыть волшебника. Видеосвязь или другая комната, при этом он должен видеть и слышать участника
    • Роли. Модератор, волшебник, при необходимости наблюдатель, который записывает
    • Пять и более участников и 30–90 минут на сессию

    Как провести

    1. Вопросы и сценарий

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

    2. Ответы и материалы

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

    3. Роли и обучение волшебника

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

    4. Площадка

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

    5. Репетиция

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

    6. Сессии

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

    7. Разбор между сессиями

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

    8. Раскрытие и итоги

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

    Результат

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

    Пример журнала сессии голосового заказа еды. Данные выдуманы, формат — реплика участника, ответ волшебника и вывод по описаниям процесса у Smashing Magazine, This Is Service Design Doing и в разборе голосовых интерфейсов Реалвеб

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

    • Волшебник импровизирует

      Усталость, ошибки и собственные реплики оператора разрушают единообразие и надёжность данных. Дайте шаблоны и репетиции.

    • Заминки выдают иллюзию

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

    • Волшебник подсказывает

      Если он направляет участника или добавляет своё мнение, результат искажён.

    • Слишком сложная симуляция

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

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

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

    • Нет ответов на сбои

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

    • Нет раскрытия и разбора

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

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

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

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

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

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

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