Метод Волшебника Страны Оз
Wizard of Oz Testing
Метод Волшебника Страны Оз (Wizard of Oz Testing) проверяет идею продукта до разработки. Участник работает с системой, которая выглядит рабочей, а ответы вручную даёт скрытый человек, «волшебник». Так видно, как люди будут вести себя с функцией, которой ещё нет.
- Сроки
- 5–21 день
- Респонденты
- 5–15 человек
- Команда
- 2–3 человека
- Бюджет
- Низкий
- Сложность
- Средний
- Популярность
- Редко
Содержание
Когда использовать
Метод нужен на ранней стадии, когда концепция сырая, а команде нужно направление. Он подходит для новых типов взаимодействия и сложных систем вроде ИИ-помощников, где полный прототип дорог или преждевременен. Голосовые интерфейсы и диалоги проверяют им чаще всего. Работать с ним можно и с услугами, когда за кулисами стоят люди и устройства. Главный вопрос, на который он отвечает, будут ли люди этим пользоваться и как они сформулируют запросы.
Метод не подходит для детальной проверки почти готового дизайна, там лучше работает подробный прототип в юзабилити-тестировании. Не годится он и для систем с очень разнообразными, сложными или непредсказуемыми ответами, которые человеку не воспроизвести одинаково. Скорость, нагрузку и точность распознавания речи таким образом не оценить. Идею, которую нужно показать целиком, можно проверить в тесте концепции.
Что нужно для старта
- Вопрос, на который нужен ответ, и список задач для участников
- Сценарии заданий с контекстом, без слов, которые подсказывают, как называется функция
- Заготовленные ответы «системы», включая ответ на запрос, который она не распознала или не может выполнить
- Прототип или материалы, из которых собирается видимость системы. Бумага, картон, кликабельные макеты, консоль для оператора
- Способ скрыть волшебника. Видеосвязь или другая комната, при этом он должен видеть и слышать участника
- Роли. Модератор, волшебник, при необходимости наблюдатель, который записывает
- Пять и более участников и 30–90 минут на сессию
Как провести
-
Вопросы и сценарий
Определите, что хотите узнать, какие задачи дадите и насколько подробным должен быть прототип. Опишите ситуацию, в которой у человека возникает потребность, без слов, которые активируют функцию. Иначе участник повторит формулировку из задания.
-
Ответы и материалы
Подготовьте шаблоны ответов заранее, в том числе запасные на случай, когда запрос неожиданный или система «не поняла». Соберите материалы, чтобы волшебник мог быстро показать нужный ответ.
-
Роли и обучение волшебника
Волшебнику объясните цели исследования, нужную единообразность реакций и то, как не вносить в ответы своё мнение. Ему нужно хорошо знать продукт, а если ответы звучат, то и говорить внятно. Один волшебник на очень сложную симуляцию не справится.
-
Площадка
Для онлайна используйте видеосвязь и назовите волшебника названием продукта с логотипом или нейтральным фоном. Офлайн посадите волшебника в другую комнату или за зеркальную стену и свяжитесь с ним через чат. Участник не должен его видеть.
-
Репетиция
Прогоните сценарии на коллегах из других проектов, чтобы найти слабые места. Волшебник должен отработать сценарий до единообразия.
-
Сессии
Расскажите участнику контекст и дайте задачу. Волшебник отвечает быстро и единообразно, потому что задержка разрушает ощущение естественности. Наблюдатели записывают ошибки, идеи и вопросы.
-
Разбор между сессиями
После каждой сессии команда обсуждает, что сработало, и расставляет приоритеты. Ответы волшебника правят между задачами, а не пытаются сделать идеальными заранее.
-
Раскрытие и итоги
В конце расскажите участнику, что часть системы изображал человек, и объясните зачем. Попросите пояснить причины поведения. Сохраните конфиденциальность данных.
Результат
Журнал наблюдений по сессиям, цитаты и видео, список проблем и открытий и решения, что делать с функцией. Из реплик участников получается словарь запросов, а из паузы или сбоя волшебника список мест, где система должна страховать пользователя.
Типичные ошибки
-
Волшебник импровизирует
Усталость, ошибки и собственные реплики оператора разрушают единообразие и надёжность данных. Дайте шаблоны и репетиции.
-
Заминки выдают иллюзию
Неестественные фразы и паузы дают понять, что отвечает человек. Репетируйте и держите ответы быстрыми.
-
Волшебник подсказывает
Если он направляет участника или добавляет своё мнение, результат искажён.
-
Слишком сложная симуляция
Один человек не справится с большим числом путей. Сузьте сценарий или добавьте помощников.
-
Слова из задания в речи участника
Если в тексте задания звучит название функции, респондент повторяет его. Описывайте ситуацию.
-
Нет ответов на сбои
Без заготовленных ответов на нераспознанный запрос волшебник импровизирует, а данные получаются несравнимыми.
-
Нет раскрытия и разбора
Участнику нужно сказать, что часть системы была симуляцией, и расспросить о причинах поведения.
Российская специфика
В русскоязычном разборе голосовых интерфейсов предлагают провести тест онлайн в видеоконференции, переименовав волшебника в название продукта. Ещё один вариант, перевёрнутый: роль волшебника играет сам респондент. На один прототип может понадобиться до трёх человек, модератор, волшебник и ассистент, который записывает запросы.
Кто использует
В Smashing Magazine описаны два примера. Дизайнер сыграл ИИ-помощника для HR-системы, возвращая шаблонные планы онбординга. Участники переоценивали возможности и спрашивали о контроле, и команда добавила прозрачность и подтверждение действий человеком. В машине волшебник в соседней комнате запускал ответы на голосовые команды, и стало видно, какие команды неоднозначны и какие формулировки предпочитают люди, до того как была разработана система распознавания.
Первой работой о методе считают статью Келли 1984 года о проектировании офисных приложений на естественном языке. Популярным его сделали, как пишут в Smashing Magazine, исследования IBM с голосовой печатной машинкой.
Место в процессе
- Глубинные интервьюГлубинное интервью (in-depth interviews) — разговор один на один, цель которого понять контекст, мотивы и опыт человека. Это не тест продукта и не сбор мнений, а способ узнать, как устроена жизнь пользователя вокруг проблемы, которую вы решаете.
- Проверка концепцииПроверка концепции (Concept Testing) показывает, как аудитория реагирует на идею продукта или функции до того, как её начали делать. Людям показывают описание, скетч, макет или лендинг и выясняют, понимают ли они идею, нужна ли она им и решает ли их задачу.
- Юзабилити-тестированиеЮзабилити-тестирование (usability testing) показывает, где люди спотыкаются о продукт. Участнику дают реалистичную задачу, например оформить заказ или найти настройку, и наблюдают, как он её выполняет. Исследователь фиксирует, где человек буксует, ошибается или теряет ориентацию.
- A/B-тестированиеA/B-тестирование (A/B testing) показывает, какой из двух вариантов интерфейса лучше достигает заданной метрики, например конверсии или кликов. Пользователей случайно делят на группы, каждая видит свой вариант, а результаты сравнивают статистически.