Говорить на языке пользователя, а не на языке базы данных
Этот принцип кажется очевидным, но его сложнее всего воплотить в жизнь. Технические специалисты, которые часто и занимаются первыми набросками сценариев, мыслят категориями своей системы: «тикет», «статус», «ID заказа», «логин». А обычный человек мыслит категориями своей проблемы: «заказ не пришел», «не могу зайти», «с меня списали лишнее». Проектирование сценария – это постоянный перевод. Вы должны создать такой путь, где вход – это естественная фраза пользователя на человеческом языке, а выход – это четкое действие в вашей внутренней системе. И весь диалог между этим входом и выходом должен идти без требующих перевода технических жаргонизмов. Бот не должен спрашивать: «Укажите идентификатор вашего тикета». Он должен сказать: «Давайте найдем ваше обращение. Введите номер, который был в письме-подтверждении, или укажите email, на который вы его отправляли». Это разница между разговором с роботом и разговором с помощником, который просто хорошо знает свое дело.
Остановитесь на минутку. Вспомните свой последний неудачный опыт общения с автоответчиком в банке или у провайдера. Что именно вызвало раздражение? Скорее всего, вы наткнулись на место, где сценарий сломался. Где вас не поняли, заставили пятый раз повторять одно и то же или отправили по кругу. Запишите эту точку. Вот именно в таких местах и нужна ваша особая внимательность как проектировщика. Ваша задача – предвидеть эти точки сбоя и заложить в сценарий «амортизаторы» – плавные переходы, уточняющие вопросы, альтернативные пути. Не оставляйте пользователя в тупике с холодным «Команда не распознана». Всегда давайте ему возможность сделать шаг назад, переформулировать или просто начать заново, без чувства вины за то, что он «неправильный» пользователь.
Проектирование сценария – это не программирование, это скорее картография неизвестной территории, по которой предстоит путешествовать тысячам разных людей. Вы не можете контролировать каждый их шаг, но вы можете расставить такие указатели, помосты и пункты помощи, чтобы даже тот, кто заблудился, в итоге нашел свой путь. И помните, первый набросок карты всегда будет неполным. Его нужно тестировать, дорисовывать, исправлять. Но если вы заложите в основу эти принципы – модульность, ориентацию на цель и человеческий язык, – то ваши правки будут не паническим латанием дыр, а спокойным и уверенным улучшением уже работающего маршрута.
Карта диалога: пользовательские интенты и сценарии
Давайте представим на минутку, что наш бот – это водитель такси в огромном, незнакомом городе. Пассажир садится в машину и что-то говорит. Он может попросить: «На вокзал, пожалуйста», а может бросить многозначительное: «Меня ждут важные люди». Задача водителя – понять не только буквальный смысл, но и конечную цель: человеку нужен вокзал. Это и есть интент – намерение, скрывающееся за словами. Карта диалога – это и есть подробный атлас всех возможных дорог (сценариев) ко всем возможным точкам назначения (интентам). Без нее наш водитель будет кружить по городу, тратя бензин и нервы пассажира, пока тот не выйдет из машины, хлопнув дверью.
Поэтому первое и самое важное правило звучит почти как заповедь: диалог существует ради цели пользователя, а не ради демонстрации интеллекта бота. Каждый раз, когда вы проектируете сценарий, задавайте себе простой вопрос: «Чего на самом деле хочет человек, написавший это?». Он не хочет «узнать информацию о статусе заказа». Он хочет понять, приедет ли сегодня его посылка с подарком для сына. Он не хочет «инициировать процедуру возврата». Он хочет вернуть не подошедшие кроссовки и получить назад деньги, чтобы купить другие. Улавливаете разницу? Это сдвиг от формального набора функций к человеческим потребностям. Попробуйте прямо сейчас отложить книгу и вспомните свой последний диалог с какой-нибудь службой поддержки. Что двигало вами? Скорее всего, не абстрактное желание «взаимодействовать с системой», а вполне конкретная эмоциональная или практическая потребность.
Интенты: добываем алмазы из груд слов