Chapter 2   •   10 minute read

Built for Mars

Highlighting the difference between good and great UX.

Making my first payment

Analysing the experience of making a payment with each bank.

Photograph by Built for Mars

The days of paying friends and family with cash are behind us. Why? Well, because paying people online is so delightfully easy.

Tap, tap, tap… okay I’ve sent you £30.

Sending money online—probably through a mobile app—is quickly becoming the norm.

But are the banks ready for this new world? How well will the traditional banks evolve given that they’re now competing with mobile-only companies?


With a few exceptions, there wasn’t a huge variance in the amount of effort, or time taken to send a payment from any of the banks.

What they did do differenty:

⚡️Faster notifications.

👆Pre-selecting your only account.

😅 Reduced the user’s anxiety when making a payment.

💪 Utilising the power of defaults.

👨‍🏫 Unlocking extra value through external functionality.

⛔️ Handling errors well.

Case studies

This chapter has 12 case studies. Each study shows:

🤯 The full flow of making a payment with each bank.

👀 Highlights notable UX decisions.

🧠 The subtle psychology used by each bank.

👇 Click any logo to open that case study in a new tab. 👇


Each case study is about a 3/5 minute read.

Number of clicks to make a payment

Firstly, I wanted to compare how many clicks it took to send money to a new payee. Ultimately this would reflect the amount of effort required.

Number of clicks to make my first payment













Number of clicks

Clearly, reducing the number of clicks in this domain is hard—it’s a process with thin margins. Perhaps Starling could shave off another click, but would it make their experience any nicer? Possibly not.

Perhaps a better metric would be how quickly you can actually go through the process of creating a new payee, and then sending them money. So I timed myself.

How many seconds it took me to make a payment













Number of seconds

This demonstrates that the number of clicks does not always translate into a faster experience. Certainly not a better experience. For example, I was 39% faster on Monzo than I was on Lloyds, despite Lloyds requiring fewer clicks.

Does it matter that it took me 1 second longer to send a payment with HSBC than with Revolut? No. But you would notice when the process was twice as fast.

It was more than 3x faster for me to send a payment with Monzo than it was with Nationwide.

🤦‍♂️ Input & time

UX tip

You cannot measure a form, or process, purely on the number of clicks. Great UX can actually make it quicker to complete a longer form, than a poorly-designed but shorter one.

What are the differences?

So what exactly do these banks do to make this process faster? And ultimately, is speed even a good way to measure the experience? The rest of this chapter explores that question.

1. Faster notifications

One of the first things people notice when using one of the challenger banks is how fast the payment notifications are.

But are they actually any faster than the traditional banks? To test this I made a series of identical payments for £1 with the same online merchant. I timed how long it took for that payment to appear in my app, and did this 3 times for each bank—averaging the results.

These were online transactions, and I started the timer from when I clicked to make the purchase. So these times will be considerably slower than making a contactless payment in-person.

The challenger banks

The traditional banks

⚡️ Avg. (mean) time to show payment was between 11-12 seconds.

⚡️ Avg. (mean) time to show payment was at least 25 seconds. Often a lot more.

🏖 App updated in realtime, without any refresh needed.

🤳In most instances app required a hard refresh to show pending payments. Exceptions: Metro, Santander & Nationwide.

📊 Very consistent.

📈 Very inconsistent. Some banks weren’t showing a payment even after an hour.

Frustratingly, most of the time the results were inconsistent, and without doing hundreds of payments I’d be unable to accurately compare each bank fairly. But, after completing 3 payments for each bank it was obvious that the challenger banks have done something to speed the process up.

The challenger banks were at least 2x faster at displaying the payment in the app. In some instances they were 100x faster.

Whilst this difference may seem fairly small, its effect is far more significant. Monzo, Revolut and Starling feel instant.

Say it took an extra second for the light to come on when you flip a light switch, you wouldn’t consider the light to be nearly instant. It’d feel slow.

In comparison that’s how the traditional banks feel. Consumers are now aware that it’s possible to get a notification immediately, so anything less than instant—be it 30 seconds or 30 minutes—feels like a step backwards.

⚡️ The power of instant

UX tip

Feedback from an input should be as fast as possible, then aim to make it faster. A huge part of something feeling intuitive is the ability to see a reaction to your input immediately.

2. Pre-selecting my only account

I only have one account open with each bank, so being asked to ‘select which account I want to make a payment from‘ is a waste of time—and an annoyance.

Instead, it should just default to my only account, but they don’t all do that.

Pre-selected my only account:

Forced me to select my account:

Pre-selected my only account:

Forced me to select my account:

This simple default option would make the process require less input, and therefore be completed faster. Perhaps only by a few clicks, but over the course of a year, or a decade, that’ll add up a significant amount of wasted energy.

