{"id":14277,"url":"\/distributions\/14277\/click?bit=1&hash=17ce698c744183890278e5e72fb5473eaa8dd0a28fac1d357bd91d8537b18c22","title":"\u041e\u0446\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c \u043b\u0438\u0442\u0440\u044b \u0431\u0435\u043d\u0437\u0438\u043d\u0430 \u0438\u043b\u0438 \u0437\u043e\u043b\u043e\u0442\u044b\u0435 \u0443\u043a\u0440\u0430\u0448\u0435\u043d\u0438\u044f","buttonText":"\u041a\u0430\u043a?","imageUuid":"771ad34a-9f50-5b0b-bc84-204d36a20025"}

«Не зовите оператора»: как мы переизобрели чат-бот силами дизайн-команды

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

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

UX-дизайнеры Markswebb переосмыслили подход к диалогу в цифровых сервисах: разработали удобную и понятную форму, потенциально применимую для разных индустрий, продуктов и услуг. Для примера взяли дизайн-систему и сценарий открытия вклада в мобильном приложении Райффайзен Банка. Это единственный крупный банк, дизайн-система которого публично доступна в Figma. У остальных она представлена в коде либо ее нет в открытом доступе.

Диалог лучше анкеты

Стандартный формат настройки вклада — форма-калькулятор. Она позволяет настроить все параметры продукта на одном экране, но почти не помогает разобраться в деталях. Например, какие условия лучше подходят, как именно они влияют на доходность и что делать с продуктом после открытия.

Этот вариант хорошо подходит для прямого сравнения качества UX с диалоговой механикой. В отличие от диалога форма не формирует эмоциональную связь с пользователем и не дает достаточного количества информации для принятия решения.

Что предложили мы:

  • Уютный диалог с пошаговым движением к результату.
  • Помощь в принятии решений на всем пути взаимодействия с продуктом.
  • Своевременное объяснение свойств и ценностей продукта.
  • Наглядную связь параметров продукта и итогового предложения.
  • Возможность отказаться от избыточной заботы.

Конвертация экспертизы: из дизайнера в исследователя

Все этапы проекта, включая исследовательскую часть, реализовала команда UX-дизайнеров Markswebb — это три человека. В частности, ребята решили самостоятельно провести юзабилити-тесты на респондентах, чтобы убедиться в качестве своей работы и исправить ошибки.

Чтобы дизайн-решения в современных цифровых продуктах были конкурентноспособны, они не должны создавать UX-проблем. Особенно, в таких прогрессивных индустриях, как финтех. Если ты как дизайнер не способен самостоятельно выделять их на ранних стадиях, ты будешь постоянно расходовать избыточное количество ресурсов — обращаться к чужой экспертизе, потом тратить время на исправление допущенных ошибок. Способность самостоятельно отсеять ±80-90% проблем оптимизирует процесс.

Владимир Кулаев, Design Team Lead Markswebb

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

За исследовательской экспертизой обратились к аналитикам и базам знаний агентства:

  • Попросили CEO Markswebb Алексея Скобелева верифицировать гипотезы.
  • Проконсультировались у тимлидов, как правильно провести юзабилити-тесты и составить вопросы для респондентов.
  • С помощью гайда по UX-проблемам научились корректно формулировать проблемы интерфейса через состояние пользователей.

Шаги реализации

Шаг 1: На старте мы детально изучили процесс открытия вклада в Райффайзен Банке. В результате разработали свой сценарий, который упрощает существующий и делит его на маленькие этапы с последовательным погружением пользователя в контекст. Один этап — одно решение.

Шаг 2: Изучили рынок. Нам нужно было сформировать ценностное предложение, на которое команда сможет ориентироваться в процессе разработки MVP — образ конечной цели. Для этого мы разобрались, какие реализации существуют, в чем их преимущества и недостатки, что стоит переиспользовать, а что нужно придумать с нуля. В итоге получили понимание того, что мы хотим видеть в своем конечном продукте, и набор референсов.

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

