Золотое правило MVP: как расставлять приоритеты в разработке голосовых навыков

Привет, я Никита Муренький, лид команды разговорных продуктов KODE. Мы разрабатываем голосовых ассистентов и чат-ботов. Моя команда занимается проектированием и аналитикой, отвечает за пользовательский опыт и развитие продукта.

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

Пару слов о том, почему этот вопрос вообще важен. Разработкой хоть сколько-нибудь сложного чат-бота или голосового приложения занимается целая команда менеджеров, разработчиков, тестировщиков, UI/UX и разговорных дизайнеров. Если неправильно расставить приоритеты, все эти люди будут неделями работать над сценариями диалогов, которые в первом релизе увидит 0,05% пользователей, а то и вовсе 0%. Это обидно для специалистов и дорого для бизнеса.

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

Каждый интент на MVP должен помочь кооперативному пользователю пройти целевой сценарий.

Что это значит, мы разберем на примере обработки ошибок – одном из проблемных мест разговорного дизайна.

1. Помнить про целевой сценарий

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

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

— Очисти корзину.

— Готово.

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

«Простите, не могу», — извиняться не за что.

«Корзина уже пуста», — из этой фразы не ясно, была ли совершена очистка.

По правилам дизайна надо донести до пользователя недвусмысленную информацию и вернуть ему контроль над диалогом. Вот, что у нас получилось:

— Очисти корзину.

— В корзине ещё ничего нет. Давайте это исправим!

В этом случае пользователь приятно удивлён интеллектом и удобством ассистента, а VUI-дизайнер берёт с полки пирожок. Или нет?

2. Думать с точки зрения UX

Почему потребитель просит очистить пустую корзину:

• Не уверен, что корзина пуста.

• Не завершил заказ ранее и не знает об автоочистке корзины.

• Пользуется навыком вместе с кем-то из членов семьи.

• Забыл, добавлял ли что-то сегодня утром.

С точки зрения UX нас волнует только намерение пользователя. И тут важно понять: он не думает очищать корзину, а хочет знать, что она пуста, чтобы не заказать ничего лишнего.

Ещё раз сравним два диалога.

— Очисти корзину.

— Готово.

— Очисти корзину.

— В корзине ещё ничего нет. Давайте это исправим!

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

Именно об этом говорит правило: если интент не помогает пройти целевой сценарий или вернуться к нему, не торопитесь его вводить.

Да, без обработки ошибки ассистент выглядит глупее, но если пользователь этого не заметит (он ведь не знал, что корзина пуста), то стоит ли овчинка выделки? Экономьте часы разработчиков.

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

3. Рассматривать только кооперативного пользователя

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

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

При обработке ошибок рассматривайте только кооперативного пользователя — такого, который пытается пройти целевой сценарий.

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

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

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

• Может ли такое сказать кооперативный пользователь?

• Поможет ли нововведение пройти целевой сценарий или вернуться к нему?

Если пользователь свернул с happy path — идеального сценария без ошибок — и не может вернуться самостоятельно, ему надо помочь. Рассматривайте это как часть целевого варианта: включите фразы «помощь» и «как сделать…».

А если распознавание речи работает хорошо и ошибки обработаны, но кооперативный пользователь всё равно часто убегает с happy path, вероятно, вы забыли провести онбординг. Но это уже другая история.