Making my first payment


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?
Summary: 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 do differently
⚡️
👆
😅
💪
👨🏫
⛔️
Case studies
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.
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.
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.
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.
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.
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: |
Co-op | Barclays |
HSBC | First Direct |
Lloyds | Santander |
Metro | |
Monzo | |
Natwest | |
Nationwide | |
Revolut | |
Starling |
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.
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: |
Lloyds | Barclays |
Metro | Co-op |
Monzo | HSBC |
Natwest | First Direct |
Santander | Nationwide |
Revolut | |
Starling |
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.
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.
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.
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.
First Direct

HSBC

Natwest

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: | Have to add Apple Pay via the wallet: |
Barclays | Co-op |
First Direct | Metro |
HSBC | Nationwide |
Lloyds | Santander |
Monzo | |
Natwest | |
Revolut | |
Starling |
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.
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: |
Barclays | Monzo |
Co-op | Nationwide |
First Direct | |
HSBC | |
Lloyds | |
Metro | |
Natwest | |
Revolut | |
Santander | |
Starling |
Yeah, I was surprised too. So what did Monzo and Nationwide actually show?
Monzo

Nationwide

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?
Conclusion
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.
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.