Шаг 3: Формулировка гипотез. На их основе мы должны были тестировать прототип (MVP). Верифицировать формулировки и заложенные смыслы попросили CEO Markswebb Алексея Скобелева. Остановились на семи тезисах для проверки:

  1. Диалоговая форма понятна и не вызывает трудностей.
  2. Контекстная информация в чате помогает принимать решения и отвечает на вопросы пользователя.
  3. Механика изменения ранее данного ответа в чате жизнеспособна — респонденты про нее помнят и используют в случае необходимости. Единственная спорная гипотеза по итогам верификации. Было непонятно, как проверить ее жизнеспособность на респондентах, если они не будут ошибаться — наводящие вопросы исказили бы конечные результаты исследования.
  4. Виджеты в диалоге не воспринимаются как что-то инородное.
  5. Зафиксированный компонент «общая информация о вкладе» полезен и не мешает.
  6. FAQ помогает в любой момент получить ответ на вопрос по любой теме, касающейся вклада.
  7. Текстовые ответы, заложенные в кнопку «У меня есть вопросы», помогают принимать решения.

Шаг 4: Разработка прототипа.

Шаг 5: Общение с респондентами. Чтобы проверить гипотезы и убедиться, что формат нравится пользователям и будет полезен бизнесу, дизайнеры провели семь очных модерируемых юзабилити-тестов.

Чтобы избежать искажения результатов исследования, придерживались следующих принципов:

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

Нас интересовала быстрая качественная проверка гипотез, поэтому тестирование состояло из двух небольших задач, а время выполнения не фиксировалось.

  1. Открыть вклад в приложении на удобных для себя условиях.
  2. Изменить неправильно данный ответ в чате.

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

В голову пришла идея смоделировать частую ошибку пользователя — миссклик. Когда респондент нажимал на «Да, буду пополнять», в прототипе отправлялся ответ «Нет, не буду пополнять». В итоге все интерпретировали эту ошибку как «видимо, промахнулся» — никто из 7 человек даже не предположил, насколько мы коварны.

Владимир Кулаев, Design Team Lead Markswebb

Шаг 6: Доработка макетов, исправление ошибок, инсайты.

Мы проанализировали протоколы юзабилити-тестов и выявили 16 UX-проблем. Отсортировали их по количеству затронутых респондентов и по уровню критичности, который определили на основании гайда. В итоге взяли в работу и решили семь важных проблем. Еще четыре решили «по дороге» в рамках корректировки текста и дополнительного анализа.

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

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

  • Кирилл, 26 лет: «Дело в простоте твоих шагов. Задача открыть вклад делится на много мелких подзадач. И ты постепенно регулируешь основные параметры, которые тебе в дальнейшем выводят некую концепцию того, что в итоге то будет».

  • Паша, 39 лет: «На мой взгляд, вклад — это сложный продукт, потому что я первый раз его открывал, и благодаря тому, что он пошаговый, понимал его работу. Нравится, что здесь не надо вводить данные. Я делаю это интуитивно, одним пальцем. А в калькуляторе будет несколько полей, которые я как-то из головы должен заполнить».

  • Настя, 25 лет: «Наверное, именно с эмоциональной точки зрения более комфортно… Ощущение, что обо мне заботятся, со мной разговаривают».

К чему пришли: что должно быть в простом и полезном сценарном боте

Вывод 1: Три слоя подачи информации — помогаем новичкам, не раздражаем опытных, отвечаем на вопросы.

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

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

Во время тестов к этим блокам обращалась меньшая часть респондентов — в основном новички. Опытным пользователям хватило информации из сообщений бота.

Вывод 2: Не навязывать свой подход.

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

Мы решили, что для таких случаев стоит сохранить возможность вызвать стандартный интерфейс-калькулятор. У нас она есть в закрепленной плашке summary.

Вывод 3: Закрепленная плашка с основной информацией о продукте полезна и не мешает.

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

Вывод 4: Выбор момента для онбординга влияет на его эффективность.

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

