International payments for business banking customers

Client: Allica Bank
Role: Senior Product Designer
Year: 2022
Tags: Mobile, Research, UX, UI

Allica's business banking customers could hold and move money across the UK, but not beyond it. This is the work that let them send money abroad without leaving the app.

The send international payment screen on a phone, showing 150 GBP converting to 176.02 EUR with the transfer fee and live exchange rate

Problem

Payments stopped at the UK border

Business banking customers could only make bank transfers within the UK. Anything international meant leaving Allica for a third party service, opening an account elsewhere and moving money out of the ecosystem in order to move it abroad.

For businesses that import, export or pay suppliers overseas, every international payment was a reason to keep another provider open alongside Allica.

Approach

Learning the rails before designing the screens

Workflow

How the project ran

Competitor analysis

API documentation analysis

Wireframing

UI exploration

Design system

Hi-fidelity design

Prototyping

Usability testing

Kick-off

Agreeing what we were building

The project started in Miro with a product manager and an engineer. We filled a product canvas to settle the goals, the metrics, the target group and the picture of the project, then ran a SWOT to be honest about the strengths, weaknesses, opportunities and threats attached to the feature.

Lastly we populated a MoSCoW board. It decided what had to be in the first release and what could wait, which mattered here because the feature sat on a partner's infrastructure and there was a limit to how much of it we could change.

A product canvas in Miro covering the name, goal, metrics, target group, big picture and product details of the international payments feature — The product canvas. SMEs as the target group and a goal of making international payments through the Allica app.

A SWOT analysis in Miro covering the strengths, weaknesses, opportunities and threats attached to the international payments feature — The SWOT, where we were honest about what the partnership gave us and what it cost us.

A MoSCoW board in Miro sorting the feature into must have, should have, could have and won't have — The MoSCoW board, which settled what made the first release and what waited.

Allica x Wise

Designing on someone else's rails

Allica partnered with Wise to enhance the payment capabilities it offered customers. That gave customers the ability to send internationally in multiple currencies including EUR, USD, INR and more and it gave me a fixed set of behaviours to design around.

I went through the API documentation and mapped the happy path with the engineers. Then came everything the documentation does not lead with: the unhappy paths, the fields each payment type demands and what happens when a customer needs a Wise account created before they can send anything.

We had regular touch points with the team at Wise to work through the API, the UX and the delivery requirements, so the parts we could not see from the documentation were answered rather than assumed.

A diagram of the Wise API happy path in eight steps, from choosing to send an international payment through creating or connecting a Wise account to the payment being sent — The happy path, in eight steps. Steps two and three only apply to a new user and the edge cases around them took the longest to map.

Competitor analysis

How others handle the same rails

To understand the Wise UX further, I looked at other FinTechs using Wise as their international payment solution: Wise itself, Up Bank in Australia and Aspire in Singapore. Wise showed the reference experience. The other two showed the more useful thing, which is how the flow behaves once it sits inside somebody else's banking product.

An annotated teardown of the Wise app's international payment flow, noting how it surfaces recently used currencies, the cost of each transfer type and a 31 day rate history — Wise, the reference experience, annotated.

An annotated teardown of Up Bank's international payment flow, built on Wise — Up Bank, an Australian FinTech running on the same rails.

An annotated teardown of Aspire's international payment flow, built on Wise — Aspire, a Singaporean FinTech, doing the same again.

Wireframes

Lo-fi first

Before working in hi-fidelity I explored the UX in lo-fi, which kept the focus on the information, the content and the flows. The same canvases carried the open questions and the errors and edge cases, so the gaps were visible rather than assumed.

Sharing lo-fi work with the other stakeholders at Allica and at Wise let us iterate, refine and correct the UX quickly, before any of it was drawn properly.

A lo-fi wireframe canvas for the new user flow, with open questions listed above it, the Wise account creation screens in the middle and an errors and edge cases section below — The new user canvas. The open questions sat above the flow and the errors and edge cases below it, so nothing was quietly assumed.

A lo-fi wireframe strip of the returning user flow, from the payments screen through the quote and review details to payment sent — The returning user flow, from the payments screen through to payment sent.

Solution

Sending money abroad, without leaving the app

Once the UX was settled I moved to hi-fidelity. What follows is the flow as it was designed, screen by screen.

The flow

From an empty state to a payment

A customer sending internationally picks a currency, enters an amount and gets a live quote before anything is committed. The payments screen carries the new option alongside a UK bank transfer and once a payment has been made the payee is saved, so the next one is a couple of taps.

The payments screen with an empty payee list reading you haven't paid anyone yet — Entering an amount and searching for a currency, then the payments screen before and after a first payee is saved.

The payments screen with a populated list of recent payees, showing both domestic and international payees — Entering an amount and searching for a currency, then the payments screen before and after a first payee is saved.

Quote

The screen that does the explaining

The quote screen is where customers enter the amount they want to send in their chosen currencies and where the fee, the live exchange rate and the arrival time become real. It works in both directions, so a customer can say what they want to send or what the recipient should get and the other side follows.

Amounts that will not go through surface here too, which is why the error states had as much attention as the happy path.

The quote screen with the amount being entered on the you send side — Both directions of the same quote, then what happens when the amount will not go through.

The quote screen with the amount being entered on the recipient gets side — Both directions of the same quote, then what happens when the amount will not go through.

Transaction details

Details that change with the payment

Details of an international payment are presented differently depending on the status of the payment and the currency. A EUR payment inside Europe does not carry the same information as the same payment sent outside it and a payment in flight does not show what a settled one shows.

I designed the details view as a set of variations on one layout rather than a screen per case, so the pattern holds however the payment is routed.

The my money screen showing account balances and recent transactions — One layout, adapting to currency, destination and status. EUR outside Europe carries the most detail of the three.

Transaction details for a pending EUR payment sent inside Europe — One layout, adapting to currency, destination and status. EUR outside Europe carries the most detail of the three.

Add payee

Every currency asks for something different

The payee details required depend on the currency and the country being sent to. EUR asks for an IBAN and USD asks for a routing number, while INR and CNY each ask for something else again.

The flow had to change shape around those differences without feeling like a different feature each time. Below are the completed states for four currencies.

The completed add payee form for a EUR payment, with an IBAN added — The final step of the same flow in four currencies. The fields differ, the pattern does not.

The completed add payee form for a USD payment — The final step of the same flow in four currencies. The fields differ, the pattern does not.

Outcome

Payments came back into the app

By the end of the project, business banking customers could send money internationally from Allica.

A gap closed

Customers could send money abroad from the account they already had, in the currencies their business actually needed.

More reason to open the app

Payments that used to happen somewhere else became a routine task inside Allica, which lifted app usage.

Fewer reasons to leave

With international payments handled in one place, customers had less need to keep another provider running alongside their business account, which helped retention.

Testimonials

“Khayam was a great asset to the Allica Bank Payments squad. Working on an array of new product features, and contributing to the new, overall design system, khayam had a solid understanding of UX / UI design, and was willing to openly work alongside engineering to come to conclusions quickly but effectively. I’d happily recommend Khayam to any engineering team going forward.”

Andrew McCulloughLead Engineer, Allica Bank