Создание UX-исследовательского направления в Банке Б

Банк Б активно развивал цифровые продукты для физических и юридических лиц. Одним из ключевых продуктов было веб-приложение на технологии PWA для физических лиц.

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

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

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

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

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

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

Были проведены встречи с представителями бизнеса, дизайна, аналитики, ИТ и руководителями направлений. Дополнительно изучались процессы разработки и существующая документация, а также оценивалась организационная UX-зрелость банка. UX-зрелость организации находилась на начальном уровне.

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

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

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

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

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

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

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

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

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

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

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

Для самого исследовательского направления также рассчитывался ROI. Исследования рассматривались не как затраты на получение информации, а как инструмент снижения продуктовых рисков и повышения эффективности решений.

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

В рамках новой модели продукт прошел несколько этапов проверки: экспертный анализ, анализ конкурентных решений, UX-исследование, разработка решений и ретест. Исследование выявило проблемы в пользовательском сценарии, которые могли препятствовать его выполнению и снижать конверсию. На основе результатов пользовательский сценарий был переработан и повторно протестирован.

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

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

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

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

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

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

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

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

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

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

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

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

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

Time to Market — 25%. Исследования позволили быстрее проверять продуктовые гипотезы и принимать решения до начала разработки, сокращая время на обсуждения и последующие изменения.
Количество доработок — с 3 до 1 до релиза, после релиза — до 0. Проблемы пользовательских сценариев стали выявляться на этапе исследования и проектирования, а не после выхода продукта к клиентам.
Затраты на разработку — снизились на 30%. Исследования позволили отказаться от части невостребованных функций и решений еще до начала их разработки, а также сократить объем работ по изменениям, которые не создавали достаточной ценности для пользователей.
Удовлетворенность пользователей (SUM) — выросла на 26%. Исследования позволили выявлять проблемы в пользовательских сценариях и улучшать решения до их выхода в промышленную эксплуатацию.
Средняя конверсия по исследованным пользовательским сценариям — выросла на 12%. Проверка решений на пользователях позволила командам концентрироваться на изменениях, которые непосредственно влияли на выполнение целевых действий.

Вадим Врублевский
vrubleuski.com