Дизайн диалогов чат-бота: сценарии, ошибки и метрики

Чат-бот почти никогда не ломается на уровне кода. Он ломается на третьей реплике: человек написал «а если мне надо в субботу?», бот ответил «Я вас не понял, выберите пункт меню», и разговор закончился. Человек закрыл окно и позвонил в поддержку — ровно туда, куда бот должен был его не пустить. Проблема здесь не в нейросети и не в платформе, а в том, что диалог никто не проектировал: были кнопки, тексты приветствия и надежда, что люди будут писать предсказуемо.

Дизайн диалогов — это такая же работа UX-дизайнера, как проектирование формы или навигации, только интерфейс здесь состоит из реплик. Его делают до разработки и передают инженерам вместе со схемой сценариев, текстами и правилами обработки ошибок. Если бота делает подрядчик, разумно заказать разработку чат-бота вместе со сценариями диалогов, а не только «подключение к Telegram»: так за реплики, ветки и тупики отвечает та же команда, что пишет код, и схема не теряется между дизайнером и разработчиком.

Ниже — процесс от сбора намерений до разбора логов после запуска, а в конце — пример, таблица ошибок и чек-лист.

Что такое дизайн диалогов чат-бота?

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

Термин часто смешивают с оформлением окна чата. Разница практическая: от неё зависит, кто что делает в команде.

Слой	Что в нём	Кто отвечает
Диалоговый UX	Задачи, намерения, логика веток, ошибки, передача оператору	UX-дизайнер или conversation designer
UX-тексты	Формулировки реплик, тон, длина сообщений, подсказки	UX-писатель, редактор
Диалоговый UI	Окно чата, пузыри, кнопки, карусели, индикатор набора	UI-дизайнер
Логика и интеграции	Распознавание намерений, запросы в CRM и базы, хранение контекста	Разработчики

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

Когда чат-бот не нужен?

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

• Задача многошаговая, но шаги зависят от ответов. Подбор тарифа, диагностика неисправности, запись к нужному специалисту — да. Ввод адреса доставки из пяти полей — нет, это форма.
• Люди формулируют вопрос своими словами. Если запросы разнообразны («не приходит смс», «код не работает», «не могу войти»), бот с распознаванием намерений полезен. Если выбор всегда из трёх вариантов, хватит трёх кнопок на странице.
• Канал уже разговорный. Мессенджер, виджет поддержки, голосовой ассистент — там человек и так пишет сообщения.
• Есть данные, чтобы ответить по существу. Бот без доступа к статусу заказа или расписанию может только пересказывать FAQ и злить.
• Есть человек на подхвате. Сложные и эмоциональные случаи бот должен уметь передать оператору — без этого его лучше не запускать.

Если по трём-четырём пунктам ответ «нет», сначала улучшите форму или справочный раздел. Как сделать форму, которую не бросают на середине, мы разбирали в материале о UX форм.

Как задать персону бота и тон общения?

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

Параметр персоны	Вопрос	Пример решения
Роль	Кем бот выступает в разговоре	Администратор клиники, а не «умный помощник обо всём»
Обращение	«Вы» или «ты», по имени или нет	«Вы», имя — только если человек сам его указал
Длина реплики	Сколько текста в одном сообщении	1–2 предложения, длинное — разбить на два сообщения
Юмор и эмодзи	Где допустимы	В приветствии — можно, в ошибке оплаты и жалобе — никогда
Словарь	Какие слова использовать и запрещать	«Запись», а не «бронирование слота»; без внутренних кодов статусов

Не делайте бота «почти человеком». Имя и характер допустимы, но человек должен понимать, что говорит с программой, — иначе он ждёт понимания контекста, которого у бота нет, и разочарование сильнее. В Евросоюзе с августа 2026 года это ещё и требование AI Act: пользователя нужно уведомлять, что он общается с системой ИИ.

Как спроектировать диалог чат-бота: пошаговый процесс