Так как решение с долгим тапом изначально было взято из мессенджеров, а наш MVP — чат-бот, мы объясняли респондентам принципы работы через онбординг в начале сценария. В ходе тестов мы выяснили, что большинство читает онбординг бегло, и в нужный момент пять из семи пользователей не могут вспомнить, как изменить ответ. При этом они начинают искать какие-то более привычные решения — например, двое отметили, что при обнаружении ошибки просто закрыли бы диалог, чтобы начать процесс сначала.

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

Вывод 5: Сообщить об изменениях недостаточно — нужна конкретика.

В первой версии нашего MVP при изменении параметров вклада пользователь получал всплывающее уведомление с текстом «Вы изменили сумму вклада». Несмотря на то, что у респондентов это не вызвало затруднений, мы решили что такая реализация не дает пользователю очевидного ответа на вопрос, как изменение ответа повлияло на условия вклада.

Мы доработали уведомление и добавили в него конкретную информацию о том, как поменялась ставка. Плашка висит 3 секунды, затем пропадает. Убрать ее самостоятельно можно свайпом вверх.

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

Вывод 6: Не всегда грамотного UX-дизайна достаточно — может понадобиться более комплексная работа над продуктом.

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

После юзабилити-тестов мы отказались от этой идеи, так как практически никто из респондентов не принял этот оффер as is — им хотелось узнать подробности и самостоятельно все проверить. В результате мы трансформировали сценарий и начали предлагать решение на основании параметров, заданных самим пользователем. В нашем случае — желаемой суммы и срока вклада.

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

Эта задача нерешаема в рамках двух-трех коротких сообщений в процессе открытия продукта, поэтому эту идею мы из концепции убрали.

Не бойтесь экспериментировать и выходить за рамки

Нестандартные проекты полезны всем участникам рынка:

  • Бизнесу — как источник новых идей и решений для привлечения клиентов. Подробнее о преимуществах нашей разработки можно узнать узнать на сайте Markswebb и в кейсе на Behance.
  • Дизайнерам и исследователям — как возможность расширить границы и поработать в рамках собственной инициативы. Изучить новые предметные области, прокачать или приобрести навыки смежных специализаций, проявить креативность.

Делитесь впечатлениями о кейсе в комментариях или будем рады получить обратную связь на почту [email protected].

0
24 комментария
Написать комментарий...
Андрей Федоренко

Бесполезный огород. Стандартные переключатели быстрее и нагляднее. И самовнушение "Диалог — самый естественный для людей формат взаимодействия" вообще ни в какие рамки даже за вычетом того, что "людей" в примере нет.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Vladimir Kulaev

То-то, я смотрю, вы наглядный контрол в ответ отправили, а не текст)

Ответить
Развернуть ветку
Егор Т.

раньше это называли wizard на английском, просто ряд диалоговых окон с вариантами ответов. нахрен это было в якобы диалог упаковывать - х3, мертворождённая затея

Ответить
Развернуть ветку
Vladimir Kulaev

Визард — это та же анкета настройки финального продукта, в ней есть свои плюсы и минусы с точки зрения пользовательского опыта.

Часть дизайнеров на старте тоже скептически относились к идее. Действительно, зачем растягивать процесс и заставлять общаться с ботом?

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

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

Ответить
Развернуть ветку
Yaroslav Tugolukovskiy

А какие исследования?

Ответить
Развернуть ветку
Vladimir Kulaev

Когда не читал содержание статьи, а сразу пошел в комменты спрашивать, о чем она?))

Ответить
Развернуть ветку
Yaroslav Tugolukovskiy

Читал, увидел, что у вас всего семь респондентов, чего явно недостаточно, чтобы делать далеко идущие выводы. Не понятно, как был выстроен процесс исследования. Поэтому и спрашиваю.

Ответить
Развернуть ветку
Vladimir Kulaev

Качественные ux-исследования не предполагают участие большого количества пользователей. На выборках свыше 5 респондентов инсайты и выявленные проблемы уже начинают повторяться.

