Як ми вже писали, CUI (conversational user interface) – це концепція інтерфейсу, яка розмовляє з користувачем на одній мові.
Специфіка CUI для чатбота полягає в тому, що при його створенні прописується величезна кількість сценаріїв розвитку подій, що повинні враховувати обмежені можливості інтерфейсу бота. Детальність і продуманість цих сценаріїв обумовлює майбутнє цього бота. Якщо бот не розуміє і не реагує належним чином на запити, він ніколи не стане популярним і не принесе своєму власникові бажаного ефекту. Хто повторно звертатиметься до бота, що безліч разів ставить одне й те-ж запитання, і не може вийти з глухого кута?
При створенні зручного і продуктивного чатбота на основі концепції CUI, ми виділили декілька важливих принципів. Про них, і їхні ролі в житті бота і піде далі мова.
Спілкування з чатботом завжди відбувається в один канал, і це обмежує можливість вибору. Маленький екран в месенджері не дозволяє відобразити велику кількість інформації, і в тому числі надати користувачеві повноцінний вибір. Він може видавати інформацію по черзі, але користувачеві буде складно гортати великі обсяги видачі. Так як користувач не може зробити множинний вибір, натискати на кнопки всередині діалогу – CUI повинен бути грамотно продуманий з урахуванням обмежень месенджера.
Ось кейс бота для сайту pulti.ua – бот допомагає підібрати і купити пульт. І коли на запит потрібно видати велику кількість інформації – інтерфейс месенджера адекватно це зробити не в змозі. CUI вирішує цю задачу, запропонувавши користувачеві отримати результати пошуку через сторінку сайту, або уточнити деталі пошуку.
Зазвичай, при введенні необхідної інформації в форми браузера – у користувача є підказки. Це список автодоповнення, що видає підказки біля форми, і обмежує перехід на наступний етап у разі введення некоректних значень. Можливості месенджера не дозволяють цього зробити в рядку введення, і CUI повинен обійти це обмеження та допомогти користувачеві надати дані коректно.
У цьому кейсі показано як вирішується проблема ідентифікації населених пунктів, для нп з однаковими назвами. Що ми робимо? Даємо можливість боту перепитати, при не точному введенні користувачем даних: “виберіть один з варіантів”, або “можливо ви мали на увазі це” … і задати відповідь кнопками. Тоді імовірність відправки боту неправильної адреси зменшується. І це може бути застосовано не тільки для адрес. Аналогічно можна і задати параметри для будь-якої відповіді користувача: “введіть ваш номер телефону в форматі + 380 ….”, І бот може не приймати відповідь, яка не відповідає заданому формату. Але далеко не всі дані можна так провалідувати.
Коли відбувається збій або в мережі, або у бота – важливо забезпечити можливість “оживити завислого бота”. Для того, щоб не викликати у користувача гнівного стану, бот повинен вміти розпізнавати емоційний імпульс.
Наприклад, якщо бот надав вибір у вигляді кнопок, а через проблеми з мережею у користувача вони не відобразилися – бот не може йти далі, поки користувач не зробить вибір. Він буде наполягати на виборі із запропонованих кнопок, і на цьому застрягне.
Як ми з допомогою CUI вирішуємо це питання? Ми закладаємо боту “кодові слова”, або “стоп слова”, які провокують екстрений сценарій. Бот розуміє що щось пішло не так, і може запропонувати користувачеві варіанти вирішення проблеми (повернутися на крок назад, або розпочати спочатку). Це можуть бути будь-які слова, якими користувачі в повсякденному житті висловлюють своє невдоволення, в тому числі і “стій”, “назад”, “не тупи”, “завис” та ін.
Можливість повернутися на крок, або блок назад, без втрати внесених раніше даних дуже важлива. Особливо коли справа стосується заповнення великої кількості важливих даних.
Те ж стосується і ситуації, коли сценарій заходить в глухий кут через непродуманість заздалегідь кейсу. Якщо він не може впоратися з ситуацією, не знає, або не може вивести даних / відреагувати на запит – повинен бути передбачений “запасний план”. Тоді чатбот запропонує залишити свій номер для зворотного дзвінка, або переключити на оператора/ написати заявку на пошту. Але саме важливо тут – зберегти введену користувачем інформацію. Тоді менеджер, який обробляє запит вже буде мати часткові дані про клієнта, і користувачеві не потрібно буде повторяться.
Для бота всі стандартні кнопки і можливості відрізняються від web-івських. Те саме стосується заповнення форм.
У браузері, при помилці, або введенні некоректних значень – наступний крок не відбувається, і помилки підсвічуються. У користувача є багато точок дотику з інтерфейсом, і є можливість вводити інформацію в будь-який черговості, змінювати, перевіряти до моменту відправлення форми.
У чатботі користувач може виправити зроблену помилку вдавшись до кроку назад. Але користувач заздалегідь не знає як це зробити – і бот повинен володіти широким спектром слів-індикаторів, щоб максимально спростити взаємодію. Або заздалегідь попередити користувача – як повернутися назад, або розпочати заново.
Для зручності взаємодії користувача з ботом потрібно допомогти користувачеві “не загубитися”. Найпростіше це реалізовано в ботах типу “додатка”. У таких ботах користувач здебільшого взаємодіє з допомогою кнопок, які за своїм дизайном дуже схожі з кнопками додатків. При грамотній побудові логіки кнопок – користувачеві загубитися буде дуже складно.
Ось приклад двох кнопкових ботів, і того як одними й тими-ж інструментами можна зробити зручний бот, а можна доводити користувачів до “нервового зриву”.
Зліва бот FC Barcelona – зручний і зрозумілий бот, а праворуч – бот Київводоканалу, в якому є “точки неповернення”. У ньому не можна повернутися ні назад, ні в меню – потрібно тільки видаляти діалог і розпочинати все спочатку.
Багато ботів приймають і обробляють персональні дані користувачів, але в них не закладена авторизація користувачів і захищеність їх даних.
І ось що ми виявили – один відомий бот (не вказуватимемо пальцем) приймає дані за номером договору. Досить ввести номер договору, і бот сприймає тебе за істинного користувача, не вимагаючи додаткових даних/підтверджень. Більш того, він зберігає в собі якусь базу, яка стає доступна. В результаті: ввівши навмання номер договору – отримуєш інформацію про іншу людину і його дані. Іще й на додачу можна вносити зміни і нашкодити.
Вирішується така проблема будь-яким із способів авторизації – пароль / ключове слово / код підтвердження з смс, або хоча-б додатково запитати іще даних (прізвище, або номер телефону).
Специфіка сесії з чатботом полягає в її обмеженості в часі. Тобто боти не чекають відповіді вічно, та це б не мало ніякого сенсу. Логікою бота закладається час на відповідь, по завершенню якого – алгоритм сесії бота закінчується, і бот повертається на точку старту. Тут важливий момент – нагадати користувачеві, що бот чекає його повідомленням. Тоді у користувача не виникне претензій, що по його поверненню – бот не пам’ятає на чому зупинилася їхня розмова.
.
Не завжди товариського інтерфейсу достатньо для потреб користувача. Наприклад, для введення даних банківської карти краще використовувати форми (GUI – графічний інтерфейс). Межі CUI там, де закінчується можливість зручно вирішити питання за допомогою звичайного спілкування. Оптимальніше всього комбінувати різні інтерфейси в одному боті, використовуючи від кожного максимально зручні елементи.
Комунікабельний інтерфейс CUI займає ключову роль при створенні чатботу. Але використання його бездумно – не дає автоматичної можливості створення якісного бота. Потрібно завжди продумати максимальну кількість сценаріїв розвитку під кожну подію, враховувати нюанси і потреби користувачів, тестувати і перевіряти ще раз логіку гілок рішень щоб уникнути тупиків.
Ми розглянули кілька кейсів рішення проблем, що виникають при створенні чатботів. Ми вирішили їх, застосовуючи принципи CUI, сформульовані Полом Грайсом.
Для того, щоб із ботом можна було нормально спілкуватися, не існує універсального шаблону. Чатбот повинен використовувати різні алгоритми, роблячи спілкування максимально наближеним до людського.
Не дивлячись на те, що поки системи розпізнавання людської мови ще не надто розвинена і мало використовуються на практиці – деякі принципи ми вже застосовуємо, щоб робити ваших ботів краще. Звертайтеся до нас.