Диалог чат-бота проектируют в семь шагов: от целей и намерений пользователей до разбора логов после запуска. Процесс одинаков для бота поддержки, продаж и внутреннего помощника; между шагами 3 и 6 обычно бывает две-три итерации.

1. Цели бота и бизнеса. Какие задачи бот закрывает и какой результат считается успехом: запись создана, статус выдан, заявка передана.
2. Намерения пользователей. Список того, зачем люди пишут, с примерами формулировок из реальных обращений.
3. Основной путь. Идеальная последовательность реплик для каждого главного намерения.
4. Граничные случаи. Неверный ввод, нехватка данных, смена темы посреди сценария, отказ.
5. Тексты реплик. Формулировки по персоне, подсказки, варианты кнопок.
6. Прототип и тест. Проверка на людях до разработки — хотя бы в формате «человек играет бота».
7. Запуск и разбор логов. Чтение реальных переписок, доработка веток и словаря.

Как собрать намерения пользователей

Намерения собирают из того, что люди уже пишут и говорят: чаты поддержки, записи звонков, письма, поисковые запросы по сайту. Выгрузите 200–500 обращений, разметьте их по задачам и посчитайте частоту. Обычно небольшая часть намерений даёт основную массу обращений — с них и начинают. Для каждого намерения сохраните 10–20 реальных формулировок: они понадобятся и для обучения распознавания, и для тестов.

Как построить основной путь

Основной путь (happy path) — самый короткий разговор, который приводит человека к цели. Запишите его как сценарий пьесы: реплика бота, ответ пользователя, следующая реплика. Затем сократите. Каждый вопрос бота должен быть нужен для результата: если дату можно взять из контекста, а филиал — из геолокации, не спрашивайте их. Хорошая планка — главная задача решается за 3–5 обменов репликами.

Как найти граничные случаи

Для каждого шага основного пути задайте четыре вопроса: что, если человек ответит не то, что ждали; что, если у него нет нужных данных; что, если он сменит тему; что, если передумает. Ответы на них и становятся ветками схемы. Их удобно рисовать в FigJam, Miro или специализированных конструкторах вроде Voiceflow: главное, чтобы схема была одна и её видели и дизайнеры, и разработчики.

На каких принципах строится хороший диалог?

Хороший диалог строится на кооперативном принципе философа Пола Грайса (1975). Грайс описал, чего собеседники неявно ждут друг от друга, и эти четыре максимы хорошо переводятся в правила для реплик бота.

Максима	Суть	Как применить в боте
Количество	Сообщать столько, сколько нужно, — не больше и не меньше	Не вываливать все условия тарифа; дать главное и предложить «подробнее»
Качество	Говорить правду и то, в чём уверен	Не обещать «оператор ответит через минуту», если очередь неизвестна
Релевантность	Говорить по теме разговора	Не вставлять рекламу акции в ответ на жалобу
Ясность	Говорить понятно, однозначно, по порядку	Один вопрос в одной реплике; без двойных отрицаний и внутренних терминов

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

Кнопки или свободный ввод: что выбрать?

Кнопки выбирают, когда вариантов мало и они известны заранее; свободный ввод — когда ответ уникален или вариантов слишком много. Чаще всего работает смешанная схема: кнопки как подсказка, но текст тоже принимается.

Ситуация	Лучше	Почему
2–5 известных вариантов	Кнопки	Быстрее, нет ошибок распознавания
Дата и время	Кнопки с ближайшими слотами + ввод	Большинство берёт ближайшее, остальным нужна свобода
Имя, адрес, номер заказа	Свободный ввод с проверкой формата	Вариантов бесконечно много
Описание проблемы	Свободный ввод	Формулировки человека — материал для распознавания и оператора
Подтверждение действия	Кнопки «Да» / «Изменить»	Однозначный ответ перед необратимым шагом

Две частые ошибки с кнопками. Первая — кнопки исчезают после нажатия, и человек не может вернуться к выбору. Вторая — бот принимает только нажатие и отвечает «Выберите вариант из списка» на текст, совпадающий с надписью кнопки. Если человек написал «завтра», а кнопка называется «Завтра», это одно и то же. Состояния кнопок — активная, нажатая, недоступная — описывайте так же подробно, как для любого компонента; полезен наш чек-лист состояний компонентов.

