На главную
2024 → сейчас B2E · Web Старший продуктовый дизайнер

Корпоративная платформа для работы с клиентскими данными

Внутренний сервис Сбера: 30 000+ пользователей ежедневно.
Отвечал за архитектуру, ключевые сценарии и дизайн-команду.
Шесть систем объединены в одну, аудитория выросла в 15 раз.

30 000+

пользователей ежедневно

×15

рост аудитории

6 → 1

систем объединено

78% → 84%

CSI

 / 09
Обзор платформы — главный экран
Карточка клиента
Продуктовый модуль — поиск продуктов клиента
Модуль согласий — поиск согласий клиента
Госорганы — обновление данных юридических лиц
Контрагенты — поиск контрагентов
Контрагенты — экспресс-анализ
Контрагенты — тендеры и госзакупки
Быстрый поиск

01 — Контекст

Шесть систем, один сценарий и 12 ролей

Когда я пришёл, продукт покрывал часть сценариев, им пользовались ~2 000 человек. Задача — собрать функциональность в одно решение, стандартизировать сценарии и снизить порог входа.

Ограничения

  • Регуляторика: нельзя сокращать состав данных и шаги проверок
  • Легаси с разными моделями данных и правами доступа
  • 2 000 человек уже работают ежедневно — ломать привычное нельзя
  • 12 ролей с разным уровнем доступа

Моя роль

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

02 — Архитектура

Как не утонуть в 30+ разделах

Шесть систем нельзя было «сложить» — получилось бы меню на 30 пунктов. Собрал структуру вокруг сущности «клиент»: верхний уровень — домены (клиенты, продукты, согласия, проверки), внутри — сценарии, а не разделы исходных систем.

Отвергнутые варианты

  • Плоское меню — 30 равнозначных пунктов
  • Деление по исходным системам — переносит легаси в новый продукт
  • Деление по частоте — структура меняется под каждую роль

Проверка: карточная сортировка, 20 участников — по итогам поменял уровни вложенности

Навигация по доменам
Итоговая структура: четыре домена, внутри — сценарии

03 — Пример фичи

Форма создания клиента:
30 полей, которые нельзя убрать

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

Проблема

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

Корень

Форма не отвечала на два вопроса: «сколько ещё осталось» и «что обязательно именно для этого клиента».

Ограничение

Состав полей продиктован регуляторикой: классический ход «сократить форму» не подходит. Задача — сделать длинную форму предсказуемой, не делая её короче.

Решение

  1. 1Форма разбита на логические секции, сгруппированные по источнику данных: секция совпадает с документом, который лежит перед менеджером
  2. 2Правая навигация как карта формы: все секции видны сразу, под каждой — сколько обязательных полей осталось
  3. 3Счётчик прогресса по обязательным полям
  4. 4При смене типа клиента или страны состав секции пересобирается, навигация обновляет счётчики
  5. 5Контекстные подсказки там, где цена ошибки высока: ИНН, ОГРН, основной код ОКВЭД

Развилка

  • Пошаговый визард — ломает сценарий «заполнить частично и вернуться»: данные приходят от клиента вразнобой
  • Аккордеон — скрывает объём работы и появление новых обязательных полей

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

Было — форма одним полотном
Было: все поля подряд, обязательность непонятна
Стало — секции, навигация, прогресс
Стало: навигация показывает остаток по каждой секции

Масштаб

60 менеджеров, около 700 карточек в месяц. По данным поддержки и интервью число обращений снизилось на 30%.

Проверка

9 сессий юзабилити на прототипе — по итогам перенёс счётчик из шапки в правую колонку.

Результат

Доля карточек, заполненных с первого раза, выросла на 25%, обращений в поддержку стало меньше на 30%.

Разбор фичи целиком

04 — Пример фичи

Управление доменами данных и AI-пространство

От ручного разбора структуры данных — к визуальной навигации и работе через AI. От концепта до демо за неделю.

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

Две разные боли

  • Владельцы доменов вели структуру во внешних документах: связи держались в голове, изменение в одном месте ломало понимание в другом
  • Обычные пользователи не могли применить домены: за ответом по выборке шли в Excel и сводили руками

Ключевой инсайт

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

01

Управление доменами

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

02

AI-пространство

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

03

Шаблоны промптов и роли

Повторяющиеся запросы сохраняются и переиспользуются. Владельцы получают управление и AI-пространство, остальные — только AI-пространство.

Граф связей домена
Структура домена: связи между уровнями атрибутов
AI-пространство
Диалог с данными в границах выбранных доменов
3 000

доменов и атрибутов

54 / 3 500

владельцев и пользователей

25 → 13 мин

время на задачу

Разбор фичи целиком

05 — Пример фичи

Массовые операции по филиальной сети

Ручная обработка 25–30 юрлиц превратилась в одну управляемую операцию: 3,5 часа → 10 минут.

Компании филиальной сети связаны общим ИНН. Если банкротом признавался один филиал, статус проставляли всем остальным вручную, по карточке. Пропущенный филиал — финансовое решение по компании с неактуальным статусом.

Компромисс

Защищал полную автоматизацию — безопасность отклонила: необратимое массовое изменение критичных данных не должно происходить без подтверждения оператора. Переработал в контролируемый сценарий: ввод ИНН → список затрагиваемых компаний → подтверждение.

Точка входа

Система сама находит банкротство в сети при работе с ИНН и предлагает распространить статус.

Контроль вместо скорости

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

Прозрачность выполнения

Прогресс с количеством обработанных компаний: массовая операция без обратной связи — источник тревоги.

Сайдпейдж со списком затрагиваемых компаний
Форма данных о банкротстве
3,5 ч → 10 мин

обработка сети

25–30

юрлиц в одной операции

0

пропусков филиалов — исключено логикой

Разбор фичи целиком

06 — Система и команда

Дизайн-система и команда из одного дизайнера в три

Развил дизайн-систему на базе Ant Design: компоненты, состояния и процесс работы с ней в команде — меньше UI-ошибок, быстрее сборка экранов.

Начинал единственным дизайнером, собрал команду из трёх: дизайн-ревью, кросс-ревью, единый стандарт качества.

Фрагмент дизайн-системы
Библиотека компонентов и их состояний

07 — Результат

Что изменилось за два года

  • 2 000 → 30 000+

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

  • CSI 78% → 84%

    За год, данные по 27 000 людям

  • 2 недели → 4 дня

    Обучение новичков

  • 6 → 1

    Сервис заменил шесть систем и стал основным рабочим инструментом

Часть интерфейсов и цифр скрыта из-за NDA — подробно расскажу на встрече.

Расскажу детали, которые не попали в кейс

Про исследования, компромиссы и то, как решения защищались перед стейкхолдерами.

Все кейсы