My role

I led the development of a scalable banking details solution across multiple user journeys—onboarding, global account setup, and holder account management. This involved defining a clear information architecture and facilitating alignment between product, engineering, and support teams. A key challenge was establishing UX boundaries: determining which validations the system could handle automatically versus which details required explicit user confirmation to ensure accuracy and trust.

The challenge

Users
  • Entering banking details incorrectly is costly
  • No feedback when entering banking details
Business & regulatory constraints
  • Currency matching
  • Clearing and branch codes
  • Compliance tightness (regulator + bank rules)
  • UX must signal responsibility vs validation

Understanding

To understand the problem space, I partnered closely with a Business Analyst and Solutions Architect during discovery. The goal was to uncover the business logic, technical constraints, and regulatory requirements that would directly shape the user experience.

Through workshops and working sessions, we aligned on:

  • How clearing codes, branch codes, and currency validation behave at a system level
  • What the platform could reliably verify versus what must remain the user’s responsibility
  • Edge cases where users could not proceed and how those scenarios should be handled

Customer journey: Login to adding bank details

Refinement

This phase focused on de-risking the experience by translating complex backend rules into clear, understandable user flows. These insights informed:

  • End-to-end user journey mapping
  • Low-fidelity wireframes to test flow logic
  • High-fidelity designs ready for developer handover

This approach ensured the final designs balanced user clarity, technical feasibility, and regulatory compliance.

Customer journey: Login to adding bank details

IX flows: Wireframing banking feature

Clarifying system validation vs user responsibility

To reduce the risk of irreversible errors, the user is shown confirmation that their bank and branch details were matched in the system.

Executing the idea proved tricky. Design patterns such as modals, inline notifications and toasts all communicate the idea well. However, the pattern has to scale in the context of a multi-step page in onboarding and as a sheet once a user is onboarded. Using an inline notification provided users the most clarity on all journeys.

  • The notification confirmed the matched bank and branch details
  • Inputs were locked to prevent accidental changes
  • This created a clear moment of intent before submitting payment instructions

This pattern balanced safety with momentum, without overloading users with warnings. Lastly, this aligned with financial best practices and reduced downstream support issues.

Key decisions

Clarifying system validation vs user responsibility

A key decision was to explicitly separate what the system could validate (bank, branch, currency) from what the user must confirm themselves (account number accuracy and account name alignment).

  • Bank and branch lookup results were surfaced clearly to build user confidence
  • Account number entry remained a deliberate, user-owned step
  • Supporting copy reinforced responsibility without sounding punitive

This reduced ambiguity and helped prevent false assumptions about system validation.

High fidelity Figma handover specs: Full customer journeys

Reflection

Reduced confusion
  • Fewer support tickets, call centre traffic predicted to decrease
  • Visibility into what the system could/couldn’t verify
  • Increased confidence in user entries

The final experience provided users with a clear, predictable, and trustworthy flow for entering banking details.Key outcomes included:

  • Improved clarity around what the system validates versus what users must ensure
  • Reduced risk of incorrect bank detail submissions
  • Stronger user confidence through confirmation and review patterns
  • A design solution that development could implement cleanly with minimal ambiguity

While quantitative metrics were not available at the time, the solution was well-received by stakeholders and aligned with compliance and engineering expectations.

With future iterations, I would explore usability testing focused on:

  • User comprehension of responsibility messaging
  • Confidence levels at the review stage
  • Opportunities to further reduce cognitive load without compromising safety