«Не зовите оператора»: как мы переизобрели чат-бот силами дизайн-команды
Как UX-дизайнеры Markswebb адаптировали диалоговую механику для открытия вклада, вписали ее в существующую дизайн-систему банка и убедились, что бот не раздражает пользователей. Рассказываем в новом кейсе.
Диалог — самый естественный для людей формат взаимодействия. При этом на рынке нет однозначно успешных решений: концепцию в основном реализуют в виде чат-ботов, но они не дают пользователям опыт, сопоставимый с живым общением. Чаще всего они работают как альтернатива операторам поддержки и вызывают раздражение тем, что не понимают запросы или неправильно интерпретируют сообщения.
UX-дизайнеры Markswebb переосмыслили подход к диалогу в цифровых сервисах: разработали удобную и понятную форму, потенциально применимую для разных индустрий, продуктов и услуг. Для примера взяли дизайн-систему и сценарий открытия вклада в мобильном приложении Райффайзен Банка. Это единственный крупный банк, дизайн-система которого публично доступна в Figma. У остальных она представлена в коде либо ее нет в открытом доступе.
Диалог лучше анкеты
Стандартный формат настройки вклада — форма-калькулятор. Она позволяет настроить все параметры продукта на одном экране, но почти не помогает разобраться в деталях. Например, какие условия лучше подходят, как именно они влияют на доходность и что делать с продуктом после открытия.
Этот вариант хорошо подходит для прямого сравнения качества UX с диалоговой механикой. В отличие от диалога форма не формирует эмоциональную связь с пользователем и не дает достаточного количества информации для принятия решения.
Что предложили мы:
- Уютный диалог с пошаговым движением к результату.
- Помощь в принятии решений на всем пути взаимодействия с продуктом.
- Своевременное объяснение свойств и ценностей продукта.
- Наглядную связь параметров продукта и итогового предложения.
- Возможность отказаться от избыточной заботы.
Конвертация экспертизы: из дизайнера в исследователя
Все этапы проекта, включая исследовательскую часть, реализовала команда UX-дизайнеров Markswebb — это три человека. В частности, ребята решили самостоятельно провести юзабилити-тесты на респондентах, чтобы убедиться в качестве своей работы и исправить ошибки.
Чтобы дизайн-решения в современных цифровых продуктах были конкурентноспособны, они не должны создавать UX-проблем. Особенно, в таких прогрессивных индустриях, как финтех. Если ты как дизайнер не способен самостоятельно выделять их на ранних стадиях, ты будешь постоянно расходовать избыточное количество ресурсов — обращаться к чужой экспертизе, потом тратить время на исправление допущенных ошибок. Способность самостоятельно отсеять ±80-90% проблем оптимизирует процесс.
Чтобы оптимизировать затраты ресурсов, команда составила план: определила последовательность шагов и точки роста, запланировала обучение.
За исследовательской экспертизой обратились к аналитикам и базам знаний агентства:
- Попросили CEO Markswebb Алексея Скобелева верифицировать гипотезы.
- Проконсультировались у тимлидов, как правильно провести юзабилити-тесты и составить вопросы для респондентов.
- С помощью гайда по UX-проблемам научились корректно формулировать проблемы интерфейса через состояние пользователей.
Шаги реализации
Шаг 1: На старте мы детально изучили процесс открытия вклада в Райффайзен Банке. В результате разработали свой сценарий, который упрощает существующий и делит его на маленькие этапы с последовательным погружением пользователя в контекст. Один этап — одно решение.
Шаг 2: Изучили рынок. Нам нужно было сформировать ценностное предложение, на которое команда сможет ориентироваться в процессе разработки MVP — образ конечной цели. Для этого мы разобрались, какие реализации существуют, в чем их преимущества и недостатки, что стоит переиспользовать, а что нужно придумать с нуля. В итоге получили понимание того, что мы хотим видеть в своем конечном продукте, и набор референсов.
Помимо привычных практик финтеха собрали решения из других предметных областей — например, позаимствовали из мессенджеров механику редактирования сообщения. Наш чат-бот должен был сам предлагать варианты ответов. При этом мы учитывали, что пользователь может ошибиться или захотеть изменить выбранный ответ. На этот случай мы реализовали в диалоге возможность изменить сообщение через долгое нажатие.
Шаг 3: Формулировка гипотез. На их основе мы должны были тестировать прототип (MVP). Верифицировать формулировки и заложенные смыслы попросили CEO Markswebb Алексея Скобелева. Остановились на семи тезисах для проверки:
- Диалоговая форма понятна и не вызывает трудностей.
- Контекстная информация в чате помогает принимать решения и отвечает на вопросы пользователя.
- Механика изменения ранее данного ответа в чате жизнеспособна — респонденты про нее помнят и используют в случае необходимости. Единственная спорная гипотеза по итогам верификации. Было непонятно, как проверить ее жизнеспособность на респондентах, если они не будут ошибаться — наводящие вопросы исказили бы конечные результаты исследования.
- Виджеты в диалоге не воспринимаются как что-то инородное.
- Зафиксированный компонент «общая информация о вкладе» полезен и не мешает.
- FAQ помогает в любой момент получить ответ на вопрос по любой теме, касающейся вклада.
- Текстовые ответы, заложенные в кнопку «У меня есть вопросы», помогают принимать решения.
Шаг 4: Разработка прототипа.
Шаг 5: Общение с респондентами. Чтобы проверить гипотезы и убедиться, что формат нравится пользователям и будет полезен бизнесу, дизайнеры провели семь очных модерируемых юзабилити-тестов.
Чтобы избежать искажения результатов исследования, придерживались следующих принципов:
- Респондентов отбирали так, чтобы минимизировать влияние профессиональной деформации на результат. В основном это были сотрудники Markswebb — менеджеры проектов, аккаунт-менеджеры и офис-менеджер. Дополнительно взяли пару человек извне — полицейского и бизнес-аналитика. UX-исследователей на тестирование в качестве респондентов не привлекали.
- У всех респондентов был разный опыт взаимодействия с вкладами: от «открывал однажды, лет 6 назад» до «пользуюсь сейчас и знаю, как это работает».
Нас интересовала быстрая качественная проверка гипотез, поэтому тестирование состояло из двух небольших задач, а время выполнения не фиксировалось.
- Открыть вклад в приложении на удобных для себя условиях.
- Изменить неправильно данный ответ в чате.
Чтобы проверить гипотезу про удобство изменения ранее отправленных сообщений, мы придумали нестандартное решение — замаскировали задачу под мисклик.
В голову пришла идея смоделировать частую ошибку пользователя — миссклик. Когда респондент нажимал на «Да, буду пополнять», в прототипе отправлялся ответ «Нет, не буду пополнять». В итоге все интерпретировали эту ошибку как «видимо, промахнулся» — никто из 7 человек даже не предположил, насколько мы коварны.
Шаг 6: Доработка макетов, исправление ошибок, инсайты.
Мы проанализировали протоколы юзабилити-тестов и выявили 16 UX-проблем. Отсортировали их по количеству затронутых респондентов и по уровню критичности, который определили на основании гайда. В итоге взяли в работу и решили семь важных проблем. Еще четыре решили «по дороге» в рамках корректировки текста и дополнительного анализа.
Юзабилити-тесты показали, что неформальная и легкая диалоговая форма нравится пользователям больше, чем калькулятор. Четыре из семи респондентов сказали, что предпочли бы такой бот, так как не нужно вводить данные, нравится элемент пошагового погружения, плюс сам формат эмоционально приятнее.
Двое опытных пользователей в самом начале тестирования были недовольны навязыванием такой диалоговой механики, но в процессе взаимодействия поменяли свое отношение на противоположное. В конце тестирования они отмечали, что информация, полученная в процессе общения с ботом, действительно помогала им принимать решения и была удобнее, чем стандартный «калькулятор».
Кирилл, 26 лет: «Дело в простоте твоих шагов. Задача открыть вклад делится на много мелких подзадач. И ты постепенно регулируешь основные параметры, которые тебе в дальнейшем выводят некую концепцию того, что в итоге то будет».
Паша, 39 лет: «На мой взгляд, вклад — это сложный продукт, потому что я первый раз его открывал, и благодаря тому, что он пошаговый, понимал его работу. Нравится, что здесь не надо вводить данные. Я делаю это интуитивно, одним пальцем. А в калькуляторе будет несколько полей, которые я как-то из головы должен заполнить».
- Настя, 25 лет: «Наверное, именно с эмоциональной точки зрения более комфортно… Ощущение, что обо мне заботятся, со мной разговаривают».
К чему пришли: что должно быть в простом и полезном сценарном боте
Вывод 1: Три слоя подачи информации — помогаем новичкам, не раздражаем опытных, отвечаем на вопросы.
Первый слой — это минимально необходимый объем информации, помогающий пользователю принимать решения. В нашем случае — контекстная информация в сообщениях бота. В ходе юзабилити-тестов мы выяснили, что она действительно помогает и предвосхищает вопросы пользователей. Например, пять из семи респондентов отметили, что в принятии решения помогало описание того, как выбор влияет на доход.
Второй и третий слои — это ответы на все возможные дополнительные вопросы. Например, почему меняются проценты и доходность, как работают налоги, автопополнение и т.д. Их мы спрятали в блоках «У меня есть вопрос» и FAQ. Внутри кнопки «У меня есть вопрос» — информация по конкретной теме, связанной с шагом, на котором находится пользователь. FAQ же аккумулирует блоки каждого шага и составляет общую базу знаний по вкладам, разделенную на категории для удобства поиска.
Во время тестов к этим блокам обращалась меньшая часть респондентов — в основном новички. Опытным пользователям хватило информации из сообщений бота.
Вывод 2: Не навязывать свой подход.
Опытные пользователи, которые знают принцип работы продукта, предпочитают привычный формат взаимодействия с ним. В нашем случае двое из семи респондентов сказали, что настроить вклад самостоятельно через калькулятор для них быстрее и легче, так как уже есть аналогичный опыт и для них это простой продукт. При этом один из них уточнил, что, открывая вклад в новом для себя банке, однозначно выбрал бы диалог с возможностью завизировать ответы в конце через настройки.
Мы решили, что для таких случаев стоит сохранить возможность вызвать стандартный интерфейс-калькулятор. У нас она есть в закрепленной плашке summary.
Вывод 3: Закрепленная плашка с основной информацией о продукте полезна и не мешает.
На старте наша плашка summary отображала сумму, условия, итоговые проценты и доходность вклада. По итогам юзабилити-тестов мы ее доработали — добавили акцентный элемент, так как большинство респондентов ее не сразу замечали, а также убрали лишнюю информацию и оптимизировали верстку.
Вывод 4: Выбор момента для онбординга влияет на его эффективность.
Демонстрировать пользователю возможности интерфейса лучше непосредственно «в точке приложения» инструкции. Мы это поняли на примере онбординга в механику изменения ранее данного ответа.
Так как решение с долгим тапом изначально было взято из мессенджеров, а наш MVP — чат-бот, мы объясняли респондентам принципы работы через онбординг в начале сценария. В ходе тестов мы выяснили, что большинство читает онбординг бегло, и в нужный момент пять из семи пользователей не могут вспомнить, как изменить ответ. При этом они начинают искать какие-то более привычные решения — например, двое отметили, что при обнаружении ошибки просто закрыли бы диалог, чтобы начать процесс сначала.
В ходе доработок мы перенесли онбординг из начала сценария в место потенциальной ошибки. Теперь сообщение о том, что решение можно будет изменить позднее, пользователь получает сразу после выбора ответа. Чтобы дополнительно привлечь к нему внимание, мы добавили яркий эмоджи с восклицательным знаком. Также для забывчивых появилось дополнительное облачко с подсказкой, автоматически всплывающее при скролле диалога назад.
Вывод 5: Сообщить об изменениях недостаточно — нужна конкретика.
В первой версии нашего MVP при изменении параметров вклада пользователь получал всплывающее уведомление с текстом «Вы изменили сумму вклада». Несмотря на то, что у респондентов это не вызвало затруднений, мы решили что такая реализация не дает пользователю очевидного ответа на вопрос, как изменение ответа повлияло на условия вклада.
Мы доработали уведомление и добавили в него конкретную информацию о том, как поменялась ставка. Плашка висит 3 секунды, затем пропадает. Убрать ее самостоятельно можно свайпом вверх.
Дополнительно добавили привычную механику, используемую в мессенджерах, — шорткат возврата к последнему сообщению в диалоге.
Вывод 6: Не всегда грамотного UX-дизайна достаточно — может понадобиться более комплексная работа над продуктом.
В первоначальном прототипе мы прямо на старте сценария предлагали пользователю «быстрый» оффер — открыть вклад на максимально выгодных условиях, рассчитанных на основе смарт-аналитики его доходов и расходов. Идея была в том, что мы как банк знаем, как клиент тратит и накапливает деньги, и можем предложить наиболее комфортное решение.
После юзабилити-тестов мы отказались от этой идеи, так как практически никто из респондентов не принял этот оффер as is — им хотелось узнать подробности и самостоятельно все проверить. В результате мы трансформировали сценарий и начали предлагать решение на основании параметров, заданных самим пользователем. В нашем случае — желаемой суммы и срока вклада.
Для себя мы сделали вывод, что проблема может быть в недостаточном доверии к автоматической аналитике. Чтобы проактивные предложения работали, с клиентами нужно вести коммуникацию о них на протяжении всего пользовательского опыта. Например, показывать сториз с анализом трат, прогнозировать траты на следующий период, оценивать точность этих прогнозов — тем самым вовлекая, показывая логику работы и ценность такой аналитики.
Эта задача нерешаема в рамках двух-трех коротких сообщений в процессе открытия продукта, поэтому эту идею мы из концепции убрали.
Не бойтесь экспериментировать и выходить за рамки
Нестандартные проекты полезны всем участникам рынка:
- Бизнесу — как источник новых идей и решений для привлечения клиентов. Подробнее о преимуществах нашей разработки можно узнать узнать на сайте Markswebb и в кейсе на Behance.
- Дизайнерам и исследователям — как возможность расширить границы и поработать в рамках собственной инициативы. Изучить новые предметные области, прокачать или приобрести навыки смежных специализаций, проявить креативность.
Делитесь впечатлениями о кейсе в комментариях или будем рады получить обратную связь на почту hello@markswebb.ru.
Бесполезный огород. Стандартные переключатели быстрее и нагляднее. И самовнушение "Диалог — самый естественный для людей формат взаимодействия" вообще ни в какие рамки даже за вычетом того, что "людей" в примере нет.
Комментарий недоступен
То-то, я смотрю, вы наглядный контрол в ответ отправили, а не текст)
раньше это называли wizard на английском, просто ряд диалоговых окон с вариантами ответов. нахрен это было в якобы диалог упаковывать - х3, мертворождённая затея
Визард — это та же анкета настройки финального продукта, в ней есть свои плюсы и минусы с точки зрения пользовательского опыта.
Часть дизайнеров на старте тоже скептически относились к идее. Действительно, зачем растягивать процесс и заставлять общаться с ботом?
Но результаты исследования показали, что подавляющее большинство положительно оценили такое решение. Им оно показалось более удобным с точки зрения ощущения контроля и и понимания свойств, ограничений и возможностей продукта.
Когда ты четко понимаешь, как работает продукт, в который ты собираешься вложить свои кровные, тебя уже не беспокоит то, что это «дурацкий чат» или «еще один визард». Ты взаимодействуешь с интерфейсом, получаешь ожидаемый и прозрачный результат, а негатив сменяется чувством комфорта.
Не мешайте юношам переизобретать визарды. :)
Ещё несколько итераций с дополнительными фильтрами, контралами настроек, навигацией и получится классический визард. И снова можно писать простыню про невероятные достижения. Без негатива, пусть развлекаются. :)
никто не заменит хорошего саппорта, который хочет реально помочь человеку. и чем больше ботов в поддержке _клиентов_ (или будущих клиентов) компании N, тем меньше ей хочется пользоваться. если я пишу в поддержку, значит мне нужна помощь и я не смог решить проблему самостоятельно. а если я не смог, значит вы хреново или неполностью подаёте информацию, или мне нужно решить нестандартную ситуацию, которую бот не решит. боты - экономия на клиентах.
отойду от оффтопа, вернемся к макетам:
По факту вы сделали мультистеп форму в виде чата. не знаю кто вам сказал, что оборачивать форму в чаты это круто, но задача мультистеп формы разделить большую форму на много маленьких, соединенных логически.
НО, мультистеп плохо работает, когда юзеру надо принять несколько последовательных решений, которые(возможно) связаны между собой, пока он не знает наверняка последствий этих решений. То есть сперва юзеру надо дать контент(условия) решения, потом попросить его это решение принять или идти к следующему. Вы же предлагаете мне выбрать комбинезон для будущего ребенка, когда я только ребенка планирую, не надо так - пол и размер могут быть разные(а возможно ребенок вовсе не выйдет, всякое бывает). кмк условия сперва, потом принятие решения.
Если у вас выбор опции подразумевает только "да" или "нет", ставьте чекбокс и ниже опишите в чем прикол этой опции понятным языком. пример по вашей картинке: я не уверен хочу ли я иметь пополнение досрочно. вроде прикольно, но есть наверняка условия изменятся. я жму "да, хочу", читаю условия, у меня остаются вопросы по условиям, я говорю "у меня вопросы", мне показывают FAQ, который не отвечает на мой вопрос, я иду в чат помощи(а где кнопка?), где мне пытается помочь менеджер, понимаю, что мне условия не подходят, возвращаюсь, жму на выбор свой с целью изменить решение, выключаю решение, меня ведут дальше. 6 действий. Накидал прототип, где тоже самое решается за 3 действия. и я сперва ознакамливаюсь с условиями и потом делаю выбор(или сразу делаю, если уверен что не подходит).
пысы: боты - отстой