Saving the Build: Redirecting Resources to What Mattered
The Problem: A hackathon winner. Internal excitement. A feature ready to be designed and built.
The idea was to have a Quick Pay shortcut that let users save payment details for faster repeat transactions to the same person. The only thing missing was evidence that anyone actually wanted it.
The Business Risk: The team was ready to move straight to development. I pushed to test the design first although nobody thought it was necessary. Since there was no extra budget for this, I piggybacked on a research study already in progress to do it without adding extra cost.
My Role: Advocated for and led user testing before a single line of code was written. Research revealed that users didn't see value in Quick Pay — the time saving was minimal, the payments weren't frequent enough, and saving fixed details didn't match how they actually paid. What they wanted was smarter access to recent payees — something far simpler to build and far more useful.
Outcome: Resources were refocused. The right feature got built instead.
Client
Virgin Money | ME Bank | Bank of Queensland
Role
Lead Researcher | Product Designer
Stakeholders
Development Lead | Product Team | Design Lead
/ Context
5
Complex Products, 3 Brands, 2 Platforms
10
%
Of Digital Bank Complaints Were Related to Bonus Interest
30
%
Of These Complaints Were from Virgin Money
70
%
Of These Complaints Were from MyBOQ App
How might we simplify frequent payments to the same person when amounts or timing can’t be fixed?
/ Discovery
Testing the Assumption Before the Build
I planned and led end-to-end user research to test interest, behaviours, and usability for the proposed feature.
Participant Recruitment: Created screeners and recruited 6 participants through ChitChat.
Testing Set Up: Prepared Dovetail templates and moderation guide for consistent testing.
Moderated Testing for Real-Time Insight
I facilitated all sessions to understand: a) how often users repeat payments, b) what they value in managing payees, and c) their concerns around saving payment data.
Customers find Bonus Interest criteria difficult to understand.
Pain Point
We believe clear communication of the criteria and progress visibility will reduce support queries, because customers had no way to self-serve the answer.
Hypothesis
Customers don’t know which criteria they haven’t met.
Pain Point
We believe a visual progress tracker will increase completion rates, because users can't act on criteria they can't see.
Hypothesis
Customers don’t understand why pending transactions are excluded.
Pain Point
We believe contextual messaging around pending transactions will reduce confusion, because without explanation exclusions felt like errors.
Hypothesis
Customers lack timely updates on their progress.
Pain Point
We believe timely progress updates will improve confidence and completion, because they can't complete what they don't know they have missed.
Hypothesis
Prototyping: I designed alternative payment flows in Figma to test whether Quick Pay solved a real problem or just assumed one.
Stakeholder Collaboration: I presented findings directly to the team and product lead, making the case to redirect resources before a single line of code was written.
Synthesis
Post-research, I tagged and analysed all insights in Dovetail. Patterns emerged quickly: the hypothesis didn't hold. User needs pointed somewhere else entirely.
Users didn't see value in Quick Pay. The time saving was minimal, payments weren't frequent enough, and fixed details didn't match how they actually paid. What they wanted was smarter access to recent payees.
/ Design
Pivoting Based on Real User Needs
Research revealed that users simply wanted the app to remember who they paid last. This shifted focus from Quick Pay to enhancing Recent Payees within the Address Book.
Hover over the arrows to explore key improvements.
Before
After
/ Success Criteria
-
Fewer support queries related to bonus interest
+
Improved App Store ratings across brands
+
Sustained engagement post-launch
If confusion persisted post-launch, the next lever was product simplification, not more design.
/ Reflection
Aligning Across Stakeholders
The product was complex enough that even internal stakeholders didn't fully agree on how it worked. Aligning compliance, dev, product, and branding, each with different priorities was challenging at times. What worked was proper documentation and clear communication and as a result I became better in navigating complex regulation heavy products.
Designing for Simplicity
This project taught me that the hardest design problem wasn't the interface, but the product logic underneath it. I learned to advocate for simplicity in the product itself not just on the screen, anchoring every decision in what users could actually understand.
Navigating Conflict Constructively
When a peer reworked my design post-approval, I addressed it directly and respectfully. Escalating when needed, I stayed focused on outcomes, ensuring alignment and delivery without losing trust.
Saving the Build: Redirecting Resources to What Mattered
The Problem: A hackathon winner. Internal excitement. A feature ready to be designed and built.
The idea was to have a Quick Pay shortcut that let users save payment details for faster repeat transactions to the same person. The only thing missing was evidence that anyone actually wanted it.
The Business Risk: The team was ready to move straight to development. I pushed to test the design first although nobody thought it was necessary. Since there was no extra budget for this, I piggybacked on a research study already in progress to do it without adding extra cost.
My Role: Advocated for and led user testing before a single line of code was written. Research revealed that users didn't see value in Quick Pay — the time saving was minimal, the payments weren't frequent enough, and saving fixed details didn't match how they actually paid. What they wanted was smarter access to recent payees — something far simpler to build and far more useful.
Outcome: Resources were refocused. The right feature got built instead.
Client
Virgin Money | ME Bank | Bank of Queensland
Role
Lead Researcher | Product Designer
Stakeholders
Development Lead | Product Team | Design Lead
/ Context
5
Complex Products, 3 Brands, 2 Platforms
10
%
Of Digital Bank Complaints Were Related to Bonus Interest
30
%
Of These Complaints Were from Virgin Money
70
%
Of These Complaints Were from MyBOQ App
How might we simplify frequent payments to the same person when amounts or timing can’t be fixed?
/ Discovery
Testing the Assumption Before the Build
I planned and led end-to-end user research to test interest, behaviours, and usability for the proposed feature.
Participant Recruitment: Created screeners and recruited 6 participants through ChitChat.
Testing Set Up: Prepared Dovetail templates and moderation guide for consistent testing.
Moderated Testing for Real-Time Insight
I facilitated all sessions to understand: a) how often users repeat payments, b) what they value in managing payees, and c) their concerns around saving payment data.
Customers find Bonus Interest criteria difficult to understand.
Pain Point
We believe clear communication of the criteria and progress visibility will reduce support queries, because customers had no way to self-serve the answer.
Hypothesis
Customers don’t know which criteria they haven’t met.
Pain Point
We believe a visual progress tracker will increase completion rates, because users can't act on criteria they can't see.
Hypothesis
Customers don’t understand why pending transactions are excluded.
Pain Point
We believe contextual messaging around pending transactions will reduce confusion, because without explanation exclusions felt like errors.
Hypothesis
Customers lack timely updates on their progress.
Pain Point
We believe timely progress updates will improve confidence and completion, because they can't complete what they don't know they have missed.
Hypothesis
Prototyping: I designed alternative payment flows in Figma to test whether Quick Pay solved a real problem or just assumed one.
Stakeholder Collaboration: I presented findings directly to the team and product lead, making the case to redirect resources before a single line of code was written.
Synthesis
Post-research, I tagged and analysed all insights in Dovetail. Patterns emerged quickly: the hypothesis didn't hold. User needs pointed somewhere else entirely.
Users didn't see value in Quick Pay. The time saving was minimal, payments weren't frequent enough, and fixed details didn't match how they actually paid. What they wanted was smarter access to recent payees.
/ Design
Pivoting Based on Real User Needs
Research revealed that users simply wanted the app to remember who they paid last. This shifted focus from Quick Pay to enhancing Recent Payees within the Address Book.
Hover over the arrows to explore key improvements.
Before
After
/ Success Criteria
-
Brands Evolved Through Strategic Design
+
Improved App Store ratings across brands
+
Sustained engagement post-launch
If confusion persisted post-launch, the next lever was product simplification, not more design.
/ Reflection
Aligning Across Stakeholders
The product was complex enough that even internal stakeholders didn't fully agree on how it worked. Aligning compliance, dev, product, and branding, each with different priorities was challenging at times. What worked was proper documentation and clear communication and as a result I became better in navigating complex regulation heavy products.
Designing for Simplicity
This project taught me that the hardest design problem wasn't the interface, but the product logic underneath it. I learned to advocate for simplicity in the product itself not just on the screen, anchoring every decision in what users could actually understand.
Navigating Conflict Constructively
When a peer reworked my design post-approval, I addressed it directly and respectfully. Escalating when needed, I stayed focused on outcomes, ensuring alignment and delivery without losing trust.
Saving the Build: Redirecting Resources to What Mattered
The Problem: A hackathon winner. Internal excitement. A feature ready to be designed and built.
The idea was to have a Quick Pay shortcut that let users save payment details for faster repeat transactions to the same person. The only thing missing was evidence that anyone actually wanted it.
The Business Risk: The team was ready to move straight to development. I pushed to test the design first although nobody thought it was necessary. Since there was no extra budget for this, I piggybacked on a research study already in progress to do it without adding extra cost.
My Role: Advocated for and led user testing before a single line of code was written. Research revealed that users didn't see value in Quick Pay — the time saving was minimal, the payments weren't frequent enough, and saving fixed details didn't match how they actually paid. What they wanted was smarter access to recent payees — something far simpler to build and far more useful.
Outcome: Resources were refocused. The right feature got built instead.
Client
Virgin Money | ME Bank | Bank of Queensland
Role
Lead Researcher | Product Designer
Stakeholders
Development Lead | Product Team | Design Lead
/ Context
5
Complex Products, 3 Brands, 2 Platforms
10
%
Of Digital Bank Complaints Were Related to Bonus Interest
30
%
Of These Complaints Were from Virgin Money
70
%
Of These Complaints Were from MyBOQ App
How might we simplify frequent payments to the same person when amounts or timing can’t be fixed?
/ Discovery
Testing the Assumption Before the Build
I planned and led end-to-end user research to test interest, behaviours, and usability for the proposed feature.
Participant Recruitment: Created screeners and recruited 6 participants through ChitChat.
Testing Set Up: Prepared Dovetail templates and moderation guide for consistent testing.
Moderated Testing for Real-Time Insight
I facilitated all sessions to understand: a) how often users repeat payments, b) what they value in managing payees, and c) their concerns around saving payment data.
Customers find Bonus Interest criteria difficult to understand.
Pain Point
We believe clear communication of the criteria and progress visibility will reduce support queries, because customers had no way to self-serve the answer.
Hypothesis
Customers don’t know which criteria they haven’t met.
Pain Point
We believe a visual progress tracker will increase completion rates, because users can't act on criteria they can't see.
Hypothesis
Customers don’t understand why pending transactions are excluded.
Pain Point
We believe contextual messaging around pending transactions will reduce confusion, because without explanation exclusions felt like errors.
Hypothesis
Customers lack timely updates on their progress.
Pain Point
We believe timely progress updates will improve confidence and completion, because they can't complete what they don't know they have missed.
Hypothesis
Prototyping: I designed alternative payment flows in Figma to test whether Quick Pay solved a real problem or just assumed one.
Stakeholder Collaboration: I presented findings directly to the team and product lead, making the case to redirect resources before a single line of code was written.
Synthesis
Post-research, I tagged and analysed all insights in Dovetail. Patterns emerged quickly: the hypothesis didn't hold. User needs pointed somewhere else entirely.
Users didn't see value in Quick Pay. The time saving was minimal, payments weren't frequent enough, and fixed details didn't match how they actually paid. What they wanted was smarter access to recent payees.
/ Design
Pivoting Based on Real User Needs
Research revealed that users simply wanted the app to remember who they paid last. This shifted focus from Quick Pay to enhancing Recent Payees within the Address Book.
Hover over the arrows to explore key improvements.
Before
After
/ Success Criteria
-
Fewer support queries related to bonus interest
+
Improved App Store ratings across brands
+
Sustained engagement post-launch
If confusion persisted post-launch, the next lever was product simplification, not more design.
/ Reflection
Aligning Across Stakeholders
The product was complex enough that even internal stakeholders didn't fully agree on how it worked. Aligning compliance, dev, product, and branding, each with different priorities was challenging at times. What worked was proper documentation and clear communication and as a result I became better in navigating complex regulation heavy products.
Designing for Simplicity
This project taught me that the hardest design problem wasn't the interface, but the product logic underneath it. I learned to advocate for simplicity in the product itself not just on the screen, anchoring every decision in what users could actually understand.
Navigating Conflict Constructively
When a peer reworked my design post-approval, I addressed it directly and respectfully. Escalating when needed, I stayed focused on outcomes, ensuring alignment and delivery without losing trust.