Как мы уже писали, CUI (conversational user interface) — это концепция пользовательского интерфейса, говорящего с пользователем на одном языке.

Специфика CUI для чатбота состоит в том, что при его создании прописывается огромное количество сценариев развития событий, которые должны учитывать ограниченные возможности интерфейса бота. Детальность и продуманность этих сценариев обусловливает будущее этого бота. Если бот не понимает и не реагирует должным образом на запросы — он никогда не станет популярным, и не принесет своему владельцу желаемого эффекта. Кто повторно обратиться к боту, который до бесконечности задает один и тот-же вопрос, и не может выехать из тупика?

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

Принципы концепции CUI, которых нужно придерживаться при создании чатбота:

Ограничение интерфейса мессенджера

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

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

 Пример бота

Корректность введенных пользователем данных

Привычно всем, что при вводе необходимой информации в формы браузера — у пользователя есть подсказки. Это выпадающий список автодополнений, подсказки возле формы, и невозможность перехода на следующий этап в случае допущения не корректных значений. Возможности мессенджера не позволяют этого сделать в строке ввода, поэтому CUI должен обойти это ограничение и помочь пользователю предоставить данные корректно.

Вот такой вид имеет автопродление на сайте:

Автозаполнение на сайте

А так мы реализовали аналогию в чатботе:

 Автозаполнение в чатботе

В этом кейсе показано как решается проблема идентификации населенных пунктов, для нп с одинаковыми названиями. Что мы делаем? Даем возможность боту переспросить, при не точном введении пользователем данных: “выберите один из вариантов”, или “возможно вы имели ввиду это”… и задать ответ кнопками. Тогда вероятность отправки боту неправильного адреса уменьшается. И это применимо не только для адресов. Аналогично можно и задать параметры для ответа пользователя: “введите ваш номер телефона в формате +380….”, и бот может не принимать ответ, которых под формат не подходит. Но далеко не все данные можно провалидировать.

Выход из тупикового сценария

Когда происходит сбой или в сети, или у бота — важно обеспечить возможность “оживить зависшего бота”. Для того, чтоб не вызывать у пользователя состояния “бешенства” бот должен уметь распознавать эмоциональный импульс.

Например, если бот предоставил выбор в виде кнопок, а из-за проблем с сетью у пользователя они не отобразились — бот не может идти дальше, пока пользователь не совершит выбор. Он будет настаивать на выборе из предложенных кнопок, и на этом застрянет.

Как мы с помощью CUI решаем этот вопрос? Мы закладываем боту “кодовые слова”, или “стоп слова”, которые провоцируют экстренный сценарий. Бот понимает, что что-то пошло не так, и может предложить пользователю варианты решения проблемы (вернуться на шаг назад, или начать заново). Это могут быть любые слова, которыми пользователи в обыденной жизни выражают свое недовольство, в том числе и “стой”, “назад”, “не тупи”, “завис” и тд.

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

То же касается и ситуации, когда сценарий заходит в тупик из-за непродуманного заранее кейса. Если он не может справиться с ситуацией, не знает или не может вывести данных/отреагировать на запрос — должен быть предусмотрен “запасной план”. Тогда чатбот предложит оставить свой номер для обратного звонка, или переключить на оператора, или написать заявку на почту, и тд. Но самое важно здесь — сохранить введенную пользователем информацию. Тогда менеджер, обрабатывающий запрос уже будет иметь частичные данные о клиенте, и пользователю не нужно будет повторятся.

Возврат на шаг, или блок назад

Для бота все стандартные кнопки и возможности отличаются от web-овских. То же и касается заполнение форм.

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

Заполнение формы

В чатботе пользователь может исправить совершенную ошибку призвав к шагу назад. Но пользователь заранее не знает, как это сделать — и бот должен обладать широким спектром слов-индикаторов, чтоб максимально упростить взаимодействие. Или как вариант — предварительно предупредить пользователя — как вернуться назад, или начать заново.

Понятность и логичность бота

Привычно всем, что при вводе необходимой информации в формы браузера — у пользователя есть подсказки. Это выпадающий список автодополнений, подсказки возле формы, и невозможность перехода на следующий этап в случае допущения не корректных значений. Возможности мессенджера не позволяют этого сделать в строке ввода, поэтому CUI должен обойти это ограничение и помочь пользователю предоставить данные корректно.

Для удобства взаимодействия пользователя с ботом нужно помочь пользователю “не потеряться”. Проще всего это реализовано в ботах типа “приложения”. В таких ботах пользователь по большей части взаимодействует с помощью кнопок, которые по своему дизайну очень схожи с кнопками приложений. При грамотном построении логики кнопок — пользователю потеряться будет очень сложно.

Вот пример двух кнопочных ботов, и того как одни и теми-же инструментами можно сделать удобный бот, а можно доводить пользователей до “нервного срыва”.

 

Пример бота Чатбот - пример

Слева бот FC Barcelona — удобный и понятный бот, а справа — бот Киевводоканала, в котором есть “точки невозврата”. В нем нельзя вернуться ни назад, ни в меню — нужно только удалять диалог и начинать все заново.

Авторизация и защищенность данных

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

И вот что мы обнаружили — один известный бот (не будем тыкать пальцем) принимает данные по номеру договора. Достаточно ввести номер договора, и бот воспринимает тебя за истинного пользователя, не требуя дополнительных данных/подтверждений. Более того, он хранит в себе некую базу, которая становится доступна. Что в результате: введя наугад номер договора — получаешь информацию о другом человеке и его данных. И в придачу можешь вносить изменения, и “наломать ему дров”, при желании.

Решается такая проблема любым из способов авторизации — пароль/ключевое слово/код подтверждения из смс, или хотя-бы дополнительно запросить еще данных (фамилию, или номер телефона).

 Вот так любой может получить доступ к чужому лицевому счету

Доступы

Ограниченность сессии бота во времени

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

OSAGO бот

Комбинированный UI

Не всегда общительного интерфейса достаточно для потребностей пользователя. Например, для ввода данных банковской карты лучше использовать форм (GUI — графический интерфейс). Границы CUI там, где заканчивается возможность удобно решить вопрос посредством обычного общения. Лучше всего комбинировать разные интерфейсы в одном боте, используя от каждого максимально удобные элементы.

Дизайн чатбота

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

Принципы CUI решают большинство проблем, возникающих при создании чатбота

Мы рассмотрели несколько кейсов решения проблем, возникающих при создании чатботов. Мы решили их, применяя принципы CUI, сформулированные Полом Грайсом.

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

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

 

05.04.2018
Используемые в статье картинки взяты из открытых источников и используются как иллюстрации.