Эскроу-счета: один продукт, два интерфейса

Контекст

Эскроу-счёт защищает деньги покупателя при покупке квартиры в новостройке или при покупке дома у подрядчика. Банк хранит средства, пока застройщик не сдаст дом, и только потом перечисляет их

В Сбере один и тот же продукт живёт в двух местах:

• Клиенты сами открывают эскроу-счета и управляют ими в мобильном приложении: открытие, дополнительные соглашения, возврат средств и смена счёта для возврата
• Сотрудники банка делают всё остальное в SBOL.pro — внутренней системе отделений на планшете и в вебе, обычно когда клиент сидит напротив: открытие, пополнение, уступка прав, закрытие, выписки и многое другое

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

Проблема

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

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

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

Ограничения

• Регулирование. Эскроу регулируется федеральными законами. Закрытие счёта работает по-разному в зависимости от закона, под который подпадает сделка (214-ФЗ или 186-ФЗ), от того, действует ли за клиента представитель, и от того, использовался ли материнский капитал
• Две платформы, две дизайн-системы. Одна бизнес-логика должна корректно работать в мобильном приложении и во внутренней системе на планшете и в вебе
• Разделённая зона ответственности. Часть точек входа и экранов принадлежит другим командам, поэтому отдельно приходилось договариваться, где заканчивается наш контроль
• Нехватка компонентов. В дизайн-системе не было паттернов для части сложных реестров и карточек счёта

Внутренняя система сотрудников банка полностью под NDA, поэтому здесь показаны только экраны клиентского приложения

Единый источник правды

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

Для реестров (счета, договоры, документы) я собрала справочник для фронтенда: чем отличаются похожие списки и карточки — названиями, атрибутами, визуальными состояниями. У разработки появилось одно место для сравнения паттернов, а я смогла поддерживать их как систему

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

Миграция как редизайн, а не перекраска

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

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

1. 1Точка входа

   Изменение условий договора начинается со страницы счёта

   
2. 2Новые условия от застройщика

   Клиент проверяет, что изменил застройщик. Отсюда можно продолжить, сообщить об ошибке или отказаться

   
3. илиСообщить об ошибке

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

   
4. илиОтказаться от изменений

   Причина обязательна: пустое поле переходит в состояние ошибки

   
5. 3Подписание

   Новые условия ещё раз, согласие и ссылка на сам документ

   
6. 4Готово

   Документы доступны в одно касание

   
7. 5Статус в истории

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

   

‹›

×

Ключевые решения

Открытие: путь вперёд вместо тупика

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

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

Возврат: сумму считает интерфейс, а не сотрудник

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

Пополнение: исправить логику, а не только экран

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

Закрытие с материнским капиталом: закон человеческим языком

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

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

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

Налоговое резидентство на двух платформах

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

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

• Система сотрудников: в проде с 6 апреля 2026
• Клиентское приложение: в проде с 30 апреля 2026

Объяснить налоговое резидентство простыми словами

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

Открытие в клиентском приложении

Так выглядит открытие в приложении с новым шагом: от проверки условий до экрана успеха

1. 1Проверка условий

   Клиент сверяет условия договора. Если что-то не так, он может сообщить об ошибке, а не застрять

   
2. 2Счёт для возврата

   Куда вернутся деньги, если сделка не состоится. Подходят только бессрочные счета или счёт в другом банке

   
3. 3Налоговое резидентство

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

   
4. 4Подтверждение

   Все условия, счёт для возврата и налоговое резидентство в одном месте перед подписанием

   
5. 5Готово

   Счёт скоро откроется. Подписанные документы доступны в одно касание

   

‹›

×

Ошибки и валидация

Если условия не совпадают с договором, клиент не упирается в тупик. Это та же идея, что и путь восстановления в системе сотрудников, только в клиентском приложении

1. 1Сообщить об ошибке

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

   
2. 2Валидация

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

   

‹›

×

Результат

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

В тот же период команда бэкенда исправляла обработку статусов, поэтому это не чистый A/B-результат. Он показывает, что новый обязательный шаг не ухудшил прохождение

Кроме цифр:

• Все описанные изменения работают в проде — в приложении или в системе сотрудников
• Макеты продукта стали общим справочником для бизнеса, разработки и QA
• Виджет, который я спроектировала для эскроу, теперь входит в общую библиотеку дизайн-системы

Что дальше

Системе сотрудников около пяти лет, и в ней накопился UX- и процессный долг. Я провожу по ней исследование: сначала продуктовая аналитика и clickstream, затем контекстные интервью в отделениях, затем модерируемые юзабилити-тесты с замером прохождения, ошибок, времени на задачу и простоты (SEQ). Результаты определят, что мы исправим в первую очередь