NAB · BPAY bill payments

Rebuilding BPAY for millions of customers

Turning a legacy Angular payment flow that couldn't run in the app into a reusable React mini-app for NAB and every white label partner, now live.

The redesigned "New bill payment" screen in Kogan Money internet banking on a desktop, with the app version on a phone beside it.
Role
Senior Product Designer, owned UX and UI from problem definition to sign-off
Team
2 product owners, 2 design managers, NAB's payments design team and a delivery squad
Timeline
Research, 3 rounds of testing and delivery
Problem
BPAY is used by millions of customers every day, but the old flow couldn't load inside the mobile app, was hard to maintain, and had to be rebuilt for every brand.
  • 4.5+out of 5, clearing the Platinum ExQual bar across three test rounds
  • 5 → 4taps to pay an existing biller, with one step fewer for both existing and new billers
  • A/B winfor my One Way to Pay concept over the live flow, now on NAB's roadmap

Why it mattered

BPAY sits on one of the most-used journeys in banking. The existing experience was legacy Angular: it couldn’t load inside the mobile app and couldn’t adapt across brands, so every partner implementation meant rebuilding it. The job was a migration to React, but also a full product redesign on a live product used by millions, with a design system that didn’t yet have everything we needed.

Design approach: Progressive Elaboration

The team followed Progressive Elaboration: build confidence step by step instead of committing to high-fidelity solutions before the foundations are proven. In plain terms, nothing went to high fidelity until the lower-fidelity version had been tested and cleared. Every major decision was based on evidence, not assumption.

Because payments are critical, BPAY was classed as a Platinum ExQual experience, the highest bar in NAB’s quality framework: 4.5 out of 5 or better across key experience measures, with at least 20 participants.

Progressive Elaboration

Nothing moves up a fidelity until it clears the gate

Audit the existing flow andbenchmark CommBank and ANZLowfidelityiteratingUsingfriction metricsSELFQualityMidfidelityiteratingUsing designreviewTEAMQualityHighfidelityiteratingUsing customertestingCUSTOMERQualityPlatinumExQual4.5+ out of 5,20+ participantsAudit the existing flow andbenchmark CommBank and ANZLowfidelityUsingfriction metricsSELFQualityMidfidelityUsing designreviewTEAMQualityHighfidelityUsing customertestingCUSTOMERQualityPlatinumExQual4.5+ out of 5,20+ participants

Decision 1: settle a stakeholder conflict with evidence

Early on, the two product owners wanted different things. One wanted BPAY to look and behave like the Citibank experience. The other wanted it aligned with NAB’s existing payment flows. These were genuinely different directions.

Rather than escalate or pick a side, I designed and tested both.

The NAB-aligned concept scored higher. I shared the results with both owners and invited the project-side owner to watch real customers use both concepts. We aligned on a direction backed by data, not seniority, and I kept a decision log in Confluence so the reasoning held up when it was questioned later.

  • Input
  • Happy path
  • Optional step
  • Scroll
Friction map of paying a new biller in the redesigned flow: 4 steps and 8 taps, with every tap, input and scroll plotted where it happens.

Decision 2: one page, not a wizard

The audit mapped every step and tap in the existing flow, and benchmarking against CommBank and ANZ showed how far expectations had moved. We narrowed the options to a stepped flow (one action per page) or a single page holding the whole task.

I chose the single page. Breaking a quick, confident task into next-button steps added friction rather than removing it. Complex sub-tasks, like adding a new biller, open a separate reusable mini-app and return the customer to their payment.

Paying an existing biller went from 4 steps and 5 taps to 3 steps and 4 taps. Paying a new biller went from 5 steps to 4, still in 8 taps.

A smaller decision with outsized impact: in other NAB payment flows the amount field sat below the frequency selector and jumped around depending on what was chosen. I fixed it above, so it never moves.

Concept A

Stepped flow

3 screens 3 taps on Next

Concept B

Single page

1 screen 1 tap on Next

Scored higher in testing

Concept A spreads the payment across three screens. Concept B holds it on one, and scored higher in testing.

Decision 3: go beyond the brief

Every payment type at NAB starts by asking customers what kind of payment they’re making: biller, person or transfer. The burden of knowing sits with the customer before they’ve even started.

I designed One Way to Pay to invert that. You choose who you want to pay, and the right fields appear automatically. I took it from concept to high-fidelity UI with every error state, worked through it with engineering, and presented it across the business.

It beat the live BPAY flow in A/B testing. Budget and timing kept it out of this release, but NAB’s payments team has picked it up as future work.

  1. 1Choose who to payOne list holds billers and people. No need to know the payment type first.
  2. 2Pick a biller, get BPAYBiller code and reference are already filled in.
  3. 2Pick a person, get a transferBSB and account are already filled in.
One Way to Pay: choose who to pay, and the right form appears.

Testing to a high bar

To clear that bar I ran three rounds of moderated, task-based testing. Round one settled the stakeholder question. Rounds two and three refined form hierarchy, terminology, error handling and confirmation states until the experience consistently cleared the bar. Internal critique between rounds pressure-tested edge cases before they reached customers.

Filling a gap in the system

The biller dropdown didn’t exist in NAB’s design system. Rather than design a one-off, I designed it to system standards and contributed it back, so other teams can use it. The whole experience is component-driven, themeable per brand and meets WCAG AA.

To
Choose a saved biller to pay
The biller dropdown, contributed back to NAB's design system. Try it.

Staying close through build

I ran the handover with the full squad, then stayed in delivery: answering questions, adjusting designs for implementation constraints and joining story reviews. I pushed to formally sign off each story before it progressed. The shipped product matches the design, not a best guess from a Figma file.

Outcome

  • A legacy flow that couldn’t load on mobile is now a live, accessible React mini-app, built once and deployable across NAB and partner apps.
  • Paying an existing biller now takes 3 steps and 4 taps, down from 4 and 5. A new biller takes 4 steps instead of 5, in the same 8 taps.
  • It cleared the Platinum ExQual bar across three rounds before production code was written.
  • A conflict that could have derailed the project was resolved through research.
  • A new component now lives in NAB’s design system, and One Way to Pay is shaping the payments roadmap.

What I learned

  • Build trust before you need it. Relationships with both product owners meant hard calls became conversations, not escalations.
  • Design for where customers need to go. One Way to Pay didn’t ship this time, but it changed the roadmap.
  • Design doesn’t end at handover. On projects where I wasn’t in build reviews, defects followed. Here I was, and quality showed.