Мои три уровня проектирования UX для финтеха

Три уровня проектирования, на которых мы строим фундамент UX для финтех сервисов:

1. Регуляторный уровень;

2. Операционная прозрачность;

3. Уровень доверия пользователей.

Без них любой дизайн в финтехе — это UX поверх пустоты. Менять местами не рекомендую.

Меня зовут Павел, я основатель Module Agency, за 15+ лет в дизайне через меня прошло больше 50 финтех-продуктов — необанки, платежные сервисы, депозиты, чекауты, BNPL и рассрочки, карточные продукты, — в командах вроде AliExpress, Uzum Bank, VK Pay. Все три уровня ниже — не теория, а то, обо что регулярно спотыкались мы сами и продукты, которыми занималась моя команда. Мой telegram канал «Паша, ты на мьюте» ･ LinkedIn

1. Регуляторный уровень

Регистрация, перевод, выдача кредита, подключение карты — каждый сценарий имеет свои требования регулятора: KYC, SCA, AML, ограничения по суммам и др.

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

• неоптимальный UX с плохой конверсией;

• дополнительные траты на разработку;

• риск штрафов от регулятора.

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

Monzo не просто сделали видео-KYC, а придумали фразу, которую пользователь произносит на камеру: «Меня зовут •••••, я хочу открыть аккаунт в Monzo». Это закрывает требование FCA по идентификации, работает как сигнал доверия и стало фирменной чертой банка, у которого уже 15 млн клиентов.

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

Nu (Nubank) показывают анимацию, как правильно сфотографировать документ и сделать селфи, а сам снимок сверяют с общей базой биометрии банков и ритейлеров Бразилии — Unico. Требование по идентификации превратилось в антифрод-слой, который работает на всю индустрию — и дал Nubank рост до 131 млн клиентов к концу 2025.

Что стоит сделать на практике

Первое. Составить чек-лист вопросов юристам перед тем, как брать сценарий в работу:

• какой минимальный набор данных нужно собрать на этапе регистрации, а что можно отложить;

• какие пороги по суммам триггерят дополнительные проверки и где они зафиксированы;

• что делать, если автоматический скоринг сработал на пользователе — отказать молча или объяснить.

Второе. Сделать чекап регуляторного уровня и проверить, что:

• команда может быстро ответить, какие регуляторные требования закрыты текущими макетами (это должно быть задокументировано);

• юридические тексты прошли через юристов, а не написаны маркетингом;

• в backlog нет тикетов с тегом compliance старше месяца;

• в команде понятно, какие изменения нужно согласовывать с юристами, а какие можно катить самостоятельно.

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

2. Операционная прозрачность

Как выглядит процесс международного перевода в одном из моих банков:

• Заполняю все нужные реквизиты для перевода и подтверждаю с помощью OTP;

• Наступает пауза, в которую ничего не происходит (деньги не списываются, банк ни о чем меня не уведомляет);

• Пишу письмо личному менеджеру в отделении банка, где сообщаю, что я вообще-то там перевод заполнил;

• Менеджер что-то делает и, обычно, в течение суток деньги отправляются через SEPA (система, которая сделана для того, чтобы деньги доходили за минуты);

• После того как я получаю SMS о том, что деньги списаны со счета — жду сутки и спрашиваю получателя, дошли ли до него деньги.

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

Wise можно считать эталоном в прозрачности как полной стоимости перевода, так и всего операционного слоя. Вот пример таймлайна перевода. GoCardless использует похожее решение.

Жесткий контрпример — Robinhood. Пользователь увидел в интерфейсе баланс −$730 тыс — это было промежуточное состояние расчётов по опционам, реального долга не было. Но UI этого не показывал, вместо поддержки — был получен шаблонный ответ. История закончилась трагедией, иском семьи и рекордным в истории FINRA штрафом — $70 млн.

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

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

Без ответа на этот вопрос последствия не заставят себя долго ждать:

1. Рост нагрузки на поддержку;

2. Потеря доверия после первого же сбоя (вернуть доверие, как известно, дороже, чем его заработать);

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

Проектирование статусной модели, точек входа и выхода, реалистичных таймаутов — это все важная часть качественного UX.

В макетах Figma такое рисовать скучно, в демо-режиме эти ситуации не всплывают, поэтому проработку стабильно откладывают на потом.

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

Что можно сделать на практике

Перед тем, как брать новый сценарий в работу:

1. Какие состояния может принимать операция между инициацией и финальным статусом? Какие типы ошибок возможны?

2. Какие SLA у систем, задействованных в операции, и как это правильно коммуницировать клиенту?

3. Кто и как ведёт коммуникацию с клиентом в момент инцидентов — продукт, маркетинг, поддержка?

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

1. Стоит проверить, правильно ли заполняются паузы: 2 секунды, минута, сутки — это совершенно разное поведение интерфейса. Выяснить, нет ли минутной паузы там, где предполагалось 2 секунды, и т.п.;

2. Все типы встречающихся ошибок должны адекватно обрабатываться. Ошибки пользователя лучше предотвращать заранее, а ошибки системы должны объяснить пользователю, что ему с этим всем делать дальше;

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

