2️⃣ Операционная прозрачностьКак выглядит процесс международного перевода в одном из моих банков:
• Заполняю все нужные реквизиты для перевода и подтверждаю с помощью OTP;
• Наступает пауза, в которую ничего не происходит (деньги не списываются, банк ни о чем меня не уведомляет);
• Пишу письмо личному менеджеру в отделении банка, где сообщаю, что я вообще-то там перевод заполнил;
• Менеджер что-то делает и, обычно, в течение суток деньги отправляются через SEPA (система, которая сделана для того, чтобы деньги доходили за минуты);
• После того как я получаю SMS о том, что деньги списаны со счета — жду сутки и спрашиваю получателя, дошли ли до него деньги.
Это пример плохой операционной прозрачности. Стоит сравнить, например, с курьерской доставкой, где можно чуть ли не в реальном времени отследить — где сейчас находится курьер с посылкой. Посылка — физический объект, движущийся в реальном мире через десятки точек передачи. Деньги — запись в базе, которая знает свой статус в каждый момент. Парадокс в том, что в 2026 году отследить посылку проще, чем перевод.
Wise можно считать эталоном в прозрачности как полной стоимости перевода, так и всего операционного слоя. Вот пример таймлайна перевода. GoCardless использует похожее решение.
Жесткий контрпример — Robinhood. Пользователь увидел в интерфейсе баланс −$730 тыс — это было промежуточное состояние расчётов по опционам, реального долга не было. Но UI этого не показывал, вместо поддержки — был получен шаблонный ответ. История закончилась трагедией, иском семьи и рекордным в истории FINRA штрафом — $70 млн.
Robinhood — крайний случай, но механика везде одна. Большинство финтех-проектов построены на взаимодействии множества систем и в сценариях пользователя много точек, где процесс может затянуться, оборваться, пойти по неожиданному сценарию.
Статусы переводов, таймауты, ошибки банка-партнера, отказы скоринга, частичные зачисления, реверсы, конверсионные расхождения, «зависшие» транзакции — каждое из этих состояний однажды наступит и важно знать, что в этот момент пользователь увидит.
Без ответа на этот вопрос последствия не заставят себя долго ждать:
• Рост нагрузки на поддержку;
• Потеря доверия после первого же сбоя (вернуть доверие, как известно, дороже, чем его заработать);
• Репутационные риски — один завирусившийся тред о том, что деньги пропали на три дня и бренд теряет доверие даже среди тех, кто не был клиентом.
Проектирование статусной модели, точек входа и выхода, реалистичных таймаутов — это все важная часть качественного UX.
В макетах Figma такое рисовать скучно, в демо-режиме эти ситуации не всплывают, поэтому проработку стабильно откладывают на потом.Стоит проектировать это все в момент работы над фичей как часть продукта, а не как корнер-кейсы в беклог.
Что можно сделать на практикеПеред тем, как брать новый сценарий в работу:
• Какие состояния может принимать операция между инициацией и финальным статусом? Какие типы ошибок возможны?
• Какие SLA у систем, задействованных в операции, и как это правильно коммуницировать клиенту?
• Кто и как ведёт коммуникацию с клиентом в момент инцидентов — продукт, маркетинг, поддержка?
Чекап операционного слоя для уже работающих сценариев:
• Стоит проверить, правильно ли заполняются паузы: 2 секунды, минута, сутки — это совершенно разное поведение интерфейса. Выяснить, нет ли минутной паузы там, где предполагалось 2 секунды, и т.п.;
• Все типы встречающихся ошибок должны адекватно обрабатываться. Ошибки пользователя лучше предотвращать заранее, а ошибки системы должны объяснить пользователю, что ему с этим всем делать дальше;
• Полезно убедиться, что проработаны все выходы из сценария: пользователь может сам закрыть окно или даже приложение, либо ошибка системы приведет к зависшему сценарию — продумать, как вернуть пользователя в сценарий, чтобы не начинать все заново;
• Статусная модель в продукте, бэкенде и поддержке — совпадает (то есть поддержка видит то же, что и пользователь).
Качество работы финтех-команды проверяется не на happy path, а на той минуте, когда у пользователя что-то пошло не так. 
