Проблема
Все поля на одном экране, часть появляется динамически. Менеджер заполнял сверху вниз, в конце получал ошибку валидации и терял контекст.
Внутренний сервис Сбера: 30 000+ пользователей ежедневно.
Отвечал за архитектуру, ключевые сценарии и дизайн-команду.
Шесть систем объединены в одну, аудитория выросла в 15 раз.
пользователей ежедневно
рост аудитории
систем объединено
CSI
01 — Контекст
Когда я пришёл, продукт покрывал часть сценариев, им пользовались ~2 000 человек. Задача — собрать функциональность в одно решение, стандартизировать сценарии и снизить порог входа.
Ограничения
Информационная архитектура, ключевые сценарии, еженедельные интервью с пользователями, исследования и защита решений перед стейкхолдерами. Курировал двух дизайнеров.
02 — Архитектура
Шесть систем нельзя было «сложить» — получилось бы меню на 30 пунктов. Собрал структуру вокруг сущности «клиент»: верхний уровень — домены (клиенты, продукты, согласия, проверки), внутри — сценарии, а не разделы исходных систем.
Отвергнутые варианты
Проверка: карточная сортировка, 20 участников — по итогам поменял уровни вложенности
03 — Пример фичи
Переработал структуру формы, не тронув ни одного поля — регуляторика не позволяла.
Все поля на одном экране, часть появляется динамически. Менеджер заполнял сверху вниз, в конце получал ошибку валидации и терял контекст.
Форма не отвечала на два вопроса: «сколько ещё осталось» и «что обязательно именно для этого клиента».
Состав полей продиктован регуляторикой: классический ход «сократить форму» не подходит. Задача — сделать длинную форму предсказуемой, не делая её короче.
Развилка
Менеджеры заполняют форму не линейно, поэтому нужен был не маршрут, а карта: единая форма с якорной навигацией и прогрессом.
60 менеджеров, около 700 карточек в месяц. По данным поддержки и интервью число обращений снизилось на 30%.
9 сессий юзабилити на прототипе — по итогам перенёс счётчик из шапки в правую колонку.
Доля карточек, заполненных с первого раза, выросла на 25%, обращений в поддержку стало меньше на 30%.
04 — Пример фичи
От ручного разбора структуры данных — к визуальной навигации и работе через AI. От концепта до демо за неделю.
Домены описывают группы атрибутов клиента: что входит, в каких форматах, с какими связями. Вложенность до четырёх уровней: домен → поддомен → логический → физический атрибут.
Две разные боли
Домен — не набор данных, а система связей. Владельцу её надо видеть, пользователю — применять. Одним интерфейсом задача не решается: нужны два сценария и разные права.
Редактирование структуры, статистика и граф связей вместо таблиц. Риск нечитаемости на объёме закрывал фильтрами, поиском с фокусом на узле и сворачиванием уровней.
Пользователь выбирает домены, подключает источники и работает с данными через диалог. Модель отвечает только в границах выбранных доменов — результат можно проверить.
Повторяющиеся запросы сохраняются и переиспользуются. Владельцы получают управление и AI-пространство, остальные — только AI-пространство.
доменов и атрибутов
владельцев и пользователей
время на задачу
05 — Пример фичи
Ручная обработка 25–30 юрлиц превратилась в одну управляемую операцию: 3,5 часа → 10 минут.
Компании филиальной сети связаны общим ИНН. Если банкротом признавался один филиал, статус проставляли всем остальным вручную, по карточке. Пропущенный филиал — финансовое решение по компании с неактуальным статусом.
Компромисс
Защищал полную автоматизацию — безопасность отклонила: необратимое массовое изменение критичных данных не должно происходить без подтверждения оператора. Переработал в контролируемый сценарий: ввод ИНН → список затрагиваемых компаний → подтверждение.
Система сама находит банкротство в сети при работе с ИНН и предлагает распространить статус.
Боковая панель со списком всех затрагиваемых компаний: пользователь впервые видит филиальную сеть целиком — этого не было и в ручном сценарии.
Прогресс с количеством обработанных компаний: массовая операция без обратной связи — источник тревоги.
обработка сети
юрлиц в одной операции
пропусков филиалов — исключено логикой
06 — Система и команда
Развил дизайн-систему на базе Ant Design: компоненты, состояния и процесс работы с ней в команде — меньше UI-ошибок, быстрее сборка экранов.
Начинал единственным дизайнером, собрал команду из трёх: дизайн-ревью, кросс-ревью, единый стандарт качества.
07 — Результат
Пользователей, подключено 7 новых подразделений — единая архитектура позволила масштабировать продукт без роста сложности
За год, данные по 27 000 людям
Обучение новичков
Сервис заменил шесть систем и стал основным рабочим инструментом
Часть интерфейсов и цифр скрыта из-за NDA — подробно расскажу на встрече.
Про исследования, компромиссы и то, как решения защищались перед стейкхолдерами.