Масштабирование back-office для растущего платёжного сервиса
Переработала ключевые B2B-сценарии — поиск транзакций, аналитику, мобильную работу и самостоятельное управление операциями — и собрала компонентную основу для дальнейшего развития продукта.
Клиент
XGateway
Сегмент
B2B
Индустрия
Финтех
Контекст
XGateway — финтех-компания и провайдер платёжных решений. Через back-office мерчанты отслеживают транзакции, управляют счетами и средствами, выполняют операции и формируют отчёты.
Задача и моя роль
После запуска MVP продукт рос, а интерфейс перестал соответствовать объёму данных и новым задачам. Нужно было быстро обновить основные разделы, поддержать работу с телефона и подготовить основу для новых функций.
Вместе с продуктом, бизнес-аналитиками и разработчиками я анализировала требования и пользовательскую обратную связь, прорабатывала UX-сценарии и адаптивное поведение, принимала решения по UI и компонентам и сопровождала реализацию через дизайн-ревью.
Discovery и приоритеты
В качестве входных данных использовали обращения в поддержку, обратную связь клиентов из звонков, аудит текущего интерфейса и конкурентный анализ.
Выявили четыре основные проблемы:
Сложный поиск транзакций: на экране помещалось пять записей, а ограниченные фильтры были скрыты в меню.
Сложная интерпретация данных: пользователи обращались за пояснениями о названиях аккаунтов, балансе и активности счёта.
Сложности масштабирования: разрозненные компоненты затрудняли добавление новых функций.
Ограниченная работа с мобильных устройств: пользователям требовался доступ к транзакциям и отчётам вне десктопа, но ключевые нагруженные сценарии не были адаптированы под маленькие экраны.
Начали с дашборда, счетов и транзакций — наиболее активно используемых страниц по данным тепловой карты.
Из-за сроков отдельные интервью и юзабилити-тестирование не проводились. Решения опирались на доступную обратную связь, аудит и знания команды.
Рабочие гипотезы и принципы
UX-гипотезы:
Видимые фильтры и более компактные таблицы помогут быстрее находить операции.
Понятные статусы, названия и выбор периода облегчат интерпретацию данных.
Адаптация ключевых сценариев позволит работать с кабинетом с телефона.
Системный принцип:
Переиспользуемые компоненты снизят количество разрозненных паттернов и упростят развитие новых функций.
Эти предположения определяли направление работы; их эффект не был измерен.
1. Таблицы и поиск транзакций
Я переработала плотность таблиц и группировку информации, вынесла основные фильтры в видимую область. Мы расширили параметры поиска, проработали выбор периода, пагинацию, статусы и названия.
Состав данных и фильтров согласовывали с бизнес-аналитиками и разработчиками, учитывая запросы пользователей и технические ограничения. Этот подход затем применяли к таблицам счетов и инвойсов.
2. Аналитика и отчёты
Собрали ключевые показатели на дашборде, добавили временные пресеты и экспорт отчётов. Состав метрик определяли вместе с продуктом и бизнес-аналитиками.
Часть сложных графиков отложили из-за сроков и загрузки разработки.
3. Работа с телефона
Для мобильных таблиц мы сравнили три подхода:
Горизонтальная прокрутка сохраняла структуру для сравнения операций, но требовала перемещаться по ширине экрана.
Карточки позволяли читать отдельную операцию вертикально, но занимали больше места и затрудняли сравнение.
Аккордеоны сокращали объём видимых данных, но требовали раскрытия дополнительных значений.
Выбрали таблицу с горизонтальной прокруткой, поскольку данных было много и их часто требовалось сравнивать.
Я зафиксировала первую колонку для ориентации в строках, перенесла часть столбцов в «Детали» — панель снизу экрана — и собрала действия в меню «⋯». Также адаптировала навигацию для компьютера, планшета и телефона.
Решение сохраняло структуру данных, однако удобство прокрутки и обнаружения скрытых действий ещё требовало проверки.
4. Самостоятельное управление операциями
По мере развития продукта появилась задача выполнять выплаты и settlements без обращения в поддержку для подтверждения.
Я проработала последовательность модальных окон: ввод и проверку данных, подтверждение операции и итоговые состояния, включая сценарии с двухфакторной аутентификацией. Логику согласовывала с бизнес-аналитиками и разработчиками.
После запуска мерчанты стали проводить выплаты и settlements самостоятельно, без запроса в поддержку на подтверждение.
Параллельно я собрала UI-кит с ключевыми компонентами, вариантами и состояниями. Отдельно проработала пустые экраны для новых клиентов без истории операций.
Компоненты внедрялись в продукт и стали основой для дальнейшего развития интерфейса. Для перехода к полноценной дизайн-системе ещё требовалось описать правила их использования и поддержки.
Во время разработки я проводила дизайн-ревью и адаптировала решения к меняющимся требованиям. Часть функций упростили или перенесли на следующие этапы.
Результат
БOльшая часть решений вошла в продукт: расширены поиск и фильтрация, добавлены отчёты и аналитические пресеты, уточнены данные и статусы транзакций.
Подготовлены адаптивные макеты, сценарии самостоятельного управления операциями и UI-кит.
В первый месяц после запуска количество обращений в поддержку по этим операциям было примерно на 60% ниже, чем до внедрения модальных окон settlements и withdrawals.
Пострелизных данных о скорости работы пользователей у меня не было.
Что бы я сделала иначе
Заранее определила бы критерии успеха: время и успешность выполнения задач, понимание статусов и необходимость обращения в поддержку.
Проверила бы ключевые сценарии на прототипе: поиск и сравнение транзакций с телефона, выгрузку отчёта и подтверждение операции.
Раньше согласовала бы состав релиза, чтобы сложные визуализации появлялись по готовности, без временных заглушек.
