Banking payments | Yash Design

From Pages to Possibilities

A user design case study on the website Project Gutenberg

Corporate Banking Payments, Cash Management & Trade Finance

Images and UI/UX artifacts are protected by non-disclosure agreements; conversations regarding these systems are always welcome .Conceptual imagery within this portfolio includes AI-generated assets.*

Overview

This project brought several corporate-banking activities like payments, cash management, and trade finance into one consistent digital experience, supporting customers across more than 120 countries. The users weren't retail banking customers checking a balance. They were finance teams, treasury users, payment operators, and approvers, and a single payment could carry a giant wall of information: beneficiary details, currency, value date, payment method, supporting documentation, and approval status.

The Challenge

Corporate payments come with real institutional weight behind them. A $250,000 supplier payment can't just be created and sent — it has to move through a maker-checker process, where the person who creates a payment often isn't the person authorized to release it. That handoff needs to be airtight: the maker needs to know exactly where their payment stands, and the checker needs everything required to make a confident approval decision, fast.

Layered on top of that were large transaction lists — sometimes thousands of payments per user — and failed transactions that, if left unexplained, would send people straight to a support call.

My Role

I worked as part of an offshore team with a Product Owner/BA, a UX lead, fellow UI/UX designers, frontend and backend engineers, QA, and a technical lead alongside client-side banking SMEs who walked us through the actual approval rules. Rather than jumping into screens, I started by sitting with the BA to understand the existing workflow, mapping it out in FigJam across payment creation, beneficiary selection, validation, approval, processing, and final status.

Designing the Maker-Checker Flow

For the maker, I designed clear, unambiguous states at every stage: Draft, Submitted for Approval, Rejected, Processing, Completed, or Failed so there was never a moment of "did this actually go through?"

For the checker, the approval screen surfaced what changed, who created the transaction, the amount, the beneficiary, and any validation warnings everything needed to approve responsibly, without digging for it

Handling Scale and Failure

For transaction lists running into the thousands, I focused heavily on search and filtering by account, beneficiary, date, amount, currency, and processing status — so finding one payment didn't mean scrolling through hundreds.

For failed transactions, I moved away from a flat "Payment failed" message and designed recovery states that told the user why: whether something needed correcting, whether the payment could simply be resubmitted, or whether it needed to go to bank support. A failure state that doesn't tell you what to do next isn't really an error message it's a dead end.

From Design to Implementation

I built wireframes and detailed screens in Adobe XD and Figma, then maintained reusable patterns for forms, tables, filters, confirmations, and status indicators so the system stayed consistent as it grew. Handoff went through Zeplin, with requirements, interaction rules, and edge cases documented in Confluence and tracked in Jira. During implementation, I used HTML, CSS, JavaScript, and Chrome DevTools to check that what shipped matched the design — particularly responsive behavior, table interactions, validation messaging, and keyboard navigation — and reviewed WCAG accessibility throughout, including focus states, keyboard access, and field labeling.

Outcome

Usability reviews showed roughly a 15% improvement in successful completion of tested transaction scenarios. Better filtering cut navigation effort for common transaction searches by about 20%, and clearer specs and handoff reduced repeated clarification and rework during implementation by around 15%.

But the number I'd point to first isn't any of those. It's this: workflows that normally look intensely technical became understandable to the people using them every day — without stripping out a single control that corporate banking actually requires.