https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/

Ответить
Развернуть ветку
Yaroslav Tugolukovskiy

Что ж, я зря быканул. Спасибо за ссылку!

Ответить
Развернуть ветку
Артем Наумов

Не мешайте юношам переизобретать визарды. :)

Ещё несколько итераций с дополнительными фильтрами, контралами настроек, навигацией и получится классический визард. И снова можно писать простыню про невероятные достижения. Без негатива, пусть развлекаются. :)

Ответить
Развернуть ветку
Артём Лисовский

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

отойду от оффтопа, вернемся к макетам:
По факту вы сделали мультистеп форму в виде чата. не знаю кто вам сказал, что оборачивать форму в чаты это круто, но задача мультистеп формы разделить большую форму на много маленьких, соединенных логически.
НО, мультистеп плохо работает, когда юзеру надо принять несколько последовательных решений, которые(возможно) связаны между собой, пока он не знает наверняка последствий этих решений. То есть сперва юзеру надо дать контент(условия) решения, потом попросить его это решение принять или идти к следующему. Вы же предлагаете мне выбрать комбинезон для будущего ребенка, когда я только ребенка планирую, не надо так - пол и размер могут быть разные(а возможно ребенок вовсе не выйдет, всякое бывает). кмк условия сперва, потом принятие решения.

Если у вас выбор опции подразумевает только "да" или "нет", ставьте чекбокс и ниже опишите в чем прикол этой опции понятным языком. пример по вашей картинке: я не уверен хочу ли я иметь пополнение досрочно. вроде прикольно, но есть наверняка условия изменятся. я жму "да, хочу", читаю условия, у меня остаются вопросы по условиям, я говорю "у меня вопросы", мне показывают FAQ, который не отвечает на мой вопрос, я иду в чат помощи(а где кнопка?), где мне пытается помочь менеджер, понимаю, что мне условия не подходят, возвращаюсь, жму на выбор свой с целью изменить решение, выключаю решение, меня ведут дальше. 6 действий. Накидал прототип, где тоже самое решается за 3 действия. и я сперва ознакамливаюсь с условиями и потом делаю выбор(или сразу делаю, если уверен что не подходит).

пысы: боты - отстой

Ответить
Развернуть ветку
Кирилл Кобозев

Это всё очень здорово и интересно, но работает ровно до того момента, пока у пользователя не возникает какой-то нестандартный вопрос или ситуация. Например решение проблемы "возврат комиссии и откат лимитов по тарифу за валютный перевод" (который был отменен в банке-получателе) - заняло у меня примерно неделю переписки с несколькими живыми операторами. Бот такое никак не осилит. А началось все с того, что первый оператор ответил мне шаблонной ботофразой в духе "комиссии по валютным переводам не возвращаются". Все, диалог с ботом-оператором на этом и закончился, так как эта ситуация далее требовала согласования с какими-то специально обученными людьми.

Ответить
Развернуть ветку
Vladimir Kulaev

Задачей спроектированного формата является качественная автоматизация понятного и предсказуемого процесса.

Он не рассчитан на сложные, с большой степенью неопределенности процесс.

Было бы глупо пытаться строить ракетный двигатель одним молотком.

Ответить
Развернуть ветку
Игорь Мыслинский

А есть статистика - какая часть пользователей пользуется формой, а какая диалогом при открытии вклада?

Ответить
Развернуть ветку
Vladimir Kulaev

Это не готовый продукт, а концепция. Что, впрочем, не помешало нам протестировать идею. Поэтому статистики конкретно по этому сценарию у нас нет, количественных исследований мы не проводили.

Топовые ребята из финтеха позволяют открывать продукты из чата (по дефолту, через бота), но там куча своих проблем. Так что делать выводы на основании такой статистики (если бы она была) все равно некорректно.

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

Поэтому на старте взаимодействия с ботом, когда ожидания пользователей не оправдываются, у людей может возникать раздражение. Но это скорее вопрос онбординга и грамотного внедрения в продукт, чем проблема самого решения.

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

