Scaling a Back Office for a Growing Payment Platform
Redesigning data-heavy workflows, mobile transaction management, analytics, and self-service financial operations for a growing B2B payment product.
CLIENT
XGateway
segment
B2B
Industry
Fintech
Context
XGateway is a fintech company and payment solutions provider. Through the back office, merchants track transactions, manage accounts and funds, perform financial operations, and generate reports.
Challenge & My Role
After the MVP launch, the product kept growing while the original interface struggled to support increasing data volumes and new workflows.
The goal was to scale the core experience for more complex use cases, make key workflows accessible on mobile devices, and create a reusable component foundation for future product development.
Working closely with Product, Business Analysts, and Engineering, I analyzed requirements and user feedback, designed UX flows and responsive behavior, made UI and component decisions, and supported implementation through design reviews.
Discovery & Prioritization
We used several existing sources of evidence:
support requests;
customer feedback collected during calls;
an audit of the existing interface;
competitor analysis.
We identified four main problems.
Difficult transaction search. Only five records were visible at a time, while limited filtering options were hidden inside a menu.
Difficult data interpretation. Users contacted support to clarify account names, balances, and account activity.
Limited scalability. Fragmented UI patterns and components made it harder to introduce new features consistently.
Limited mobile usability. Users needed access to transactions and reports outside desktop, but key data-heavy workflows had not been adapted to smaller screens.
We started with Dashboard, Accounts, and Transactions, as heatmap data showed that these were the most actively used areas.
Due to time constraints, we did not conduct separate user interviews or usability testing. Decisions were based on existing feedback, the interface audit, available product data, and team knowledge.
Working Hypotheses & Design Principles
UX hypotheses:
Making key filters visible and increasing table density would help users find transactions more efficiently.
Clearer statuses, labels, and time-period controls would make financial data easier to interpret.
Adapting key workflows for smaller screens would allow merchants to complete essential tasks on mobile devices.
Design principle
Reusable components would reduce fragmented UI patterns and make future product development more consistent.
These assumptions guided the redesign, but their individual impact was not measured.
1. Transaction Tables & Search
I increased table density, improved information grouping, and moved key filters into a persistent, visible area.
We expanded search parameters and designed period selection, pagination, clearer statuses, and more understandable labels.
The data structure and filtering logic were defined together with Business Analysts and developers, balancing user requests with technical constraints. The same approach was later applied to Accounts and Invoices.
2. Analytics & Reporting
Users needed a clearer overview of key account activity and a faster way to analyze data across different time periods.
We consolidated key metrics on the dashboard, added time presets, and introduced report exports. The set of metrics was defined together with Product and Business Analysts.
Some more complex visualizations were postponed because of delivery timelines and engineering capacity.
3. Designing Data-Heavy Workflows for Mobile
For mobile transaction tables, we compared three approaches.
Horizontal scrolling. Preserved the tabular structure and made it easier to compare multiple transactions, but required horizontal navigation.
Cards. Made individual transactions easier to read vertically, but consumed more space and made cross-row comparison harder.
Accordions. Reduced the amount of visible information, but required users to open rows to access additional values.
Decision
We chose a horizontally scrollable table. A key user need was comparing multiple transactions across the same parameters, so preserving the table structure was more important than keeping every column visible at once.
To make the pattern work on smaller screens, I:
kept the first column fixed to preserve row context;
moved secondary information into a bottom Details panel;
grouped secondary actions into an overflow menu;
adapted navigation behavior for desktop, tablet, and mobile.
The solution preserved the original data structure, although the usability of horizontal scrolling and the discoverability of hidden actions still needed validation.
4. Enabling Self-Service Financial Operations
As the product evolved, merchants needed to complete payouts and settlements without contacting Support for confirmation.
I designed a self-service flow covering: data entry → validation → confirmation → 2FA → processing → success / failure.
The flow included modal sequences for data entry and validation, operation confirmation, final states, and two-factor authentication. I aligned the interaction logic with Business Analysts and Engineering.
Outcome:
After launch, merchants were able to complete payouts and settlements independently, without requesting manual confirmation from Support.
Alongside the redesign, I built a reusable UI kit with key components, variants, and states. I also designed empty states for new merchants without transaction history.
The components were implemented in the product and became the foundation for further interface development.
At this stage, it was still a component library rather than a fully mature design system: usage guidelines, governance, and maintenance rules still needed to be defined.
During development, I conducted design reviews and adapted solutions as requirements evolved. Some features were simplified or moved to later release stages.
Outcome
Most of the proposed changes made it into the product:
expanded transaction search and filtering;
analytics presets and report exports;
clearer transaction data and statuses;
responsive layouts for key workflows;
self-service flows for financial operations;
a reusable component library.
According to Support data, in the first month after launching the self-service payout and settlement flows, support requests related to these operations dropped by approximately 60%.
I did not have access to post-release data on task completion time or task success rate, so I do not attribute broader usability improvements to the redesign without supporting data.
What I’d Do Differently
Define success criteria upfront: task completion time, task success rate, status comprehension, and the need to contact Support.
Prototype-test the highest-risk workflows: mobile transaction search and comparison, report export, and financial-operation confirmation.
Align the release scope earlier so complex visualizations could be introduced when fully ready rather than temporarily replaced with simplified solutions. v2 project backoffice
