Привет, Хабр! Меня зовут Юля, и я дизайнер диалоговых интерфейсов в команде Just AI. В своей работе мы часто сталкиваемся с ситуацией, когда после согласования работ с заказчиком, тот изъявляет желание сиюминутно приступать к написанию кода, чтобы ускорить процесс создания бота. Спойлер: только в исключительных случаях такой порыв не приводит к увеличению сроков готовности бота и расхождению ожиданий и реальности.
После того, как вы с заказчиком уже решили, что ему нужен чат-бот, важно правильно спланировать процесс разработки, чтобы не мучиться вопросом «С чего начать?». Поэтому после получения первичного технического задания для бота любого типа, будь то текстовые боты, виртуальные ассистенты, IVR или обзвоны, мы приступаем к проектированию — созданию дизайна будущей диалоговой системы.
В этой статье я расскажу о том, какая ответственность возложена на этап дизайна, как сценарий бота помогает в процессе разработки, о принципах эффективной сценарной работы и о подводных камнях подхода «проектирую сразу в коде».
Что понимается под дизайном в «прикладном» смысле?
Проектированием ботов любого типа занимается дизайнер диалоговых интерфейсов. У этой профессии много названий: скриптолог, архитектор разговорных решений, CUI/CUX-редактор и др. К навыкам специалиста данного профиля относятся: моделирование эффективного сценария диалога, прогнозирование happy path и отступлений от него, выявление пользовательских потребностей, проработка персоналии бота и Tone of Voice, написание гармонично звучащих реплик, анализ вариаций человеческих запросов. При необходимости дизайнер также берет на себя коммуникацию с заказчиком для уточнения требований к боту, анализа пользовательских логов после публикации решения в продакшн или разметки синтеза, если речь идет о голосовом интерфейсе.
Проектирование сценария
Первым шагом в проектировании сценария является создание high-level design (HLD). Чаще всего это схема с отображением входа и выхода из диалога, ключевых сценарных веток и обращений к внешним системам. Ее наличие не обязательно, если бот совсем небольшой и не использует API-методы. Однако сделав подобную верхнеуровневую «заготовку», гораздо проще переходить к low-level design (LLD), который подразумевает максимальную степень детализации.
Все артефакты этапа проектирования дизайнер бота помещает в «сценарную папку» — выделенное пространство для хранения проектной документации. Именно дизайнер впоследствии следит за актуализацией папки и документов в ней, соответствии того, что прописано в сценарии и коде. Содержимое папки понимается под словом «дизайн» в коммуникации проектной команды.
В сценарной папке хранится:
HLD-схема флоу диалога (при наличии);
LLD, содержащий конечные формулировки реплик бота, запросы пользователей, которые бот отрабатывает, все сюжетные переходы и реакции, обработчики ошибок и событий, логику обращений к внешним системам;
Детальное описание ToV и личности бота (при наличии);
Диаграмма sequence, содержащая информацию о взаимодействии внутренних компонентов диалоговой системы с внешними сервисами (при наличии);
Документации для обращения к внешним сервисам (при наличии);
Мультимедиа-контент — изображения, аудио, видео и др.(при наличии).
Какие задачи помогает решить дизайн бота?
Помимо задействования во всех этапах цикла создания бота, LLD помогает решить несколько важных для налаживания процессов задач:
-
Визуализировать ожидания заказчика и концепцию разработки. Если техническое задание не подробное, и клиент формулирует достаточно размытые требования а-ля «хочется, чтобы бот был умным» — без проработки дизайна не обойтись.
Обозначить границы скоупа работ. При согласовании сценария обязательно нужно транслировать мысль о том, что не все описанное в LLD будет реализовано на момент передачи бота и, к примеру, уйдет в технический долг.
Декомпозировать задачи. Гораздо легче заниматься долгосрочным планированием, если есть от чего отталкиваться. Глядя на сценарий, ощущается скоуп работ, становится понятно, как можно скомпоновать задачи, что можно взять в первую очередь. В план-графике проекта отдельным этапом может стать разработка, тестирование и правки после тестирования для отдельной сценарной ветки.
Тестировать бота. В тестировании сценарий будет выступать в качестве эталона работы бота.
Проводить UX-исследования. Если целевая аудитория будущего бота недостаточно изучена, а для создания прототипа нет нужных специалистов или дополнительного бюджета, LLD может стать основой для проведения исследований. Но это требует тщательной проработки онбординга в дизайн-документ и заданий для респондентов.
На каких этапах впоследствии будет необходим дизайн бота?
Если вам кажется, что, разработав сценарий и сложив его в папку, CUI-дизайнер говорит что-то вроде «На этом мои полномочия всё», то спешу заверить, что это совсем не так. Ведь детализированная версия сценария необходима на каждом этапе создания бота:
Презентация сценария. Сценарист представляет результаты своей работы заказчику, при необходимости поясняя, почему планируется реализовать именно так — ради лучшего пользовательского опыта, с целью экономии времени, для гарантии получения нужных данных от пользователей и др. Каждая договоренность фиксируется в сценарии во избежание расхождений в ожиданиях на этапе приемки бота;
Реализация. После того, как сценарий согласован, дизайнер передает его разработчикам;
Тестирование. Проверяя работоспособность, QA опирается исключительно на сценарий, ведь в нем прописано эталонное поведение бота;
Презентация готового решения. Так как сценарий перед передачей в разработку проходит этап детального согласования с заказчиком, приемка разработанного функционала будет строиться по нему. Каждая деталь, отраженная в сценарии бота, при несовпадении с готовым решением может стать иллюстрацией «ожидаемого результата» в баге;
Разбор логов. По факту вывода бота в продакшн начинается этап анализа пользовательских диалогов. Для того, чтобы определить, верно ли отработал бот, и разделить проблемные логи на баги и возможные улучшения, требуется зафиксированный сценарий;
Проектирование доработок. Как только выделены пользовательские запросы, которые бот должен отрабатывать, дизайнер может брать в работу проектирование сценария по ним. Так начинается новый цикл разработки.
Важно помнить, что бот — это настоящая экосистема, «жизнь» в которой нужно беспрерывно поддерживать. Если не дообучать бота, не расширять его базу знаний, не добавлять реакции на вопросы вне изначального сценария, он рано или поздно перестанет быть полезным для пользователей.
Что будет, если разрабатывать без сценария?
Практика показывает, что в качестве ответа на этот вопрос можно использовать поговорку про «вставлять палки в колеса».
Отсутствие зафиксированного скоупа работ влечет за собой новые неучтенные на старте требования к результату. Всплыть они могут на любом из этапов, даже (и чаще всего) на финальной приемке.
Если попробовать заменить детальный сценарий и анализ требований кратким техническим заданием от клиента, есть риск, что вам придется несколько раз составлять список вопросов для заказчика и транслировать ответы команде.
Что-то получится выяснить в переписке путем многократных уточнений, что-то придется обсуждать устно. Представьте количество участников процесса, пингов друг друга, часов созвонов, сообщений в чатах и фоллоу-апов, а потом ответьте на вопрос: «А стоит ли оно того?».
Не исключена ситуация, когда вы сходу разработали бота, и он, на ваш взгляд, работает довольно неплохо. Тестировщику тоже все понравилось. А вот на финальной демонстрации заказчику готового решения оказалось, что бот общается на «вы», а нужно на «ты», не слишком дружелюбен по мнению принимающей стороны, о бренде рассказывает мало и не использует фирменный слоган. Несоответствие разработанного Tone of Voice желаемой трансляции бренда — еще один весомый риск реализации без сценария. Возможно, заказчик без какого-либо прототипа вообще не догадывался, что его будущему боту нужна проработанная личность со своей легендой и речевыми особенностями. Такая переработка бота займет много времени.
Еще хотелось бы уточнить, что баг, найденный на этапе согласования сценария, всегда дешевле исправить, нежели баг, найденный на этапе тестирования готового кода. Ведь для его исправления задействуется исключительно дизайнер, а не дизайнер, разработчик и тестировщик. Попытка сэкономить на сокращении этапов работ зачастую оборачивается не очень приятными последствиями в виде множественных итераций процессов.
К успеху шли
Чтобы советы и «предостережения» не звучали голословно, приведу несколько реальных примеров пропуска этапа сценария из нашего опыта. Несмотря на обезличенность, менее говорящими они не становятся.
Проект №1
На старте все было довольно складно — разработчик в гордом одиночестве посещал созвоны с заказчиками, и имелась верхнеуровневая схема функционала бота, которая поддерживалась в актуальном состоянии. Тогда казалось, что отрисовывать детальный сценарий нет смысла, ведь разработчик все держал в голове, а общие принципы были отражены на HLD. Но проект не может бесконечно центрироваться на одном человеке и, когда дело дошло до передачи поддержки бота новым, непосвященным сотрудникам, появились первые трудности. Разработчики пытались осознать, какой функционал в боте есть, и куда именно нужно встроить ту или иную доработку, а тестировщики постоянно задавались вопросами «Точно ли так должно быть?». Полноценная документация помогла бы подключающимся специалистам чувствовать себя увереннее и меньше времени тратить на понимание того, как все устроено.Проект №2
У нас был полноценный сценарий, но новые фичи туда добавлялись сперва в режиме демки. Разработали MVP по краткому техническому заданию сразу в коде, и тут же в продакшн. Вроде все уже готово, можно ничего больше не фиксировать. Но впоследствии оказалось, что в задачи по расширению и правкам нового функционала могут сходу вникнуть только задействованные в его разработке люди. Или же придется уже на этапе доработок согласовывать актуализацию сценария и время на онбординг других сотрудников. А если бы кто-то из владеющих тайным знанием ушел в отпуск? Пришлось «отрисовывать» детальный сценарий по уже созданному функционалу, иначе делегировать задачи без подготовки и дополнительных трудозатрат не представлялось возможным.Проект №3
Довольно болезненный кейс, судя по воспоминаниям всех участников процесса. Видение заказчиком результата постоянно менялось в процессе коммуникации, а призывы остановить работы, пока не будет сформирован сценарий, не были услышаны. Все детали обсуждались внутри телеграм-чата и больше нигде не фиксировались. Разработчики были вынуждены постоянно следить за ходом беседы, чтобы не пропустить решение по очередному непроясненному вопросу. Разработка проходила очень медленно, многое приходилось переделывать. Общий вывод — «если бы был согласованный и актуальный сценарий, все было бы намного проще».
Можно ли параллельно заниматься сценарием и разработкой?
Кажется, что пытаться создавать и то, и другое одновременно — довольно бессмысленно: двойные трудозатраты на «придумывание», внесение правок сразу и в сценарий, и в код. Однако можно попробовать «есть слона по частям». Если предполагается сложный древовидный сценарий с множеством сюжетных веток, лучше разделить создание сценария на этапы: общий «костяк», ветка №1, ветка №2 и т.д. За каждым спроектированным куском следует процедура согласования с людьми, ответственными за постановку задачи. Как только кусочек сценария согласован, смело можно заниматься его реализацией. Такая декомпозиция приблизит срок сдачи проекта и позволит быстрее задействовать всю проектную команду.
Когда все-таки можно сразу в код?
Хотелось бы ответить «никогда» на этот вопрос :) Но, как уже упоминалось выше, возможны исключения. Допустимо обойти этап проектирования в том случае, если для будущего проекта справедливы следующие утверждения:
У проекта есть подробное, однозначно сформулированное ТЗ;
Горящие сроки («сегодня-завтра хорошо бы отдать»);
Неограниченный бюджет — ведь исправление сценарных багов в уже готовом боте это дорогое удовольствие;
Планируется минимальное количество сюжетных веток: линейный сценарий или FAQ-бот без уточняющих вопросов;
Проект никогда не дойдет до реальной аудитории или дойдет только в виде демонстрационного решения;
Дальнейшее развитие проекта не предусматривается.
Альтернатива кода — графические редакторы
Если дизайнер привык работать с визуальными платформами для создания схем, он может попробовать использовать для создания сценария графический редактор, например, J-Graph в JAICP или Aimylogic. Но нужно учитывать, что:
Выбранный графический редактор может обладать техническими ограничениями на функционал, который можно с помощью него реализовать. Стоит заранее удостовериться, что требования соответствуют возможностям платформы;
Дизайнер может не обладать всеми навыками разработчика, но в таком случае за этапом проектирования в любом случае будет следовать этап реализации, где разработчик или несколько разработчиков валидируют спроектированное и дополняют код;
Возможна ситуация, что согласованный LLD в процессе разработки зрительно изменится. В этом случае рекомендуется дополнительно фиксировать его после согласования в виде скриншота и/или дублировать отдельным проектом, в который не будут вноситься изменения. В сценарную папку, в таком случае, будут сохраняться данные о его размещении. Так всегда можно будет обратиться к изначальному виду дизайна.
Заключение: принципы эффективной сценарной работы
Наличие заранее спроектированного сценария действительно облегчает жизнь проектной команды и делает более продуманным будущий разговорный интерфейс с точки зрения пользовательского опыта. В качестве заключения хотелось бы сформулировать следующие принципы эффективной работы с дизайном бота:
Начинать разработку только после согласования сценария. Или хотя бы делить его на кусочки: спроектировали - согласовали - разработали - протестировали;
Выбирать для LLD удобную и заказчику, и проектной команде степень детализации. К примеру, всю скриптовую логику описываем текстом, а разработчик уже сам выбирает и задает названия переменных;
Использовать удобный для погружения формат. Сценарист может быть занят на нескольких проектах, поэтому продумайте возможность передачи задач по внесению небольших правок в дизайн решения;
Заполнять «сценарную папку». Все документации и контентные составляющие сложены в эту папку или прикреплены в виде ссылок, чтобы у тестировщиков проекта всегда был к ним доступ для проверки;
Поддерживать актуальность сценария. Если в код внесли правку, пусть даже минорную, необходимо отразить в LLD. Стоит подумать над грамотным распределением обязанностей в таких случаях: к примеру, какие сценарные правки может отразить сам разработчик в ходе изменения кода, а ради каких будет дергать дизайнера. Папка тоже должна быть в актуальном состоянии: ссылки валидны, все документы актуальны, поддерживаемы и применяемы на проекте (или помечены словом «архив» в названии, если уже не актуальны, но сохранить хочется);
Версионировать дизайн. Любые внесенные изменения стоит помечать для других участников процесса: выделять цветом, прикреплять стикеры, оставлять примечания и др. Так проектная команда будет понимать, что изменилось и что нужно брать в работу. Выбирать инструмент для проектирования стоит также с оглядкой на версионирование;
Выделять легенду и обозначения. Этот принцип также относится к облегчению онбординга в сценарий бота. Если в документе есть внутренние обозначения, всегда стоит выносить их в отдельный блок с легендой;
Выдавать доступы. Данному процессу также следует уделять особое внимание и проверять, что у всех участников процесса есть доступ к сценарию, и их права соответствуют требуемым. Например, не стоит «разбрасываться» доступами на редактирование, особенно, если откатиться к предыдущей версии дизайна сложновато. При этом доступ на комментирование зачастую довольно удачен для заметок со стороны заказчика или разработки: можно оставить примечание к нужному куску функционала, не описывая дополнительно, какой фрагмент сценария имелся в виду.