3 of 5 themes
Trust & verification
Clients can't confirm a payment covered the right invoice, whether it's actually processing, or that it went through at all.
UX Research
2026
Less friction, more trust
Discovery research that gave RBC’s payments team evidence for 4 roadmap features, 2 already validated with clients
Overview
Bill payment is being rebuilt for RBC’s new platform, Edge... but starting fresh doesn’t fix what’s already broken for clients.
My role
Before designing screens, I conducted discovery research under a senior researcher’s guidance to identify key pain points and avoid carrying old frustrations into Edge.
Already validated
2of 4
tested with real clients, and liked by them. Both are going into the next release.
✓ Batch payment✓ Reduced steps
Problem
Bill payment is one of the first features being rebuilt entirely, nothing carries over automatically.
The current platform (Express) is confusing, so copying it over would carry those same problems into Edge. But clients have used Express for years, so changing too much risks making the move harder for them.
so….
How might we redesign bill payment so clients want to switch to Edge, not just get pushed onto it?
What we needed to know
01
Where are clients already stuck?
Mining feedback the bank had already collected rather than starting from zero.
02
How do clients manage bills day to day?
Their habits, tools and workarounds.
03
What are other platforms doing?
So we weren’t solving a problem someone else had already solved.
Research
I mapped the journey first then let 3 sources fill it in.
To answer those three questions, I started with structure. Before collecting anything, I mapped the 5 stages every client moves through to pay a bill. That way, every complaint I found later had somewhere to land, instead of being one more random comment.
- 01Add & Manage Payees
- 02Make Payment
- 03Approve
- 04Release
- 05Confirm & Reconcile
What clients already told us
Express has a feedback box and clients had been leaving comments in it for years. Nobody had looked at them as a group.
There were 56+ of them, so I integrated an internal AI tool to help me synthesize and group the comments. That gave me a first pass at the patterns. I read the comments myself and checked the groupings before trusting them and from there I sorted everything into 5 themes:
Talking to clients
Those comments told me where it hurt, not why. So I conducted semi-structured interviews with 5 clients. The first thing they described, without me asking, was the same stuck-payment problem:
Interview participant
✓ Confirmed by 2 independent sourcesFinancial controller
“It’s like you think you’re done, but then there’s one more screen, and I often forget.”
In plain terms
They submit a payment
They think they’re done
They don’t realize there’s one more step: releasing it
The payment quietly expires
That's the same payment status problem that topped the list above. Interviews also showed me something the feedback comments couldn’t: how much manual work clients do just to get around the platform.
Looking at other platforms
2 sources, same 2 problems. Last question: Were these just normal banking problems or was RBC actually behind? So I ran a competitive scan across 5 other business banking platforms looking specifically at payment creation flow.
- RBC ExpressAdd CreditorsPay a BillApproveRelease4steps
- ScotiaConnectAdd PayeeBill Payments2steps
- TDSingle flow1step
- J.P. Morgan Cashflow360Single flow1step
- J.P. Morgan ChaseSingle flow1step
- HSBCnetSingle flow1step
RBC Express is the only platform that needs more than 2 steps. It splits payment and release into separate areas, exactly the disconnect clients described: “there’s one more screen, and I often forget.”
Synthesis
Two things kept surfacing, not five
Step back and look at everything together, the feedback, the interviews, the competitive scan, and the five themes aren’t really five separate problems. They’re two. Once the synthesis was done, I shared it with the product owner, the designer and my senior researcher.
2 of 5 themes
Manual effort
Clients compensate for the platform's gaps with repetition and outside tools, instead of the platform doing the work for them.
So what do I do with two problems? I went back to the journey and asked, at every stage, what would make a client trust this payment without doing extra work.
Recommendations
Stage by Stage
Five stages, each with the friction I found and what I’d change. I aligned with the developer team along the way, so the recommendations take technical constraints into account.
1. Add & manage payees
Searches for or adds a payee
Friction · Manual effortCan’t find or add payees; unclear navigation
What I’d changeSimplify payee search, add, and delete flows. Consider grouping payees into categories instead of one long list, a capability only 1 of 5 platforms scanned offers.
Proposed
Proposed
Validation
Then we tested it with real clients.
We ran a usability test on a prototype with batch payment and reduced steps. 10 participants: the 5 Express clients I interviewed, plus 5 external clients.
1
10 participants
- 5 current RBC Express clientsPeople who use the platform today
- 5 external clientsFinancial controllers and accountants on other business banking platforms
2
A usability test of the new payment flow
- One prototype with both features.
- Each client was asked to create a payment, so the team could see how they used the new flow.
Batch paymentReduced steps
What we saw
Paying several bills at once instead of one at a time
“I could pay everything I need to at once instead of doing it one at a time. That’s great.”
Usability test participant✓ Validated with clients
What came of it. The test didn’t lead to any design changes. Batch payment and the reduced-step flow are both going into the next release.
Screens are limited by the NDA.
Impact
The team committed to 2 features and flagged 2 more.
My research gave the design team evidence for their priorities in payment creation and payee management.
What the research backed
Reflection
What I learned
Bring the team in early
I checked technical limits with developers early, so my recommendations fit what could be built.
Tailor the story to who’s in the room
Product wants the decision. Design wants the client journey. Developers want what’s buildable. Same findings, different lead.
