Redirecting the roadmap from Quick Pay to what customers valued
How I challenged what the data seemed to prove, showed a usable flow wasn’t a desirable one, and proposed Favourite Payee backed by customer insight.
Lead Researcher - UX Designer
What changed?
- Buy-in: The hackathon-winning team loved Quick Pay. Customer evidence earned their support to let it go.
- Roadmap: Quick Pay came off before build, and Favourite Payee, saving favourites in the address book during payment, took its place.
Scale
- Banks with the payment flow problem3
- Payments made manually>99%
- Manual payments abandoned50%
Status
- Favourite Payee: in pipeline for development (2024).
A hackathon idea, headed for the roadmap
The business wanted a payment shortcut. I tested whether customers agreed, before committing to the build.
A digital hackathon team proposed Quick Pay: a way to save a payment and repeat it to the same payee from the home screen, with the option to change the amount paid. The suggested UI was a floating button or a fixed widget on the home screen. The hackathon-winning team loved the idea so much they got buy-in to add it to the sprint.
Analytics gave the idea its case: half of payment starts were abandoned. Fewer than 1% of completed transactions were scheduled payments.
My brief was to design the experience and hand over the final design to the development pipeline. I proposed testing it with customers first.
All three banks shared one codebase, so a wrong call would be tripled.
Building this meant engineering time on a home-screen feature, and a new surface on the app’s busiest screen that every later project would have to design around. Furthermore, a feature that didn’t address why the majority of payments were abandoned was unlikely to change the outcome.
- Ownership
- Led usability testing, planning to playback · Designed payment flows & prototypes
- Stakeholders
- Heads of Design · Head of Dev · PM · BA · Product Owner · iOS engineering
- Timeline
- ~2 months · Hackathon → recommendation
- Methods
- Analytics review · Prototyping · Usability testing · Research synthesis
Same payee, different amounts. The assumed fix was a shortcut on the home screen.
The data showed where payments stalled. But it didn't tell why.
People pay the same payee again and again, but the amount changes, so a scheduled payment doesn’t fit. A saved payment on the home screen, with an editable amount, would make it quick.
Analytics showed half of payment starts were abandoned, and almost nobody used scheduled payments. It didn’t show how often customers repeat a payment, or whether speed was what held them back. The shortcut was a reasonable bet, but it was untested.
- Do customers repeat payments often enough?
- Does the proposed shortcut give customers enough value to adopt a new feature?
- Are the suggested flows usable?
Every participant understood the flow. Most would rarely use it.
Analytics showed half of payments were abandoned. Testing asked whether Quick Pay was the solution.
The business believed the analytics already justified the build, and there was no budget for research. So I added Quick Pay to a testing session already planned for another project, and used it to check the assumption.
I ran the research end to end: I planned the study, built high- and low-fidelity prototypes, moderated six 60-minute online sessions on 2–3 May 2024, then synthesised the findings and played them back. Participants were mixed in age and gender.
Each session started with behaviour: how they pay today, how often they repeat a payee, what goes wrong. Only then did they see the concepts and rate how important solving this was to them.
- It covers content on the busiest screen
- It risks accidental taps
- A plus icon could read as “add contact”
Customers later expected the feature under Pay anyway.
The one I transfer to the most… she’s ninth out of my 10 payees. If I could pin her to the top, that’d be great.
A smaller fix, in the place customers already look.
Customers expected saved payments under Pay. They wanted frequent payees easier to reach.
5 of 6 participants repeat a payee twice a month or less. That’s not often enough to earn a spot on the home screen.
What customers wanted was smaller: the people they pay most, easier to find.
Half of payments are abandoned, so customers need a faster way to pay.
5 of 6 repeat a payee twice a month or less. All 6 looked for saved payees under Pay.
Drop Quick Pay. Build Favourite Payee into the address book, where customers already look when they pay.
I asked where they’d look for saved payments.
- Pay: 6 of 6, where they already go to pay someone.
- Home screen: 0 of 6. That fits my earlier call against a floating button on Home, which I made on judgement and didn’t test.
A draft design, handed to the team who’d build it.
Pin the people customers pay most, under Pay, so a repeat payment takes one tap.
I designed a draft and handed it to the Business As Usual (BAU) squad. It’s a suggested direction, not the final design. They own finalisation and development.
- Pinned payees at the top of Pay & Transfer.
- Pinned payees first in Pay someone, so a repeat payment is one tap.
- An offer to pin a payee after a payment, so there’s no separate set-up screen.
Evidence changed the roadmap before anything was built.
The team now had a validated direction that was a smaller build than the shortcut.
- The home screen shortcut went no further as scoped.
- The team gained evidence it didn’t have: 5 of 6 repeat a payee twice a month or less, and 6 of 6 looked under Pay.
- A draft direction went to BAU for finalisation and development.
Pinning frequent payees under Pay makes repeat payments faster for the customers who pay the same people most. Repeat payments are infrequent (5 of 6 twice a month or less), so I’d expect modest, steady adoption, not a spike.
How we’d know?
- Fewer taps for a repeat payment than today.
- Most repeat payments come from the pinned list among customers who pin.
- No rise in wrong-payee errors or support contacts.
At the end of the insight playback, I put the findings in front of the team and let them vote on the direction.
Resistance to dropping a planned feature is rarely about the feature. It sits on an assumption. So I tied the decision to business impact (a smaller build, aimed where customers already look), not to my opinion.
The draft design gave them an alternative to react to. They became part of the shift, not on the receiving end of it.
Six customers showed the direction. They couldn’t show the size.
Six sessions were enough to question the shortcut, and the pattern was consistent: 6 of 6 looked under Pay, and 5 of 6 repeat a payee twice a month or less. But six people can’t size the impact. Next time I’d pair the sessions with payment history from the live app, and test the pinned-payees draft before handing it over, so the decision rests on more than one source.