4. Статусная модель в продукте, бэкенде и поддержке — совпадает (то есть поддержка видит то же, что и пользователь).

Качество финтех-команды проверяется не на happy path, а на той минуте, когда у пользователя что-то пошло не так.

3. Уровень доверия пользователей

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

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

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

A. Полнота раскрытия

Комиссия указывается целиком и до операции, желательно на экране ввода суммы. Если она складывается из нескольких компонентов — комиссия третьей стороны, конвертация — указываются все. Плохой тон — прятать дополнительную комиссию в курс конвертации.

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

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

Wave (Сенегал) сделал плоский тариф в 1% для переводов, в то время как у местных операторов была сложная тарифная сетка от 5% до 10%. Конкуренты среагировали быстро и снизили стоимость переводов почти на 80%.

Atlantic Money (UK) довел эту идею до предела: фиксированная стомоисть перевода любого размера. А во ускоренная доставка стоит дополнительные 0,1%.

Условия соглашений живут в интерфейсе, а не только в PDF на тридцать страниц.

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

Apple Card показывает стоимость кредита в самом контроле выбора суммы платежа.

Б. Защита клиента

Функции, которые снижают выручку, но повышают доверие.

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

Nu провел опрос о безопасности и выяснил: перед выходом из дома клиенты выходят из приложения, снижают лимит по карте, кто-то вообще оставлял смартфон дома и брал с собой второй. В ответ появился режим Modo Rua (Street mode), позволяющий выбрать доверенные wi-fi сети, вне которых приложение ограничивает суммы переводов, а сверх лимита требует face id. 

Раньше такие функции были чистой статьей расходов. Но после введения законов по борьбе с мошенничеством — отдельные функции стали просто обязательными:

• В UK платежные сервисы должны возмещать жертвам мошенничества до 85 тыс фунтов в течение 5 рабочих дней;

• В ЕС требуют проверку получателя перед выполнением перевода. Пользователь, который подтвердил перевод после предупреждения — несет убыток сам;

• В Сингапуре: период охлаждения на 12 часов после входа с нового устройства, мониторинг быстрого опустошения счета до подтверждения или удержанием на 24 часа. Ответственность распределяется каскадом: нарушил обязанности банк — платит банк, нарушил телеком — платит телеком, не нарушил никто — платит пользователь13;

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

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

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

В. Чувство меры

Доверие может рушиться не только от недостатка решений, но и от избытка.

Манипуляция. Drip pricing, усложненная отмена подписки, давление в сторону ненужных финансовых продуктов — то с чем сталкиваются почти все пользователи. Понятие "недобросовестный интерфейс" уже появляется в разных юрисдикциях.

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

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

Объяснение, когда нельзя объяснять. Есть ситуация, решение в которой будет противоречить всему, что написано выше — счет заблокирован по подозрению в отмывании. Регуляторный уровень запрещает раскрывать причину. Операционная прозрачность требует показать статус и сроки. Уровень доверия требует объяснения, которого дать нельзя.

Например в UK, с 28 апреля 2026 при расторжении бессрочного договора клиента нужно предупреждать за 90 дней с подробным объяснением причины (там, где это разрешено законом). Исключение — подозрение в финансовых преступлениях, там счет закрывается немедленно и без объяснений.

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

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

Работающий прием — вместо конкретного объяснения дать общее, которое можно вынести в отдельный документ, на который будет ссылаться экран.

Как измерить доверие?

Работают косвенные признаки:

• Доля первых операций на минимальную сумму (пользователи делают тестовую операцию);

• Обращения в поддержку в формате "деньги точно дошли?";

• Доля клиентов, которые держат в сервисе минимальные балансы;

• Drop off на экране подтверждения, а не на экране ввода данных (то есть пользователь дошел до конца и передумал).

И не стоит судить о доверии по отсутствию жалоб и вопросов в поддержку.

Что можно сделать на практике

Перед тем, как брать новый сценарий в работу нужно понять:

1. В какой момент пользователь видит итоговую стоимость со всеми компонентами, комиссиями и курсами конвертации?

2. Какие функции сервиса сделаны против выручки и являются продуктовыми требованиями?

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

4. Что видит пользователь, если операция остановлена по причине, которую нельзя называть?

5. Как происходит коммуникация в случае сбоев по вине сервиса?

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

1. Стоит пройти сценарий целиком и сверить, совпадает ли сумма на экране ввода с суммой на экране подтверждения. Расхождение на любом шаге — точка потери доверия, даже если оно раскрыто;

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

3. Все предупреждения в сценарии стоит пересчитать и оценить долю ложных срабатываний — именно она определяет, прочитают ли те, что сработали по делу;

4. Тексты, объясняющие отказ, блокировку и задержку, должны быть написаны заранее и пройти через юристов — эти экраны пользователь читает внимательнее всех остальных;

5. Метрики оценки доверия не должны сводиться к опросами и объему обращений.

Доверие формируется там, где сервис поступает не в свою пользу:

• Называет цену, которую выгоднее не называть;

• Блокирует операцию, на которой зарабатывает;

• Останавливается там, где дожать было бы проще всего.