Электронный архив документов

ПАО Банк ЗЕНИТ использовал устаревшее решение для электронного архива. Система хранила документы, но плохо адаптировалась под растущий объём данных, разные структуры хранения и новые бизнес-процессы.

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

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

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

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

Я участвовал в проекте на всех ключевых этапах: от сбора требований до дизайн-ревью после разработки.

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

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

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

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

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

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

1. Поиск документов и договоров

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

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

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

   Поиск документов и договоров

2. Поиск клиента и досье

   Я переработал сценарий поиска так, чтобы сотрудник мог начинать с тех данных, которые у него уже есть: ИНН, фамилии, идентификатора или другого параметра.

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

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

   Поиск клиента и досье

3. Досье клиента

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

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

   Так сотрудник видит не только структуру архива, но и доступные операции с конкретным документом.

   Досье клиента

4. Роли, группы и права доступа

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

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

   Роли, группы и права доступа

5. Метаданные и справочники

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

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

   Метаданные и справочники

6. Журнал активности

   Журнал активности должен был показывать, что произошло в системе: дату и время, событие, пользователя, результат запроса, объект и путь к нему.

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

   Для банковской системы это особенно важно. Журнал активности помогает разбирать спорные ситуации, проверять действия пользователей и восстанавливать цепочку событий.

   Журнал активности

7. Заявки и задачи внутри отделов

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

   На экране задачи отображается, какие документы нужно обработать, их идентификаторы, даты создания, статусы и маршрут перемещения. В примере сотрудник видит, что документы находятся в Москве и должны быть перемещены в Самару. Для каждого файла показан тип документа, чтобы исполнитель сразу понимал, с чем работает.

   В верхней части экрана добавлено основное действие — «Взять в работу». Так задача переходит от общего списка к конкретному исполнителю, а пользователь понимает, какое действие от него требуется сейчас.

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

   Заявки и задачи внутри отделов

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

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

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