But more importantly, users have an awareness that it’s a waste of time as they’re doing it. Unlike having an additional few clicks in the menus, one can easily categorise this as a useless activity.

And in life, doing something that you suspect is useless will feel like a lot more effort than doing something you believe is necessary.

🤦‍♂️ Avoid useless actions

UX tip

Anything that the user considers to be a waste of time will feel like significantly more effort than something they believe to be necessary. This is why context is so important.

3. Anti-error UX

How many times do you check that you’ve typed the account details correctly when paying someone new? You’re not alone—we all do it and it’s a rational time to worry.

From a user experience point of view, it’s a moment of heightened panic, which makes it a great opportunity to implement minor UX changes that could have a meaningful impact on the user’s overall experience.

Some of the banks display to the user which bank you’re about to send money to.

Showed which bank the money was going to:

Did not show that:

Showed which bank the money was going to:

Did not show that:

Now, does this really stop people sending money to the wrong account? Possibly not. But that doesn’t actually matter.

What’s important to understand here is that the metric you use to measure the success of this feature, will determine if you think it’s worthwhile.

The relatively small act of saying “you’re about to send money to an HSBC account” might not actually reduce the number of incorrect payments made. So if your sole objective is to reduce this number, you’d have a reasonable argument to not bother building this feature.

But instead, if you measure success in terms of the experience, then it’s totally conceivable that the user knowing their money is going to the right bank dramatically reduces their stress.

The value of this feature isn’t in reducing payment errors—which are rare events—but reducing anxiety when sending money—which many people feel.

It’s worth noting that many banks are doubling-down on this feature now with something called ‘confirmation of payee’, which also verifies their name. There’s more detail on this topic in the footnotes, and a link to a funny baby.

👑 Redefine success

UX tip

It's okay for a feature to technically have very little utility, because they're worthwhile if they positively affect the experience.

4. Pre-populating the reference field

Typically there are two approaches that the banks have taken in regards to the payment reference:

1.  Force the user to type something

2.  The field is optional.

This is absolutely thinking inside the box. It’s either off or on.

But there were two exceptions: Monzo and Starling.

Monzo pre-populates the reference field with ‘Sent from Monzo‘. You can change it if you like, but it sets that as the default.

Starling takes a different approach and doesn’t pre-populate the reference field, but provides sensible ‘one-tap’ suggestions. 

This may seem insignificant, but it’s brilliant user experience. Subsconciously, people generally aren’t happy just typing “aaa” into the payment reference field—they’ll want to put something somewhat useful in there instead.

In effect, this means you have to stop and think of a suitable payment reference for every transaction. For some payments this would be easy, but for many you’d struggle to think of anything meaningful.

The reason why this is so delightful is that it’s slightly better than nothing, but considerably better than being forced to always type something. It’s better than both the ‘inside-the-box’ options.

🤔 Generating content

UX tip

If you're asking people to generate some content, like a nickname or account username, they'll have to think about it. Consider if this effort adds value to the user in the long term or not.

5. Adding Apple pay from within the app

You can add almost any card to your Apple Wallet through the Wallet app itself. But to do that you need to go into your iPhone settings and know what you’re looking for.

But what about people who either don’t know how to do that, or don’t know enough about Apple Pay to even know that you can do that?

The better option is to provide a link inside the banking app. It’s in context and discoverable.

Quick links to add to Apple Wallet

It’s really simple: it quite literally just loads up the iPhone Wallet app. So which of the banks have bothered to add this?

Can add Apple pay from the app:

Can only add Apple Pay via the wallet:

Can add Apple pay from the app:

Have to add Apple Pay via the wallet:

The subtle reason why this is so important is not that it saves clicks, but rather that it allows more people to discover Apple Pay—and therefore get more value out of their bank account.

A study from 2019 showed that 48% of all iPhone owners have used Apple Pay. Of the remaining 52%, there will be a cohort of people who would like to use Apple Pay, but either don’t know enough about it or never bothered setting it up.

But by making it slightly easier for them, and promoting it in the right context, these banks are unlocking additional external value for their users. 

This is a benefit that costs almost nothing to implement, but will unlock additional value for a very specific cohort of users.

🏝 Unlock external value

UX tip

Make external features, like Apple Pay, more discoverable from your app. Don't assume that your users already know how the external features work.

6. Handling incorrect account details

Errors are unavoidable, but companies can control what is shown to the user when they do happen. Remember; an error doesn’t always have to be a technical bug—it could be due to the user entering an unexpected input.

To test this, I tried to make a payment to an invalid account (101010, 10101010).

The correct way to handle this would be to notify the user that the account details are incorrect. The user may have got the sort code wrong by a single digit, and not noticed.

Notifies you that the details are incorrect:

Shows a generic error:

Notifies you that the details are incorrect:

Shows a generic error:

Yeah, I was surprised too. So what did Monzo and Nationwide actually show?

Handling invalid account details

Generic error messages like these imply that it may work if you just try it again. Say you were attempting to pay your window cleaner, but they sent you invalid account details. How many times would you try before you went back to that person to double check the details were correct?

🙅‍♂️ Handle errors better

UX tip

Error messages should be as specific as possible. Generic error messages can send users round and round in circles, even when it's a simple input issue.


I think there’s significant room for improvement for all the banks here: they’re all falling short in at least one category. This is more evident in the case studies, where I show just how confusing each flow can be.

If you take Nationwide as an example—who underperformed on nearly every test—there’s the realistic possibility that if they improved in these areas they’d make their experience many multiples better.

And that should be the takeaway here: nobody has finished optimising the experience. The gains will not be made in reducing the number of clicks, but improving the context and ancillary features around them.

A better experience might even have more clicks.

There’s more FinTech analysis like this coming soon.

Leave your email here and you’ll get it straight to your inbox. 👀

There are more chapters to dive into:


It took 18x longer to open an account with HSBC that it did with Monzo.

8 min read  ·  May 21


Payment notifications were at least 2x faster with the challenger banks, and in some cases 100x faster.

10 min read  ·  May 28

⚡️ Includes 12 case studies


There were the only 3 banks to send notifications when someone attempted to use a frozen card.

6 min read  ·  Jun 4

⚡️ Includes 10 case studies


It cost at least £20 to send £1 (GBP) to a US bank (USD) with three banks.

8 min read  ·  Jun 11

⚡️ Includes 12 case studies


It took nearly 4x longer to authorise an Open Banking payment with Lloyds than it did with Starling.

8 min read  ·  Jun 18

⚡️ Includes 10 case studies


Revolut only ever replied to 20% of my live chat support messages, and don’t have a phone line.

9 min read  ·  Jul 2


Here are somethings I felt important to explain, but are non-essential

Timing myself to make each payment

Firstly, obviously I am a huge variable here. Although I tried my best, I might be more familiar with one app than another, which could affect the times.

However, I took the following measures to ensure this was as close to a controlled experiment as I could reasonably get:

1.  I practiced and knew the ‘correct route’ in advance. I had the bank details in front of me, and had gone through the process a few times to make sure I was familiar with the steps.

2.  If I made any error or felt like I lost time, I tried again. For example, if I incorrectly typed a digit I’d start the whole payment again.

3.  I had everything I needed in front of me. For example, if I needed a card reader, I’d have it turned on and ready.

So whilst a retest may add/remove a few seconds from each bank’s time,  I highly doubt you’d see more variance than that.

Further explanation on anti-error UX

Let me explain this with an analogy:

Why do you think doctors often distract children while giving them an injection? It certainly isn’t to reduce the chances of missing the vein. (Great video of a doctor doing this at an expert level).

A doctor whose sole objective is to remove all technical error might suggest things that are quite unenjoyable, but possibly effective, like tying the child down and binding their arms.

But nobody would ever do that, because instinctively we all know that if you distract a child they might not even feel the needle.

My point is, in real life we know that experiences matter. The doctor isn’t directly reducing the pain or chance of error, but instead making the experience far less traumatic.

In doing so, with a calmer child, the doctor may actually reduce error—but that’s not their primary metric of success. The rational to dance, or sing, or play with the child is to have fewer crying babies.

Remember: the value in saying “this payment is going to a Lloyds account” is not primarily to remove error. It may also have a positive effect on that, but it’s mostly to reduce the anxiety of the user—or fewer crying adults.

Number of clicks to make a payment

This was testing the number of clicks it takes to send a payment the traditional way—account number, sort code etc.

A few of the banks do have shortcuts, such as paying people in your phonebook, so whilst you can send money in fewer taps on Monzo, this test assumed you had no existing payees or contacts.

Pre-populating the reference field

For clarity, HSBC did pre-populate the payment reference field with the payee reference. But this still required me to give the actual payee a reference.

So whilst yes, they did pre-populate the field, it didn’t actually save me any time.

Unlocking value from external products

I can give another example of this which may be more general.

Let’s say you’re building software which will be used to teach children in schools. Your primary usage are children attending various classes, and accessing resources. If your software existed in a bubble of its own, then you wouldn’t need to worry about any external factors.

But that’s not how the world works. Teachers are uploading PDFs, and most of the students just double click the file and open them. But almost nobody is downloading those files to their Kindles, or making annotations on the PDFs. Students would possibly learn better if they knew how to do this.

It’s only by understanding the external factors, or more specifically; the external limitations, that you can unlock this potential value.

To clarify, you’re not expected to build any annotation features, but rather find a way to teach the students how to do this with what they currently use.