Aimylogic
В2В
Web
Редизайн
Полный цикл
Увеличила количество созданных ботов в 7 раз
Переработала основной сценарий создания бота в сервисе, который помогает малому бизнесу и начинающим энтузиастам разрабатывать, запускать и поддерживать простых ботов.
Роль:
Product Designer
Дизайн-команда:
1 Product Designer, 1 Product Manager, 1 Product Marketing Manager
Длительность:
~6 месяцев, включая разработку
Вводные
Aimylogic — это no-code платформа, в которой пользователи без технического бэкграунда и специальных знаний могут создавать ботов. Есть два пути: разрабатывать сценарий бота сразу в визуальном Конструкторе или начать с готовых Шаблон-форм, где достаточно заполнить несколько полей и система сама сгенерирует сценарий бота в Конструкторе.
Компания заметила, что продукт не отрабатывает свою основную задачу. Ко мне пришли с запросом разобраться в ситуации и предложить решение проблемы. Был дан карт-бланш, а значит возможность провести проект по полному UX-циклу.
Макеты
Продукт
Проблема
Количество регистраций сильно превышает количество созданных ботов, высокий показатель отказов.
Задача
Выявить причины низкой активации продукта, предложить и спроектировать решение.
Решение
Провести исследования и на основе полученных данных провести редизайн ключевого флоу.
Шаг 1. Первичное исследование
Для начала я проанализировала продукт с точки зрения пользователя и технических нюансов его работы.
Уже на этом этапе стали понятны сложности, с которыми сталкиваются пользователи:
Шаблон-формы были слишком негибкие, не показывали часть настроек и вели себя непредсказуемо;
визуальный Конструктор в принципе настолько путаный, что невозможно сориентироваться даже визуально, не говоря уже о специфической лексике, которую наша ЦА не знает.
Было принято решение в текущем проекте не рассматривать Конструктор, и переиспользовать облегченную версию из родственного продукта JAICP (профессиональная платформа для создания ботов).
Таким образом, я сконцентрировалась на альтернативном пути: поиск максимально no-code решения.
Цели исследования:
1.
Сформировать гипотезы о целевой аудитории и её взаимодействии
с продуктом.
2.
Выявить ключевые проблемные точки
в текущем интерфейсе.
3.
Изучить техническую основу.
Методология:
Анализ сценариев создания первого бота.
Углубленное изучение конструктора JAICP, т.к. создание ботов любым способом, кроме написания кода, ограничивается возможностями Конструктора.
Экспертная оценка пользовательского пути (first-time user experience).
Результаты:
Сформировала требования к респондентам для UX-исследования.
Сформировала гипотезы для UX-исследования.
Спроектировала UX-исследование с пользователями.
Определила ключевую ЦА
Для дальнейшей работы выбрали платежеспособных клиентов. Гипотезы о ЦА проверили при отборе респондентов и на интервью.
Кто
Владельцы малого бизнеса (локальные интернет-магазины, сервисные компании).
Зачем им бот
Автоматизация рутинных коммуникаций с клиентами для экономии ресурсов компании (человеческих и финансовых) и улучшение клиентского сервиса.
Особенности:
Нет выделенного специалиста под разработку ботов, наем — дорог,
Отсутствие специальных знаний и не готовы глубоко изучать сложные инструменты,
Если в первые минуты интерфейс кажется непонятным, отказываются от дальнейшего погружения.
Шаг 2: UX-исследование с пользователями
Мы подобрали респондентов, соответствующих нашей ЦА и провели UX-тестирование интерфейса с небольшим интервью в начале. Главное было понять, как люди думают, как видят ботов и их создание. Иными словами моя задача была не столько в том, чтобы вычислить проблемы интерфейса, сколько понять ментальную карту процесса в голове пользователя. Если сфокусироваться только на существующем интерфейсе и его проблемах, можно бесконечно улучшать изначально неработающую систему.
Основные выводы
Непонятный Конструктор
Завершение настройки Шаблона Конструктором оказалось внезапным для респондентов. Пользователи мгновенно терялись в интерфейсе. Практически никто не попытался разобраться.
Негативные эмоции
На всем пути у респондентов преобладали растерянность, разочарование и фрустрация, многие готовы были бросить прохождение сценария уже на шаге Тестирование.
Не соответствует бизнесу
Набор и настройки Шаблонов не имеют ничего общего
с реальными бизнес-задачами пользователей.
Требует навыка письма
Диалоговая речь и письменная имеют принципиальные отличия: хорошо написанный текст в поле ввода воспринимается как плохо сформулированный в виде реплики бота. К тому же переключение между шагами срабатывает
как “маска”, респонденты забывали формулировки, пока возвращались к форме.
Очеловечивание
Люди склонны немного очеловечивать ботов и системы: реагируют и говорят в терминах человеческого поведения, особенно, когда злятся. (Не удивительно, лишний раз подтвердилось).
Непредсказуемое поведение
В Шаблоны выведена лишь часть настроек, поэтому респонеденты недоумевали, когда бот начинал незапланированные сценарии. Если эти сценарии воспринимались как лишние, респонденты не понимали, как их отключить.
Нет гибкости
Жесткая структура Шаблонов, подходят для специфических ситуаций и задач. Настройки нельзя убрать или добавить.
Пугающие ограничения
Большинство респондентов останавливались на шаге Подключение, боясь пройти дальше и потерять весь прогресс. Они воспринимали подключение бота в виде чат-виджета на сайт как обязательный шаг сценария. При этом их смущало отсутствие возможности подключить бота к другим каналам, например, Telegram.
Цели исследования:
Проверить гипотезы о поведении и ожиданиях целевой аудитории:
1.
Как пользователи представляют процесс создания бота?
2.
Какие задачи они хотят решить с его помощью?
3.
Какие сложности возникают при работе с текущим интерфейсом?
4.
Какие факторы влияют на решение продолжить или отказаться от использования продукта?
Методология:
Дистанционные полуструктурированные интервью с модерируемым UX-тестированием (screen sharing).
Участники: действующие и потенциальные пользователи Aimylogic, 14 человек.
Анализ данных:
частотный анализ проблем и болевых точек,
фиксация эмоциональных реакций и когнитивного напряжения,
группировка данных по пользовательским сценариям (а не по структуре системы).
Результаты:
Подтверждены основные гипотезы о проблемах интерфейса.
Сформирован список из ~180 конкретных проблем и инсайтов.
Полученные данные легли в основу переработки концепции продукта.
Шаг 3: Разработка концепции
На исследовании подтвердилось: наша ЦА — очень занятые люди, которые не могут себе позволить потратить кучу времени и сил, разбираясь в нюансах разработки ботов. И нуждаются они преимущественно в ботах с конкретными задачами: отвечать на вопросы клиентов, оформлять заказы, собирать лиды. Нужно было что-то максимально no-code.
Идея Шаблонов соответствовала запросу, но являла собой сложную логическую конструкцию, потому что шаблон предполагает закрытие целого пула задач. Например, «Бот для банка» должен покрывать сразу множество всего в непредсказуемой комбинации: рассказывать о банке, предлагать кредиты, помогать оформлять карты, отслеживать операции по счету, помогать переводить деньги, etc etc.
Концепция, на которой в итоге остановилась, родилась из двух идей. Во-первых, в дизайне есть метод диалогового проектирования, когда два человека разыгрывают взаимодействие с продуктом по ролям: один играет пользователя, а второй — систему. Во-вторых, людям свойственно очеловечивать объекты неживого мира, тем более, когда с ними можно взаимодействовать. То есть для многих пользователей бот — это своего рода персонаж из игры, у которого есть базовые и настраиваемые параметры.
На черновых набросках макетов идея бота как персонажа показала себя самой жизнеспособной, поэтому выбрала ее. У бота-персонажа появились базовые параметры как, например, Приветствие и Прощание. Основные запросы бизнеса разбила на обособленные Навыки, т.е. что бот будет уметь делать: Отвечать на вопросы клиентов, Собирать контакты, помогать оформлять заказы etc. Человек сможет комбинировать их так, как надо ему.
Немного первых набросков
По итогу определили ограничения и возможности: отказалась от вариантов, требующих слишком большой проработки логики и потому рискующих оказаться столь же неудобными, как Шаблоны. Поэтому остановилась на простом варианте: предложить человеку самому выбрать из существующего набора навыков те и так, как это нужно ему.
Иногда не стремящийся быть слишком умным вариант оказывается самым гибким и понятным 😊
Шаг 4: Проектирование и UX валидация
Сначала с продактом сформировали набор Навыков, которые попадут в первую итерацию.
Исходя из плана тестирования определили набор и содержимое Навыков, с которых начну проработку. Так как запланировала RITE, необходимо было отрисовать и запрототипировать весь флоу «Первой сессии пользователя» от начала до конца.
Процесс создания бота разбила на шаги: выбрать навыки — настроить каждый навык — подключить бота к каналу (по желанию пользователя) — завершить создание (переход на информационную страницу о боте).
Поскольку одна из самых сложных задач для человека — корректно формулировать реплики бота, было крайне важно дать быстрый доступ к тестированию введенной информации.
Сам интерфейс старалась делать максимально близко к прямому переносу диалогового проектирования на экран, чтобы пользователь был как будто в настоящем диалоге. Это создает контекст и пользователю не придется перестраиваться с одного типа речи на другой. (Пример в следующем блоке).
Все, что можно автоматизировать и скрыть от пользователя, скрывала. Искала понятную визуальную форму для сложных форм (кек). (Пример ниже).
Каждый участок UXd обсуждался с командой разработки, чтобы отловить невозможные к реализации моменты. (Пример в следующем блоке).
Ниже поговорю подробнее про дизайн, а пока общее знакомство с получившимся конструктором. Слева зона настройки навыков, по которой можно передвигаться как угодно. Справа — демо бота. С ним человек всегда понимает, как бот звучит, как лучше сформулировать фразу, когда будет вступать клиент. (И отсюда можно запустить полноценное тестирование бота).
Общее знакомство с конструктором
Ниже поговорю подробнее про дизайн.
Слева зона настройки навыков, по которой можно передвигаться как угодно. Справа — демо бота. С ним человек всегда понимает, как бот звучит, как лучше сформулировать фразу, когда будет вступать клиент. (И отсюда можно запустить полноценное тестирование бота).
Когда был готов и запрототипирован основной сценарий, приступили к тестированию на пользователях. По нежно мною любимому методу RITE, когда тесты идут малыми группами и изменения в дизайн вносятся по итогам каждой группы. К последнему циклу тестирования мы получили практически идеальное прохождения сценария.
Из-за длинных ветвистых сценариев, проект был разбит на несколько отдельных задач, каждая в своем файле. При этом часто корректировки нужно было вносить сразу во все схожие экраны. Так я узнала, что у Figma нет состояния, когда вкладок открыто больше, чем влезает в строку 😅.
Показать сложное простым
На первый взгляд интерфейс выглядит достаточно незаморочистым: сгруппированные формы и все. Потому что сложная логика работы бота спрятана от пользователя. Конструктор должен ощущаться простым. Все, что можно оставить "под капотом", я старалась скрыть, автоматизировать. Пользователю ни к чему знать, как система работает на самом деле.
Каждый навык разбирала вместе с продактом: какие нам нужны функции бота, на какие задачи разбивается один навык, какие реакции бота доступны. Вместе мы собирали каждый навык в визуальном конструкторе JAICP. По сути, в Aimylogic я делала оболочку для конструктора JAICP, который, в свою очередь, оболочка для консоли. При проектировании навыка я понимала, как именно система будет считывать данные и превращать их в сценарий в конструкторе.
Разберем на примере пары навыков.
Оформление заказа или заявки
Бот принимает заказ, собирает все необходимые данные и отправляет их менеджеру.
Максимально простые тексты. Везде есть подсказки. Текст в полях ввода уже занесен в бота. Составлен так, чтобы пользователь мог оставить наш вариант или получить полезную подсказку по написанию своего (например, про юридические нюансы).
Настраиваемые смысловые блоки. Для каждого навыка выбрала стандартные и настраиваемые параметры. Пример стандартного: фраза начала выполнения навыка.
Настраиваемые — те, где пользователю нужна гибкость. Например, этот навык подходит и для создания заказа в магазине, и для записи на прием. Бот должен отрабатывать для одного навыка что-то одно.
Настраиваемые параметры обрели свою форму: "таблицы" из "карточек" с простыми контролами, их можно перемещать, удалять, добавлять новые. Менять контент, корректировать поведение бота, задавать свои параметры.
Самые часто встречаемые параметры уже зашиты в систему, человек может использовать их или создавать свои:
Настраиваемые — те, где пользователю нужна гибкость. Например, этот навык подходит и для создания заказа в магазине, и для записи на прием. Бот должен отрабатывать для одного навыка что-то одно.
Настраиваемые параметры обрели свою форму: "таблицы" из "карточек" с простыми контролами, их можно перемещать, удалять, добавлять новые. Менять контент, корректировать поведение бота, задавать свои параметры.
Самые часто встречаемые параметры уже зашиты в систему, человек может использовать их или создавать свои:
Некоторые стандартные параметры на деле сложнее, чем просто фраза бота. Например, «Проверка данных» запускает целый сценарий, где бот собирает воедино информацию от клиента и дает кнопки на выбор. Если все введено верно, бот двинется дальше по сценарию. Если нет, клиент выберет, в каком параметре ошибка, бот перезапустит сбор данных именно по этому параметру и вернется к подтверждению введенных данных.
Меню бота
Это автоматически создаваемый навык. Создавая оболочку для конструктора, иногда появляются элементы, которые невозможно сделать гибко, не поломав логику конструктора. Поэтому настройка кнопок меню — неотключаемый навык. В силу особенностей настройки он обычно расположен в конце.
Здесь человек настраивает кнопку: какой будет текст, с каким навыком она связана и какую реакцию бота запускает.
Для некоторых навыков существует жесткая связка навык+реакция. Например, для оформлении заказа нет других вариантов, кроме как запустить навык. Поскольку это ключевой навык бота, удалить кнопку так же нельзя. Если в боте настроен перевод на оператора, ситуация та же.
В колонке «Запускает» система дает на выбор только доступные навыки. Колонка «Реакция бота» предлагает действия в рамках выбранного навыка. Например, для навыка «Отвечать на вопросы» в Реакциях будут доступны только вопросы, занесенные в FAQ, и только свободные (которые не привязаны ни к какой другой кнопке).
Основной сценарий после тестирований
Посмотреть весь сценарий со всеми тонкостями настройки Навыков: Кликабельный прототип
Формат для форм
Для гибкости интерфейса разработала контрол формы, о котором получила очень хорошие отзывы на тестах.
Процесс работы:
1.
Проработано несколько концепций отображения процесса настройки бота, сформирован финальный набор макетов для обсуждения с разработкой.
2.
Определен набор и настройки Навыков.
3.
Проработка интерактивного прототипа для тестирования на пользователях.
4.
Тестирование и итеративное внесение исправлений с последующей финализацией макетов.
Согласование с разработкой:
Проведены сессии презентации
и обсуждения технической реализуемости дизайн-решений.
Для сложных в реализации элементов искала компромиссные решения.
После утверждения основного флоу и определения границ возможностей приступила к детальной проработке.
UX-тестирование:
Выбрала метод RITE (Rapid Iterative Testing and Evaluation), т.к. он позволяет оперативно вносить правки между сессиями
и достаточно быстро прийти к good enough решению.
Учатники: пользователи, знакомые со старой версией интерфейса и новые пользователи, по 2 цикла на каждую группу + завершающий цикл на смешанную группу.
Легенда на тестирование
У вас небольшой бизнес по печати книг на заказ, где каждый проект уникален и требует индивидуального расчета. Чтобы сэкономить ресурсы на поддержке сайта и операторов, вы хотите создать Telegram-бота. Он будет отвечать на стандартные вопросы клиентов, а сложные запросы — перенаправлять менеджерам. Это упростит общение и снизит нагрузку на бизнес.
Пример технического ограничения
В процессе работы сталкивалась с ситуациями, когда идеальный флоу реализовать невозможно. В таком случае приходилось искать другие пути получить тот же эффект, что запланирован.
Проблема
Невозможно настроить чат-виджет так, чтобы было доступно тестирование только одного навыка, и, в случае изменений, реплики бота отображались в реальном времени по мере их ввода пользователем. Чтобы проверить реплику в диалоге, пользователь должен пройти весь путь взаимодействия с ботом с самого начала флоу.
Решение
Создаем 2 разных функциональных блока, которые для пользователя выглядят как 2 режима существования чат-виджета:
1.
Режим визуализации, который позволяет видеть реплики бота
в диалоге в реальном времени. Технически это только визуальная копия чат-виджета.
2.
Режим тестирования, чтобы проверить флоу создаваемого бота. Технически это уже боевой чат-виджет, открывающийся поверх визуальной копии.
Ключевой результат
При сравнение аналогичных периодов
(2 месяца после релиза vs аналогичный период прошлого года) количество созданных ботов увеличилось в 7 раз
(2 месяца после релиза vs аналогичный период прошлого года) количество созданных ботов увеличилось в 7 раз
