Redesigning the Westpac One app, from strategy to screens

Open the old Westpac One app and most of what you saw was a web page, wrapped inside an app shell. About 80% of it was web-based. It was slower than it should have been, and it didn’t feel like a modern banking app.

Westpac One is the name of Westpac New Zealand’s digital banking, on the web and in the Westpac One app. In 2023 the app had to change anyway. The IBM middleware behind core app functions was no longer supported, so a rebuild was coming. Westpac’s Australian app had also just been redesigned with a refreshed brand.

I led the UX strategy for a fully native app on iOS and Android. Then I went deep on accounts and payments, the two biggest parts of the app.

I led a small design team: a junior UX designer and a designer from the online business team.

• I owned the research plan, the design principles, the information architecture, the art direction, the accounts and payments design, the prototypes and the usability testing.
• I oversaw the card sorting and tree testing, which another designer ran.
• I worked with a service designer on call centre data, with internal researchers, and with squads and the tribe on priorities.

The redesign had four drivers:

• Old architecture. The app was about 80% web-based, which hurt speed and the experience.
• Unsupported middleware. Core functions needed rebuilding.
• Feature gaps. Competitors offered things like budgeting tools and real-time notifications. Westpac One didn’t.
• Brand. After the Australian app’s 2022 redesign, the New Zealand app needed the refreshed brand too.

The accounts and payments screens showed the problems most clearly. Account details and transactions were inconsistent, heavy with text and had no clear hierarchy. Screens such as KiwiSaver were built for desktop and didn’t work well on a phone. The app also allowed only nine accounts and two credit cards for each customer ID, so some customers needed a second ID. Payment forms used bank terms, such as reference codes, that customers didn’t know, and payments were one of the top reasons people called the contact centre.

I worked with a service designer to sort call centre data by call reason. I compared Westpac One with competitors using Canstar ratings and iSky research, and gathered insights from internal researchers.

I went through in-app feedback, call centre data and app store reviews, and looked at how products like Spotify and Airbnb use principles. I drafted principles around ideas like simplicity and trust, and refined them with the wider team.

A flatter structure

Deep navigation made simple tasks slow. I mapped the current structure and compared it with the Australian app’s flatter one. Another designer ran card sorting and tree tests with 30 people, and I oversaw that testing. I designed the new structure from the results, and it was tree tested again.

Art direction

I adapted the new colours, typography and visual elements for New Zealand customers. I updated the design system tokens and components to follow Material 3 and Apple’s guidelines, and designed new ones for features like budgeting.

With the direction set, I went deep on accounts, then payments. The accounts screens look simple, but each type of account has its own layout and tasks: everyday accounts, KiwiSaver, credit cards and Hotpoints, loans, statements and tax certificates.

I framed the work as four questions. How might we:

• give consistent navigation between transactions and details?
• give these screens more hierarchy, so they’re easy to scan?
• give the pages more personality, so they feel more human?
• make the app work well when people make important payments, so they can trust it?

From the map, I wrote seven hypotheses. We believed customers would want a quick balance without logging in, the latest transactions for each account, a notification when their salary arrives, tools that explain their spending, their own order for their accounts, and upcoming payments at a glance. We also believed they cared more about the daily change in their balance than each transaction.

Then I built the prototypes, using the new structure, principles and art direction.

We ran two rounds of testing. I ran one-on-one sessions over Teams with 10 people, who each completed three payment scenarios and talked us through their thinking. For each area, we compared what we thought with what customers did and said.

Quick balance. Customers found it handy and weren’t worried about security. Most preferred to keep the balance hidden until they tapped it. Without a label, most guessed the number was their available balance, but weren’t sure, so it needed a clear label.

Transactions. Customers found their history easily. They didn’t need a separate “latest transactions” section, because the list already showed the newest first. They liked sharing transaction details without a screenshot, and asked for more filters, such as a date range.

Salary notification. This one didn’t hold up. Customers already know when their salary comes in. They preferred push notifications, and wanted to choose which alerts they get.

Insights. Every participant found it valuable, as long as it’s smart. The idea works, but only if the data behind it is right.

Personalisation. Most people found reordering their accounts easy, and saw it as handy rather than essential. We flagged that reordering needed screen reader testing.

Payees and navigation. Customers found payees easily, and liked seeing past payments on each payee’s page. But one person thought “Send” meant sending a message, so we recommended “Pay” instead.

The full redesign didn’t ship as I designed it. Westpac brought in an agency, and it became a new programme called the Future Digital Platform. I handed my work over to that programme.

The full design was too much for one release, so I planned a smaller first release, called drop 1, around the accounts list. That first release went live later. In it, the payments tab is called “Pay & Transfer”, not “Send”.

Not every project ships the way you designed it. What lasts is the thinking you hand over. The principles, the structure and the tested prototypes gave the next team a head start.

Testing simple prototypes early also saved us from building things customers didn’t need, such as the salary notification and a separate list of latest transactions. And it reminded me why principles come first. When a team agrees what good looks like early, every later decision gets easier to make and easier to explain.