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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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