Как мы упростили обработку документов и ускорили флоу на 24%
Сотрудники сопровождения бизнеса постоянно обрабатывают документы от клиентов. Интерфейс программы их только замедлял, от чего сотрудники возвращались к привычным локальным папкам. В этом кейсе я показываю, как мы пересобрали процесс и интерфейс вокруг реальных задач пользователей и доказали эффективность нового UX на тестах.
Компания
Банк ДОМ.РФ
Направление
Внутренний продукт
Тип
Web
Год
2025
Контекст
Я работала продуктовым дизайнером в Банке ДОМ.РФ в стриме проектного финансирования. Банк кредитует застройщиков, а сотрудники проверяют сотни файлов (акты, отчёты, сметы) на каждом цикле.
Сотрудники загружают документы от клиентов в локальные папки: сортируют, переименовывают, копируют для 20 смежных подразделений. Ручная обработка приводит к ошибкам и потерям.
Попытка цифровизации провалилась
В Личном кабинете сотрудников разработали модуль Досье клиента и инструмент обработки документов. По задумке, сотрудник должен был заполнять атрибуты, а система — автоматически распределять файлы по подразделениям.
Но из-за нехватки ресурсов первые макеты собирали бизнес-аналитики. На тестировании разработанного функционала пользователи жаловались на неудобный UX и потерю времени. В итоге релиз отменили.
Задача
Моя роль в проекте
Меня пригласили в проект, чтобы найти причины провала и пересобрать интерфейс. Я вела задачу end-to-end как продуктовый дизайнер: исследовала, проектировала, собирала кликабельные прототипы.
Совместно с командой (продактом, аналитиками, исследователем, лидом) мы приоритизировали гипотезы, проводили тестирование, прорабатывали корнер-кейсы и формировали скоуп решения.
Критерии успеха
Аудит старого интерфейса
Я прошла весь путь пользователя на тестовом стенде и сразу поняла, почему сотрудники жаловались.
Процесс состоял из 15+ шагов и был перегружен лишними кликами: одни и те же файлы приходилось выбирать дважды, а быстро отредактировать уже заполненные атрибуты было нельзя.
Листайте карусель, чтобы увидеть масштаб проблемы 👉
Что говорят пользователи
До моего прихода команда провела тесты с 10 сотрудниками. Я проанализировала результаты тестов, выписала все комментарии на доску и сгруппировала боли.
Мои выводы полностью подтвердились, но пользователи подсветили еще критичные проблемы. В итоге получился такой набор проблем ⚠️:
Анализ структуры данных
Логика работы в Досье: сотрудник выбирает тип документа → появляются нужные поля (атрибуты). Чтобы оценить максимальный размер формы, я составила полный маппинг данных.
Всего в системе насчитала 540+ типов документов! Внутри одного типа может быть до 20 полей. При этом часть полей общие и повторяется, а часть — уникальные для разных типов.
Предугадать длину формы оказалось невозможно. А значит, новый интерфейс должен быть максимально гибким, чтобы выдерживать любые сценарии обработки документов.
Задачи пользователей
После дискавери стало понятно, что проблема не в отдельных экранах, а в логике процесса целиком. Я перевела боли пользователей в 6 конкретных задач, которые должна закрывать система.
Гипотезы
Чтобы закрыть эти задачи, нужно было полностью переосмыслить архитектуру и отказаться от модалок и шагов. Я сформулировала две ключевые гипотезы, на которых построила логику нового интерфейса:
Концепция
Я собрала lo-fi прототип, чтобы проверить гипотезы на практике. Основой стала двухколоночная структура: слева — реестр файлов, справа — панель атрибутов.
Приоритизация и скоуп MVP
В процессе работы над концептом я продумала множество интерфейсных улучшений, но нам нужен был быстрый запуск. Чтобы не блокировать разработку, вместе с командой продукта и разработки мы прогнали все идеи через формулу Value / Effort (Ценность / Сложность).
Мы отложили сложные в реализации фичи, вроде Drag&Drop и прогресса. В MVP вошло только смысловое ядро, которое решает главные боли пользователей.
Дизайн первой версии
В первой версии я сфокусировалась на базовых сценариях, чтобы быстрее отдать их в разработку и проверить на пользователях. Параллельно мы проработали сложные системные корнер-кейсы.
1. Два режима заполнения атрибутов
2.Быстрые действия над файлами
3.Прозрачная работа с ошибками
Количественный замер
Прежде чем идти к пользователям, мы с командой (я, лид, продакт, аналитики и исследователь) провели внутреннее тестирование. Каждый прогнал базовый сценарий обработки 7 документов по 3 раза в старом и новом интерфейсе.
Юзабилити-тестирование
Количественный замер доказал ускорение, но не отвечал на вопрос «стал ли интерфейс удобнее?». Чтобы это выяснить, мы провели юзабилити-тесты с 10 сотрудниками, которые тестировали прошлую версию.
Квест с доступами: У респондентов был закрыт доступ к Figma из-за политик безопасности. Чтобы тесты состоялись, я транслировала прототип в TrueConf и передавала управление своим экраном участникам 🤷♀️
Доработки после тестов
После тестирования я внесла минорные доработки: добавила кнопку «Применить» в правую панель, чтобы снять страх потери введенных данных, доработала контекстное меню групп и переписала тексты уведомлений, чтобы убрать неоднозначность.
Передача в разработку
Новый интерфейс — это единое пространство без модалок, где возможны десятки комбинаций действий пользователя. Чтобы разработка не сошла с ума, а аналитика ничего не упустила, я:
Довела все макеты до финального состояния (с учетом корнер-кейсов)
Собрала подробные User Flows для каждого сценария (загрузка, атрибутирование, ошибки, группы)
Итоги
Что дальше?
Функционал находится в активной разработке — команда использует макеты, user-flows и спецификации. После релиза первой итерации планируется:
И затем вернуться к отложенным фичам и идеям от пользователей после тестирования.
Что я вынесла из проекта
