Резюме
Контекст
Платёжная система Банка России — внутренняя веб-платформа для ежедневной операционной работы, контроля и мониторинга платёжных процессов. Системой пользовались внутренние подразделения, работающие с большими объёмами данных в условиях строгих регламентов, требований безопасности и высокой цены ошибки.
Это был продукт класса операционных и аналитических систем, где ключевую роль играют таблицы, формы ввода, статусы объектов и корректная работа с данными.
Что нужно изменить
Система работала в высокорисковом операционном контуре: ошибки в данных, непонятные статусы, непрозрачные ограничения по шагам и неочевидные права доступа могли приводить к задержкам, дополнительным проверкам и повышенной нагрузке на пользователей.
Задача дизайна заключалась не только в оформлении экранов, но и в том, чтобы сделать критичные сценарии более предсказуемыми:
- уменьшить вероятность ошибок при вводе данных;
- сделать причины блокировок и недоступных действий понятными;
- повысить прозрачность ролей и разрешений;
- унифицировать работу с формами, статусами и подтверждением действий.
Роль
Я отвечал за проектирование UX/UI ключевых экранов платёжной платформы: сценарии работы с таблицами, длинными формами, статусами, ролями и правами доступа.
- проектирование интерфейсов и пользовательских сценариев;
- проработка сложных форм ввода и связанных проверок;
- адаптация экранов под разные роли пользователей;
- развитие и доработка UI Kit под задачи платформы;
- совместная проработка решений с аналитиками и разработчиками.
Ограничения
Проектирование велось в условиях жёстких регламентов и высокой критичности пользовательских действий.
- соответствие внутренним правилам и печатным формам;
- высокая цена ошибки при вводе и подтверждении данных;
- строгая ролевая модель с разными правами доступа;
- заданная архитектура системы, которую нельзя было радикально менять;
- необходимость сохранять понятность интерфейса при большом количестве проверок, статусов и ограничений.
Решения
Основной фокус был на снижении вероятности ошибок, прозрачности системного поведения и унификации критичных сценариев.
Ошибки в критичных формах
В длинных и многошаговых формах цена ошибки была высокой: неверные данные, пропущенные поля и неочевидные требования могли останавливать сценарий и требовать повторной проверки.
Спроектировал формы с понятной логикой заполнения, валидацией по попытке продолжить, локальными сообщениями у полей и общим summary ошибок. Для части полей использовались справочники, автозаполнение и ограничения на ввод.
Сценарии стали более предсказуемыми: пользователи быстрее понимали, что именно нужно исправить и почему система не даёт перейти дальше.
Непонятные блокировки и статусы
В операционных сценариях пользователю важно сразу понимать, что уже сделано, что недоступно и по какой причине действие нельзя продолжить.
Добавил явные статусы действий, понятные причины блокировок шага и прозрачную логику недоступных действий в зависимости от состояния объекта или этапа процесса.
Интерфейс стал лучше объяснять своё поведение, а количество неоднозначных ситуаций для пользователя снизилось.
Риск ошибочных массовых действий
Массовые операции повышали риск случайного подтверждения неверного действия и могли затрагивать сразу несколько объектов.
Для критичных массовых действий использовал явные предупреждения и отдельные модальные подтверждения перед выполнением операции.
Сценарии стали безопаснее: пользователь получал дополнительную точку проверки перед необратимым действием.
Непрозрачные роли и права доступа
При сложной ролевой модели пользователю важно понимать, какие действия ему доступны и почему часть функций скрыта или недоступна.
Спроектировал более прозрачное отображение ролей, прав и разрешений в интерфейсе, чтобы ограничения читались как часть логики системы, а не как случайное поведение.
Снизилась когнитивная нагрузка: пользователю стало проще понимать свои возможности в системе и границы сценария.
Как мы внедряли решение
Решения прорабатывались в тесной связке с аналитиками и разработчиками, потому что многие изменения зависели от бизнес-логики, ограничений системы и регламентов.
- согласовывали требования к критичным сценариям;
- уточняли логику статусов, блокировок и прав доступа;
- проверяли, как ограничения отображаются в интерфейсе;
- унифицировали повторяющиеся паттерны в формах и действиях;
- расширяли UI Kit под реальные сценарии платформы.
Примеры интерфейса
Интерфейсы проектировались в тесном взаимодействии с аналитиками и разработчиками, с фокусом на снижение ошибок и удобство ежедневной работы пользователей.
UI Kit
Для проекта использовался существующий UI Kit, который я расширял и дорабатывал под задачи платёжной системы.
Результаты
Масштаб
- 10 ключевых форм и единые принципы их проектирования;
- 5+ пользовательских ролей с разными правами и сценариями;
- критичные операционные действия, статусы, проверки и подтверждения;
- развитие существующего UI Kit под задачи платёжной платформы.
Эффект
- интерфейс стал более предсказуемым в сценариях с высокой ценой ошибки;
- пользователям стало проще понимать причины блокировок и недоступных действий;
- валидации и подтверждения помогли снизить риск неверных данных и случайных действий;
- единые UI-паттерны упростили развитие экранов и поддержку продукта.
Выводы
Этот проект показал, что в высокорисковых операционных системах хороший UX — это не про визуальную лёгкость, а про предсказуемость, прозрачность и снижение вероятности ошибки.
- понятные статусы и ограничения;
- безопасная работа с критичными действиями;
- ясная логика форм и валидации;
- прозрачное отображение ролей и прав доступа.
Именно такие решения делают сложную внутреннюю систему управляемой в ежедневной работе.