Как обрабатывать ошибки и передавать разговор оператору?

Ошибку бот обрабатывает ступенчато: сначала переспрашивает конкретнее, затем предлагает варианты, на третьей неудаче передаёт разговор человеку. Фраза «Я вас не понял» без продолжения — тупик, а тупики — одна из самых частых причин, по которым люди бросают ботов и уходят звонить.

1. Первая неудача — уточнение. «Не уверен, что правильно понял. Вы хотите перенести запись или отменить её?» Бот показывает, что слышал, и сужает выбор.
2. Вторая неудача — варианты. «Могу помочь с записью, ценами и адресами филиалов. Что из этого?» плюс кнопки.
3. Третья неудача — человек. «Передаю разговор администратору — он увидит нашу переписку». Без повторного вопроса «Что у вас случилось?».

Передача оператору — отдельный сценарий, а не кнопка «Позвать человека». Оператор должен получить историю диалога и уже собранные данные, человек — понять, сколько ждать и что будет, если сейчас нерабочее время. Немедленно, без попыток уточнить, передавайте разговор в трёх случаях:

• признаки раздражения: «это бесполезно», мат, повтор одного и того же вопроса;
• упоминание денег, которые списались по ошибке;
• запросы, связанные со здоровьем или безопасностью.

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

Сценарный бот или LLM-ассистент: что меняется в дизайне?

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

Аспект	Сценарный бот	LLM-ассистент
Реплики	Написаны заранее	Генерируются; дизайнер пишет инструкции и примеры
Понимание ввода	Только обученные намерения	Почти любые формулировки
Главный риск	Тупики и «не понял»	Уверенные неверные ответы и выход за рамки темы
Что проектировать	Схему веток и тексты	Границы темы, обязательные шаги, источники ответов, отказы
Тестирование	Прогон веток	Наборы проверочных вопросов, включая провокационные

На практике лучше всего работает гибрид. Критичные шаги — оплата, запись, изменение данных, юридически значимые формулировки — идут по жёсткому сценарию с подтверждением. Свободные вопросы обрабатывает модель, которая отвечает только по проверенной базе знаний и честно говорит «не знаю», если ответа там нет. Дизайнер отвечает за то, где проходит граница между этими режимами и как человек её замечает. О том, как ИИ меняет саму работу дизайнера, мы писали в материале про ИИ в рабочем процессе дизайнера.

Как сделать чат-бот доступным?

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

• Объявление новых сообщений. Лента сообщений размечается ролью log или областью aria-live="polite", чтобы новые реплики зачитывались, не перебивая пользователя. Подробности — в спецификации WAI-ARIA о роли log.
• Управление с клавиатуры. Поле ввода, кнопки-ответы и закрытие окна доступны по Tab, фокус не теряется после отправки сообщения и виден.
• Контраст и масштаб. Пузыри бота и пользователя различаются не только цветом, текст читается при увеличении до 200 %. Требования к контрасту и фокусу мы собрали в разборе WCAG 2.2.
• Без таймаутов. Сценарий не сбрасывается, если человек отвечает медленно.
• Альтернатива. Рядом с ботом есть телефон или форма для тех, кому чат неудобен.

Какие метрики показывают качество диалогов?

Качество бота измеряют по тому, решил ли он задачу человека, а не по числу сообщений. Число диалогов растёт и тогда, когда бот плохо понимает людей, — они просто переспрашивают.

Метрика	Что показывает	Как читать
Доля завершённых сценариев	Сколько диалогов дошли до цели	Смотрите по каждому намерению отдельно, а не в среднем
Доля fallback	Как часто бот не понял ввод	Рост после запуска новой темы — сигнал, что не хватает формулировок
Доля передач оператору	Сколько разговоров ушло человеку	Низкая — не всегда хорошо: возможно, людям не дают выйти
Точка ухода	На какой реплике люди бросают диалог	Самый полезный диагностический сигнал для доработки веток
Оценка после диалога	Субъективная удовлетворённость	Короткий вопрос с оценкой, без длинных анкет
Повторное обращение	Вернулся ли человек с той же проблемой	Если да, бот «закрыл» диалог, но не задачу

