Untangling what drove 10% of bonus interest support calls
How I diagnosed the real cause, designed and shipped one tracker scaled across 3 brands, and gave the business evidence to simplify the rules.
Lead Researcher - UX Designer
What changed?
- Call centre load → customers self-serve
- Couldn’t tell where they stood → progress, gaps and next step shown
- Cluttered layout and copy → coherent view, clear hierarchy
- Complex criteria → simpler product rules
Scale
- Call centre volume from Bonus Interest queries10%
- Products in scope5
- MyBOQ share of bonus interest complaints70%
Status
Bonus confusion was driving 1-star reviews, calls and complaints
Every month, customers had to work out whether they’d earned their bonus. The ones who couldn’t, called.
Bonus interest queries made up 10% of call centre volume, and many customers complained when they missed out on interest they’d expected to earn.
Every call took call centre capacity. Missing the criteria meant losing interest customers expected to earn, which turned a product rule into a trust issue.
- Ownership
- Led usability testing · Designed a new design system component for 3 brands · Influenced rule simplification
- Stakeholders
- Head of Design · Head of Product · Eng lead · Compliance · PM · BA
- Timeline
- 6+ months · Discovery → final design handover
- Methods
- Problem mapping · Usability testing · Information architecture · Component design
The business expected clearer screens to fix the calls
The thinking was simple: surface the rules and customers would stop calling.
The solution was a tracker, and its structure was already designed. My brief was to test it with customers before it was built.
Even internally, teams didn’t agree on how every rule worked. That made me question whether a new screen could fix it. So I tested whether a tracker could carry the rules at all. Four questions shaped the sessions:
- Can customers tell if they’ve met this month’s criteria?
- Does seeing progress help them finish in time?
- Do customers know a pending payment doesn’t count yet?
- Do updates arrive in time to act on?
Customers understood every rule, but still couldn’t tell if they’d earned the bonus
Customers loved the tracker. But the pieces didn’t connect in the layout, and “balance growth” didn’t land.
I audited 5 competitor banking apps. Most showed the criteria, but none told customers what to do to meet them.
I built 8 prototype variations from the initial designs. Each one changed a single choice: tick or radio button, progress bar or bar graph, details open or tucked away. That showed which choice helped customers act, not just which one they liked.
Every session started with behaviour: how customers track their bonus today, before they saw a prototype.
…and balanced growth has to go up as well. So not really sure that last one, what that means?
Visibility was a design problem, but rule complexity was a product problem
Better design made the rules easier to see. It couldn’t make them simpler.
I started by asking whether the tracker was clear enough. Testing showed that was only half the question. Layout, ticks and hidden detail were design problems, and I fixed them. But some confusion stayed: three rule sets, “balance growth” that 6 of 6 couldn’t explain, and a bonus earned in month one, calculated in month two and paid in month three. No screen could remove that.
The business wanted the rules solved in the interface. So I took the design as far as it could go, then showed where it stopped and needed simplification.
The evidence:
- 6 of 6 couldn’t say what “balance growth” meant
- 2 of 6 couldn’t follow how the bonus worked, even with the clearest layout
- Engineering confirmed that showing every rule with real-time progress was too complex to build
- Stakeholders didn’t always agree on how every rule worked
Simplifying the rules hadn’t been on the table. I raised it at the end of research.
A tracker alone would make complicated rules easier to see, not easier to earn. The business risked building for every rule and exception across 5 products and 3 brands, and still taking the calls. Simpler rules would help every product at once. More screens couldn’t.
I designed the one screen that gives customers the confidence to act, not call
Seven changes, each answering a pain-point customers faced.
Customers read criteria, progress and timeline as three separate things. I restructured the screen so they read as one answer: this month’s result, then what’s needed for next month, with progress beside each criterion.
Customers wanted to know what’s left and by when. Criteria tick themselves off, the deadline is stated, and the wording says what counts.
Customers called it “a lot of information”, and 4 of 6 wanted detail hidden until needed. The answer comes first, and the rules sit behind a single tooltip.
The tracker is a new design system component. I adapted it to three brand design systems with the senior UI designer, and brought developers in early to check what could be built. Edge cases, like under-18 accounts and welcome bonuses, were designed in from the start.
Stakeholders didn’t agree on how the product worked, so I documented the rules and got sign-off on one version. I worked with Product, Development, Design and Compliance.
The tracker went live, and some of the rules got simplified
Customers at all three banks can see where they stand and what’s left to unlock their bonus interest.
- Designed one tracker component for the shared design system, with 20 states across 3 brands and 5 products
- Covered the edge cases up front: welcome bonus, under 18, turning 18, past months and the rules tooltip
- Documented every token for developers, mid-migration from Sketch to Figma, while the design system was still being rebuilt
I raised rule simplification at the end of research. The business accepted it, and in ME Go the $2,000 deposit is now the only criterion.
I’d settle design system questions before sign-off
I'd share the reasoning behind the new component with the design system owner earlier. A new component was justified: it serves every bonus-interest saving product and its edge cases. That case reached her at handover. I’d walk her through the why while the design was still in testing.