Ответить
Развернуть ветку
Text Body

Они стали относиться к боту лояльнее, потому что выяснили, что это не бот, а форма/визард в виде бота, и что на самом деле диалога здесь нет, а есть просто прохождение этапов визарда

Ответить
Развернуть ветку
Артём Лисовский

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

вы хотите оформить страховку дмс по стоматологии?

- да

вы хотели бы проверяться у стоматолога каждый месяц и чтобы ваши зубы были здоровы?

- ну вроде да, а сколько стоит и что как

эта услуга сделает вам первый год дмс по стоматологии на 20% дороже, но потом при прохождении всех чекапов вы будете платить на 20% меньше всегда

- нет, дорого

а хотели бы вы чтобы ваши зубы были белыми?

- конечно

тогда у нас есть акция отбеливаниеMAX, 12 отбеливаний в течение года за 25000 рублей к страховке допом

- не надо

у нас еще 120 классных опций, вам интересно?

- нет
—- vs
[да/нет] ежемесячный чекап у стоматолога с понижением стоимости страховки на 20% со 2 года
[да/нет] 12 отбеливаний в течение года за +25000 рублей
...

Ответить
Развернуть ветку
Vladimir Kulaev

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

Конечно, если так накидывать на пользователя ненужные ему услуги и на каждое сообщение требовать ответ — никто этим пользоваться не захочет. Чтобы спроектировать сценарий, который не будет раздражать — нужно идти от целей пользователей. Зачем он пришел вообще? Послушать перечисление ваших предложений или за чем-то конкретным?

Это форма не типа «а хотите у нас что-то купить?», а «мы знаем, что вам нужно вот это и мы вам поможем это получить».

Ответить
Развернуть ветку
Артём Лисовский
В отличие от диалога форма не формирует эмоциональную связь с пользователем и не дает достаточного количества информации для принятия решения.

я зацепился за это и исходя из этого понял проблему, которую решаете. эмоциональная часть это лирика, для нее можно всю инфу подать мемами или залить фон экрана бирюзовым. а вот по подаче инфы для принятия решения можно подискутировать, что и сделал. инфу подавать в диалоге плохо, потому что инфа это скролящийся контент, который ты читаешь чаще по диагонали; диалог это черный ящик. я привел пример по снятию ниже, по факту выбор подключаемых опций это как раз продажа, вы торгуетесь за % и доход. Иначе банк бы просто предлагал договор с условиями и всё. И я как юзер абсолютно не знаю что за услуги для вклада вы придумали(потому что не юзаю вклады часто/у каждого огорода свои приколы) и какие из них мне реально нужны. что-то звучит прикольно, но не прикольно падает ставка; что-то мне не надо было и тут, прочитав условия, - почему бы и нет. принятие решения это и есть продажа своего рода. ‘красный гарнитур бесплатно или зеленый с доплатой 100 рублей’ и ты думаешь - пойдет тебе красный к зеленым обоям(а кому-то к красным обоям пойдет) или доплатить.

Ответить
Развернуть ветку
Vladimir Kulaev

Все верно, эту задачу мы и решали. Как подать это органично диалогу, как выделить главное, чтобы не перегрузить большим объемом информации, при этом оставив возможность уточнить детали.

Необходимая информации подается до того, как Рэя задает вопрос, пользователь видит, как его решение повлияет на финальный оффер и принимает решение осознанно.

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

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

Ответить
Развернуть ветку
Alex Jian

Если не умеет готовить договор номер паблик стейтик джава точка ланг точка обджект ру точка тиньков ангшенс точка аф джава точка ланг точка буллин джава, то и даром не нужен такой сервис...

Ответить
Развернуть ветку
Невероятный Блондин
и убедились, что бот не раздражает пользователей

О сколько вам открытий чудных предстоит ))

Ответить
Развернуть ветку
Vladimir Kulaev

Сколько?

Ответить
Развернуть ветку
21 комментарий
Раскрывать всегда