Как доводить сложные задачи до конца, когда всё меняется на ходу: кейс переосмысления международных платежей в OTP Бизнес
Меня зовут Влада Ларионова, я продуктовый дизайнер в OTP Бизнес. Я работаю в трайбе Corporate & SME и отвечаю за решения для компаний, которые ведут внешнеэкономическую деятельность и регулярно отправляют и получают международные платежи.
Задача, о которой пойдёт речь, на первый взгляд казалась довольно узкой: сделать понятнее статусы международных переводов. На практике это оказалось историей про то, как в условиях постоянно меняющихся вводных не потерять фокус на пользователе, довести сложный проект до результата и при этом успеть в один спринт.
В этой статье я разберу:
- с какой реальной проблемой столкнулись клиенты;
- почему одних данных недостаточно, если они упакованы "по‑технически";
- как мы переосмыслили отображение статусов и траектории платежа;
- какие принципы помогли не утонуть в деталях и довести решение до конца;
- какие выводы можно применить к любому сложному B2B‑сценарию.
---
Исходная ситуация: статус есть, понимания нет
Международные платежи - это не моментальные переводы, к которым многие привыкли в розничном банкинге. Один платёж может пройти через цепочку банков-корреспондентов в разных странах и системах, а каждая точка по‑своему обрабатывает операцию, выставляет комиссии и возвращает собственные статусы.
Внутри системы у нас уже была достаточно подробная информация:
- на каком этапе обработки находится платёж;
- в каком банке он сейчас "застрял" или был отклонён;
- когда средства зачислены получателю;
- какие комиссии удержаны по цепочке;
- сколько времени заняла операция от отправки до зачисления.
Функциональность отслеживания движения международного платежа существовала. С точки зрения бэкенда всё было "корректно": статусы приходили, маппились, логировались. Но клиенты продолжали задавать один и тот же вопрос:
> "Где мой платёж?"
Деньги уже могли быть списаны со счёта, операция отправлена, но пользователь видел на экране технический статус, который скорее вызывал тревогу, чем помогал. Возникала когнитивная несостыковка:
- действие совершено (платёж отправлен),
- формально статус есть,
- но понимания, что происходит с деньгами, у человека нет.
Это приводило к двум последствиям:
1. Клиент тревожится и не чувствует контроля.
2. Поддержка получает поток однотипных обращений и тратит время на объяснения.
То есть проблема была не в отсутствии данных, а в том, как они были представлены и интерпретированы для человека, который не обязан разбираться в тонкостях международного клиринга и SWIFT‑сообщений.
---
Как мы чуть не ушли в "технический туннель"
На старте обсуждение быстро свернуло в сторону чисто технических вопросов:
- правильный маппинг международных статусов;
- точность соответствия кодов в системе;
- обработка редких и пограничных кейсов;
- нюансы отображения разных типов сообщений.
Это важные темы, без них не построить надёжный сервис. Но в какой-то момент стало ясно: мы обсуждаем систему с точки зрения системы, а не клиента. Мы постепенно потеряли главный фокус - что должен понять пользователь, открывая экран статусов.
Ключевой вопрос, к которому мы вернулись:
> "Если клиент посмотрит на этот экран, сможет ли он ответить себе двумя фразами:
> 1) где сейчас его деньги,
> 2) нужно ли ему что-то делать?"
Если хотя бы на один из этих вопросов ответ "нет", значит задача UX не решена, даже если технически всё безупречно. Пользовательский опыт не обязан показывать всю глубину бэк‑логики, его задача - объяснить происходящее человеческим языком.
---
Исследование: не не хватает данных - не хватает структуры
Я начала с анализа обращений на первую и вторую линии поддержки. Это были сотни диалогов, в которых клиенты формулировали одно и то же переживание разными словами:
- "платёж уже отправлен, но в системе непонятно, что с ним";
- "показывается какой-то непонятный статус, надо ли волноваться?";
- "средства списаны, но не ясно, когда получатель их увидит";
- "написано, что платёж в обработке, но что это значит по‑человечески?"
Главный инсайт:
пользователю не хватало не самой информации, а структуры и интерпретации.
Система говорила на языке кодов и технических статусов; клиенту нужен был простой, линейный и логичный рассказ:
- "Платёж отправлен из вашего банка";
- "Сейчас он обрабатывается банком‑корреспондентом";
- "Здесь платёж был приостановлен, вот почему";
- "Деньги зачислены на счёт получателя";
- "Комиссии удержаны такими‑то банками".
То есть нужно было не просто "вывести статусы", а:
1. Переосмыслить модель - как человек воспринимает путь денег.
2. Сформировать визуальный сценарий: движение от точки А к точке Б.
3. Перевести технический язык в понятные этапы и действия.
---
Баланс между прозрачностью и тревожностью
Отдельный пласт работы - диалог с бизнесом и экспертами по международным операциям. Естественное желание банка - показать всё, что мы знаем о платеже: каждый статус, каждый код, каждую комиссию, каждую дату. Это выглядит как максимальная прозрачность.
Но избыток необработанных подробностей в B2B‑продуктах часто даёт обратный эффект:
- повышает тревожность ("слишком много непонятных слов");
- создаёт ощущение сложности и риска;
- усложняет принятие решений.
Я отстаивала принцип:
> Показывать не всю доступную информацию, а только ту, которая помогает клиенту понять ситуацию и принять следующее действие (или спокойно ничего не делать).
Мы разложили сценарии по шагам и посмотрели:
- на каком этапе клиент должен просто наблюдать;
- когда ему важно знать, что платёж задерживается, и почему;
- когда ему нужно предпринять действие (например, связаться с контрагентом или менеджером);
- какие детали в конкретный момент не меняют его поведение и только нагнетают.
На основе этого мы решили:
- упростить формулировки статусов;
- сгруппировать сложные технические этапы в понятные пользователю фазы;
- убрать с первого плана то, что не влияет на решение;
- оставить глубину там, где она реально нужна (например, детализация удержанных комиссий).
---
Новый подход: не просто статус, а маршрут платежа
В результате мы создали новый компонент в дизайн‑системе - визуальный маршрут международного платежа. Это не просто строчка со статусом, а наглядный сценарий движения денег:
- Чёткие этапы пути: от отправки в нашем банке до зачисления получателю.
- Пошаговое отображение, через какие банки проходит платёж.
- Разделение зон, которые мы можем отследить, и тех, где данные ограничены (например, отдельные участки SWIFT‑цепочки).
- Фиксация момента, когда средства зачислены получателю.
- Отображение комиссий банков-корреспондентов и итоговой стоимости операции.
Клиент в своём личном кабинете теперь может:
- увидеть, где именно сейчас находится его перевод - в нашем банке, в банке-корреспонденте или уже у получателя;
- понять, какой участник цепочки приостановил или отклонил платёж, если это произошло;
- узнать, когда деньги поступили на счёт контрагента;
- оценить, какие комиссии были удержаны по пути;
- посмотреть, сколько в итоге заняла операция от создания до зачисления.
Сервис работает для исходящих международных переводов как внутри группы OTP, так и на счета сторонних банков. Основная цель - снизить неопределённость для клиентов ВЭД и сделать сложную инфраструктуру международных расчётов визуально и логически прозрачной.
---
Как уложиться в один спринт при высокой сложности
Отдельный вызов в этом проекте - жёсткие временные рамки. На рефакторинг логики отображения и интерфейса у нас был всего один спринт разработки. Для сложного B2B‑функционала это очень немного.
Что помогло не расползтись по задачам и довести решение до продакшена:
1. Жёсткий приоритезирующий вопрос
На каждом обсуждении мы возвращались к формуле:
"Это изменение помогает клиенту понять, где его деньги, или нет?"
Всё, что не давало прямого вклада в этот ответ, отправлялось в бэклог следующей очереди.
2. Слойность решения
Мы сразу спроектировали интерфейс многослойно:
- верхний уровень - понятные статусные фразы и визуальный маршрут;
- второй уровень - контекст: комиссии, даты, участники цепочки;
- третий уровень - технические детали для продвинутых пользователей и поддержки.
Это позволило не пытаться впихнуть всё в один экран, но при этом сохранить глубину для тех, кому она нужна.
3. Синхронная работа с бизнесом и техкомандой
Мы не делили проект на "сначала UX, потом реализация". Обсуждение шло параллельно: дизайнеры, аналитики, бизнес и разработчики одновременно уточняли требования, ограничения и возможности. Это сократило количество итераций и переделок.
4. Опора на реальные обращения клиентов
Вместо абстрактных "кажется, удобно/неудобно" у нас были конкретные формулировки запросов клиентов. Мы буквально проверяли прототипы на вопрос:
"Ответит ли этот экран на то, что человек писал в поддержку?"
---
Дополнительные эффекты: не только про статусы
Хотя проект был сфокусирован на визуализации движения платежа, в процессе проявились и другие важные эффекты:
- Снижение нагрузки на поддержку
Когда клиент видит наглядный маршрут и понимает, на каком этапе всё находится, у него меньше поводов писать или звонить. Часть запросов "где деньги?" превращается в "понял, что платёж в обработке, просто подожду".
- Рост доверия к сервису
Прозрачность в сложных сценариях усиливает ощущение контроля. Пользователь видит, что банк "держит руку на пульсе" операции на всём пути, а не исчезает после списания средств со счёта.
- Упрощение внутренних процессов
Новый визуальный компонент помогает не только клиентам, но и сотрудникам банка. Операционисты и менеджеры теперь смотрят на платёж в том же представлении, что и клиент, - это облегчает объяснения и синхронизирует картину мира.
- База для дальнейших улучшений
Структурированный маршрут платежа стал фундаментом для будущих развёрнутых аналитик: времени прохождения по каждому этапу, типичных точек задержек, статистики комиссий и т.д.
---
Как этот кейс масштабируется на любые сложные B2B‑продукты
Хотя речь идёт о международных платежах, принципы, которые мы использовали, применимы в широком спектре B2B‑сценариев: от логистики до управления контрактами.
Что можно перенять:
1. Не путать полноту данных с понятностью
Даже если система собирает "всё обо всём", это не значит, что пользователю нужно видеть эту же картину в сыром виде. Сначала должна быть модель понимания, потом - набор отображаемой информации.
2. Думать в терминах пути, а не статуса
В сложных процессах люди проще воспринимают "маршрут" - последовательность этапов от точки А до точки Б. Статусы сами по себе мало что объясняют, если не встроены в понятный сценарий.
3. Ограничивать уровень детализации в один момент времени
Пользователю не нужно всё и сразу. Сегодня ему важна стадия и необходимость действий, завтра - детали по комиссиям, послезавтра - отчёты. Важно спроектировать слои, а не свалку фактов.
4. Начинать с реальных вопросов клиентов
В любой сложной системе отличным ориентиром служат обращения в поддержку. Это концентрат непонимания. Если интерфейс отвечает на эти вопросы до того, как они возникнут, значит вы движетесь в правильном направлении.
---
Итоги и личные выводы
Работа над этим проектом ещё раз показала:
- В сложных финансовых продуктах очень легко увлечься технической точностью и забыть, что в конце цепочки есть человек, который просто хочет понять, что происходит с его деньгами.
- Данные сами по себе не создают ощущение контроля - это делает только понятный сценарий и ясный язык.
- Жёсткие ограничения по срокам - не всегда зло. Они заставляют постоянно отсекать лишнее и удерживать фокус на главном пользовательском результате.
- В B2B‑среде "прозрачность" - это не когда вы показываете всё до последнего байта, а когда клиенту в любой момент очевидно:
где он сейчас в процессе,
что происходит с его операцией,
и нужно ли ему что-то предпринять.
Переосмыслив отображение статусов международных платежей и превратив набор технических статусов в понятный маршрут, мы не просто "перерисовали экран". Мы помогли клиентам вернуть ощущение контроля в одном из самых чувствительных сценариев - когда крупные суммы путешествуют между странами и банками, а вокруг постоянно что-то меняется.