Цифры показывают, где проблема, а логи — почему. Раз в неделю читайте выборку реальных переписок, особенно с fallback и уходами. Как связать такие показатели с общими UX-метриками продукта, мы разбирали в статье про SUS и HEART.

Пример: бот записи в сервисный центр

Разберём процесс на условном примере — цифры в нём иллюстративные. Сеть сервисных центров запускает бота в мессенджере, чтобы разгрузить телефон. Первая версия состояла из меню на шесть кнопок и не понимала текст.

Что показал разбор обращений

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

Что изменили в сценариях

Статус ремонта стал первым сценарием: номер заказа или телефон → ответ из учётной системы → срок и следующий шаг. Запись свели к трём обменам: модель устройства свободным текстом, ближайшие слоты кнопками, подтверждение. Жалобы бот не обрабатывает — он сразу передаёт их администратору вместе с номером заказа. На прототипе в формате «сотрудник играет бота» с восемью клиентами выяснилось, что слово «диагностика» путают с платным ремонтом; в репликах добавили «бесплатно, 20 минут».

Итог через месяц: доля завершённых сценариев по статусу ремонта — 78 %, fallback упал с 34 % до 11 %, звонков с вопросом «готово ли» стало заметно меньше. Слабое место осталось одно — запись на выходные, где слотов мало; туда добавили предложение оставить контакт для обратного звонка.

Какие ошибки чаще всего ломают диалог?

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

Ошибка	Чем вредит	Как исправить
Меню вместо разговора	Бот не понимает текст, люди уходят	Принимать свободный ввод хотя бы для главных намерений
«Я вас не понял» без продолжения	Тупик и звонок в поддержку	Ступенчатый fallback и передача человеку
Простыня текста в одной реплике	Не дочитывают, теряют вопрос	1–2 предложения, вопрос — в конце сообщения
Несколько вопросов сразу	Человек отвечает только на один	Один вопрос — одна реплика
Нельзя вернуться назад	Ошибку в шаге исправляют только заново	Команды «назад», «изменить», «начать сначала»
Оператор спрашивает всё заново	Раздражение, двойная работа	Передавать историю и собранные данные
Бот изображает человека	Завышенные ожидания и недоверие	Сразу сказать, что это бот и что он умеет
Схема только в голове разработчика	Ветки расходятся с текстами, правки ломают логику	Одна общая схема диалога для всей команды

Чек-лист дизайна диалогов

Пройдите по списку до разработки и ещё раз перед запуском.

1. Определены задачи бота и критерий успеха для каждой.
2. Намерения собраны из реальных обращений, у каждого есть 10–20 формулировок.
3. Описаны персона бота и персона пользователя, тон закреплён примерами.
4. Для каждого главного намерения есть основной путь не длиннее 3–5 обменов.
5. У каждого шага описаны неверный ввод, нехватка данных, смена темы и отказ.
6. Первая реплика объясняет, что бот умеет и что это бот.
7. Кнопки дублируются текстом и не исчезают после выбора.
8. Есть ступенчатый fallback и сценарий передачи оператору с историей.
9. Перед необратимым действием бот просит подтверждение.
10. Окно чата доступно с клавиатуры и для программ экранного доступа.
11. Прототип проверен на людях до разработки.
12. Настроены метрики завершения, fallback, передач и точек ухода, назначено регулярное чтение логов.

Прототип диалога проверяют так же, как любой интерфейс: несколько сессий с реальными пользователями находят большую часть грубых проблем. Как спланировать такую проверку и где её пределы, — в нашей статье о юзабилити-тесте на пяти пользователях. Обзор исследований поведения людей в чат-ботах есть у Nielsen Norman Group.