Разговорный интерфейс, а не интерфейс приложения
Агенты RBM хорошо подходят для предоставления пользователям эффективных и конкретных задач в диалоговом пользовательском интерфейсе. Агенты с лучшим дизайном делают взаимодействие сфокусированным, простым для понимания и структурированным, как естественный разговор.
Агенты не могут полагаться на визуальный пользовательский интерфейс приложения или веб-страницы и не должны пытаться имитировать его. Вместо этого агенты должны полагаться на тщательно продуманные диалоги, учитывающие потребности пользователей, направляя их словесными подсказками, предложениями и хорошей обработкой ошибок.
Агенты также не должны имитировать телефонные деревья или интерфейсы, которые полагаются на то, что пользователи отвечают числом, представляющим данное действие. Пользователи должны иметь возможность общаться с агентами естественным образом, как если бы они общались с другим человеком в беседе.
Дополнительные сведения о диалоговом пользовательском интерфейсе см. в разделе Диалоговый пользовательский интерфейс и почему это важно .
Проверьте возможности устройства
Перед началом разговора с пользователем убедитесь, что устройство пользователя может получать RCS-сообщения. Отправьте запрос возможностей , чтобы определить возможности устройства и соответствующим образом настроить взаимодействие вашего агента. Взаимодействуйте с пользователями только способами, которые поддерживают их устройства. Если устройство пользователя не поддерживает RCS, настройте резервный метод связи с другой технологией, например с помощью SMS.
Начать разговор
Начало разговора устанавливает ожидания пользователя относительно того, что может сделать агент. Начните разговор с сильной ноты: покажите личность вашего агента, заранее загрузите информацию, которая важна для ваших пользователей, и расскажите, на что способен ваш агент. Предоставьте пользователям четкие варианты взаимодействия с вашим агентом и продолжения разговора.
Держите хороший ритм
Использование различных типов информации в беседах поддерживает вовлеченность пользователей и взаимодействие с вашим агентом, но будьте осторожны, чтобы не перегружать пользователей. Держите сообщения в пределах привлекательной, удобоваримой длины, которая позволяет пользователю видеть все сообщение на экране сразу. Изображения и расширенные карточки могут занимать много места на экране, поэтому помните, сколько пользователю нужно прокрутить, чтобы прочитать сообщение целиком.
Держите сообщения в порядке
Если вы отправляете несколько сообщений последовательно, важно, чтобы пользователи получали эти сообщения по порядку. Некоторые сообщения, например содержащие мультимедиа, обрабатываются дольше, чем другие, например текстовые сообщения. Чтобы убедиться, что пользователи получают сообщения в том порядке, в котором вы их отправляете, подождите, пока вы не получите ответ 200 OK на сообщение, прежде чем отправлять следующее сообщение в последовательности.
Ответ 200 OK подтверждает, что платформа RBM получила сообщение и что пользователь должен получать ваши сообщения в правильном порядке. Если вы не дождетесь ответа 200 OK перед отправкой другого сообщения, пользователи могут получать ваши сообщения не по порядку.
Проверять наличие дубликатов входящих сообщений
Когда вы проверяете входящие сообщения от пользователей и отвечаете на них, проверьте messageId и убедитесь, что вы еще не получили сообщение и не ответили на него ранее.
В распределенных системах существует два способа отправки сообщений: не более одного раза и не более одного раза.
- В системах «не более одного раза» система отправляет сообщение один раз, но если по пути возникают сетевые или коммуникационные ошибки, сообщение может не быть получено.
- В системах «по крайней мере один раз» система может отправлять сообщение несколько раз, но сообщение может быть получено даже при наличии сетевых или коммуникационных ошибок.
Google Cloud Pub/Sub использует систему «хотя бы один раз». Хотя это может привести к дублированию входящих сообщений, дедупликацию сообщений можно легко устранить, отслеживая строки messageId . Если вы уже получили сообщение, можно безопасно игнорировать любые дополнительные сообщения, которые вы получаете с тем же messageId .
Пишите четкие и последовательные сообщения
Отправляйте привлекательные и понятные сообщения. Хороший текст сообщения побуждает пользователей реагировать, а согласованность стиля, форматирования и темпа текста вызывает доверие у пользователей.
При создании текста сообщения учитывайте следующие дополнительные рекомендации:
- Не создавайте тупиков. Каждый предлагаемый ответ должен вести к содержательной беседе с пользователем.
- При необходимости обращайтесь к пользователю «вы», а не «я».
- Для заголовков и меток используйте регистр предложений, а не заглавий. Например, «Выписка по счету», а не «Выписка по счету».
- Используйте сокращения. «Это» более разговорное, чем «это».
- Используйте восклицательные знаки экономно.
- Используйте серийную запятую. Например, «А, В и С», а не «А, В и С».
- Запишите числа как цифры. Например, «1, 2, 3», а не «раз, два, три».
Уважайте, когда пользователям не нужны сообщения
Когда пользователь указывает, что он хотел бы прекратить получать сообщения от вашего агента, вы должны уважать его выбор. Ваш агент должен понимать, когда пользователи отвечают «СТОП», и реагировать соответствующим образом. Ваш агент должен понимать различные способы, которыми пользователи могут сообщать о своем желании прекратить получать сообщения, включая все языки, которые они могут использовать для сообщения о своих желаниях.
Ознакомьтесь с законами и передовой практикой для вашей страны, чтобы узнать, как реагировать на STOP и другие обязательные команды. Например, обратитесь к рекомендациям CTIA .
Помогите пользователю
Ваш агент должен отвечать на сообщения HELP от пользователей и информировать пользователей о возможностях вашего агента. Такая простая вещь, как список предлагаемых ответов, соответствующих функциям вашего агента, может превратить плохой пользовательский опыт в полезный.
Реализуйте повторные попытки с экспоненциальным отставанием
При вызове любого API возможен сбой вызова из-за проблем с инфраструктурой, перегрузки службы, ограничений количества запросов в секунду и других ошибок. Чтобы корректно восстанавливаться после неудачных вызовов API, реализуйте повторные попытки с экспоненциальной задержкой.
Используя повторы с экспоненциальной задержкой, ваша инфраструктура автоматически делает следующее:
- Идентифицирует неудачный вызов API.
- Задает начальную продолжительность ожидания и максимальное количество повторных попыток.
- Пауза на время ожидания.
- Повторяет вызов API.
Оценивает ответ на вызов API:
- В случае успеха переходит к следующему шагу рабочего процесса.
- В случае сбоя увеличивает продолжительность ожидания и возвращается к шагу 3.
- Если сбой после максимального количества попыток, переходит в состояние сбоя.
Идеальная продолжительность ожидания и идеальное максимальное количество повторных попыток зависят от варианта использования. Определите эти числа на основе требований к задержке вашей инфраструктуры и рабочих процессов.
Богатые карты
Расширенные карты позволяют объединять медиафайлы, текст и предложения в одном сообщении. Таким образом, мультимедиа не должно быть единственным элементом расширенной карточки, а предлагаемые ответы или предлагаемые действия всегда должны сопровождать отдельную расширенную карточку.
Вертикальные расширенные карточки
Вертикальные расширенные карты отображают горизонтальные медиа в верхней части карты. Горизонтальные носители должны иметь соотношение сторон 2:1, 16:9 или 7:3.
Когда вы отправляете медиафайлы пользователю, вы должны с уважением относиться к ресурсам пользователя. Когда горизонтальный носитель имеет соотношение 2:1, оптимальное разрешение для носителя составляет 1440x720 пикселей с максимальным рекомендуемым размером файла 2 МБ для изображений и 10 МБ для видео. Оптимальное разрешение для миниатюры носителя — 770x335 пикселей с рекомендуемым размером файла 40 КБ и рекомендуемым максимальным размером 100 КБ.
Горизонтальные расширенные карты
Горизонтальные расширенные карты отображают вертикальные медиафайлы с левой или правой стороны карты. Вертикальные носители должны иметь соотношение сторон 3:4.
Когда вы отправляете медиафайлы пользователю, вы должны с уважением относиться к ресурсам пользователя. Когда вертикальный носитель имеет соотношение сторон 3:4, оптимальное разрешение для носителя составляет 768x1024 пикселей с максимальным рекомендуемым размером файла 2 МБ для изображений и 10 МБ для видео. Оптимальное разрешение миниатюры медиафайла — 250x330 пикселей, рекомендуемый размер файла — 40 КБ, рекомендуемый максимальный размер — 100 КБ.
Карусели с богатыми картами
Карусели Rich Card идеально подходят для просмотра контента или различных вариантов, но их следует использовать только тогда, когда есть несколько элементов для чтения или сравнения, таких как тарифные планы или устройства. Первый элемент в карусели должен быть оптимальным выбором в любой конкретной ситуации, и пользователь должен объяснить, почему это оптимальный выбор.
Фишки предложений под каруселью должны продвигать или поворачивать разговор. Фишки предложений не должны повторять параметры, перечисленные в карусели, и не являются инструментами выбора элементов, представленных в карусели.
Медиа в каруселях Rich Card
Карусели расширенных карточек отображают горизонтальные медиафайлы в верхней части расширенных карточек. Горизонтальные медиа в каруселях должны иметь соотношение сторон 4:3.
Когда вы отправляете медиафайлы пользователю, вы должны с уважением относиться к ресурсам пользователя. Когда носитель имеет соотношение сторон 4:3, оптимальное разрешение для носителя составляет 960x720 пикселей с максимальным размером файла 1 МБ для изображений и 5 МБ для видео. Оптимальное разрешение миниатюры медиа — 605x452 пикселей, рекомендуемый размер файла — 40 КБ, а рекомендуемый максимальный размер — 100 КБ.
Предлагаемые ответы и действия
Предлагаемые ответы и действия в расширенной карточке должны относиться непосредственно к содержимому этой карточки.
Предлагаемые ответы и действия в списке фишек должны быть способами продвижения или поворота беседы.
Предлагаемые ответы
Предлагаемые ответы помогают пользователям реагировать на ваш агент таким образом, чтобы ему было легко ответить. Если взаимодействие не требует ответа в произвольной форме, используйте предлагаемые ответы. Их легче обрабатывать, чем текст произвольной формы, и они позволяют вашему агенту направлять разговоры по оптимальному пути.
Предлагаемые действия
Предлагаемые действия позволяют агенту подключаться к собственным действиям устройства и обеспечивают тесно интегрированный интерфейс для пользователя. Когда это уместно, предлагаемые действия могут упростить вызов службы поддержки клиентов или поиск местоположения на карте.
Но не перегружайте пользователей опциями. Предоставляйте только те действия, которые относятся к самому последнему сообщению, и только столько действий, сколько необходимо. Ограничьте количество предлагаемых действий и предлагаемых ответов тем, что полезно для пользователя в данном контексте.
Завершение дизайна
Дизайн для разговора, удобство использования и эффективность являются наиболее важными при создании вашего агента. Агенты должны сосредоточиться на диалоговом пользовательском интерфейсе и направлять пользователей через оптимальные рабочие процессы с предлагаемыми ответами и действиями. При использовании изображений или расширенных карт агент должен поддерживать ритм, который позволяет пользователям сохранять контекст и легко читать сообщения.
Учет пользовательского опыта и избегание диалоговых тупиков при разработке вашего агента дает пользователям положительный опыт и побуждает их снова использовать ваш агент в будущем.