Overview
As more UniSuper members move into retirement, demand for Flexi Pension Withdrawals is growing, with approximately 20,000 requests received each year.
Despite being a digital transaction, each request was processed manually, which meant rising cost-to-serve, slower release of funds for members, and growing exposure to manual error and fraud risk.
Reducing costs and risk became a business priority.
Company
UniSuper
The team
Product owner
Business analysts
Solution architect
Developers
Year
2023-24
At a glance
Here's a quick summary of the project.
Problems to solve
Rising volume of requests and cost-to-serve
Manual processing increases risk of error
Manual processing slows release of funds
Industry a growing target for fraud and scams.
Solution
Uplift security of digital transaction
Automate processing of transaction, where feasible
Enhance transaction to improve member experience.
Outcomes
91% automated processing of transactions
Reduced cost-to-serve (ahead of target)
Reduction in contact volume (ahead of target)
Positive member sentiment post launch.
My role
I was the sole UX designer on the project team. I owned experience and design decisions wherever possible. If decisions required sign-off from the product owner or higher, I would present, influence and make the case for the best experience.
Throughout the project I worked closely as part of a trio, alongside the product owner and business analyst.
Decisions that mattered
Understanding current state
Flexi pension withdrawals was an existing digital and paper transaction. The digital transaction was simple - enter your amount, complete declaration and submit, followed by step up MFA. All of this took place in a single step.
Heading into the project I was conscious of this experience, knowing the security and automation uplift would increase the number of steps in the flow to a minimum of three. I needed to look for opportunities to make the longer flow worthwhile for the member.
Discovering pain points and opportunity
As part of a three week discovery phase, I organised workshops with SMEs from the pension payments, member services and product teams. The goal was to answer a number of questions I had collated, while also hearing their stories and pain points with this transaction.
The workshops with pension payments and member services were the most insightful. I was able to clarify process pain points, particularly around minimum income and multiple bank account scenarios. They also gave insights on member behaviour when making these withdrawals, often tied to financial deadlines, so speed in processing was key.
Influencing process
Thanks to workshop insights and collaboration with BAs, I was able to map the current state processes. These maps highlighted the number of human touch points, particularly in the multiple bank accounts and minimum income scenarios. I then mapped out target future state processes, with a focus on removing human touch points, and streamlining processing, to increase speed of payments.
After sense checking the future states with the product owner, BAs and other SMEs, we presented them to the solution architect. This was our opportunity to influence the technical solution, as they were just onboarding into the project. They agreed to work towards the future state process maps.
Example of the minimum income scenario process review
Example of the multiple bank account process review
Advocating for new features
Workshop insights highlighted two gaps in the existing digital transaction - bank account selection and selecting drawdown method. Introducing these as features within the transaction would help resolve process issues, while also uplifting member experience to offset a longer transaction.
I started to design them into the experience, while also advocating for their addition amongst the project team.
Bank account selection
Allowing bank account selection would give members choice, while helping solve the following:
Member contact required to select a bank account if multiple on file
Paying withdrawals to a bank account different to pension income payments required manual intervention, which came with risk.
I wanted members to be able to choose from existing accounts on file, and also add a new bank account within the flow - which we had implemented in a previous project. This would give members the most flexibility. I prototyped it and presented to tech and financial crime stakeholders.
Their feedback was fast and direct: allowing members to add new accounts securely would mean duplicating security work that exists elsewhere in member online. I accepted the feedback and agreed to compromise. We moved forward with selecting from existing accounts.
Example of the bank account selection step
Drawdown method
Allowing members to select their drawdown method would bring the digital transaction into parity with the paper form, and give members more control over their withdrawal. It was a hard sell. It was listed as a should have feature, and workshop insights cited it as a low-demand contact point.
I made the case anyway: for highly engaged members and those under financial advice, it offered meaningful control over where their remaining balance was invested. I designed where it would sit in the flow and who would see it, then presented to the product owner for endorsement.
She could see the value in the feature. Together we prototyped it for broader stakeholders, strategically framing it around reusing existing platform features to keep cost and effort down. It was ultimately endorsed for inclusion.
Example of the drawdown selection step
Refining details
Personalising drawdown
During build we received pushback from developers regarding personalising the drawdown experience for members. The issue being we were reusing an existing feature, and choosing to personalise it, rather than lift and shift. The product owner and I were able to hold our ground by explaining the importance of the personalisation.
The existing feature used generic information, listing all 16 investment options and the default order in which they are drawn down. That works in the context in the existing feature is used, as it impacts income payments, members have the time to investigate further by visiting information elsewhere.
Personalised content was important in this context as it impacts the transaction members are completing. If they need to leave the flow to double check their investment options they'll need to start from scratch, causing a pain point. After some convincing the developers proceeded with the intended experience.
Example of the personalised 'default order' drawdown method
Outcomes
The transaction has performed strongly since going live. Key outcomes are:
91% automated processing of transactions
Reduced cost-to-serve (ahead of target)
Reduction in contact volume (ahead of target)
Positive member sentiment post launch.
Improved security measures means members better protected from the growing risk of fraud and scams.
The addition of bank account selection and drawdown method gives members more choice, while supporting streamlined processing of requests.
The below GIF showcases the flexi pension withdrawal flow
Learnings
Proof of concepts
Despite being involved early in the project, which helped feasibility estimates, developers didn't have enough time to fully grasp the experience we wanted. This led to commitments being made to business, then tech saying it can't be done. To mitigate this, I now push for proof of concepts from tech, to ensure they understand and feasibility can be proven. This ensures we are confident before making commitments.
Future ready feature
In hindsight, advocating for the drawdown feature put this transaction ahead of the curve. Financial advice has since become a major differentiator for UniSuper, and the transaction was already built to support it. The broad takeaway: low-apparent-value features still need the right people in the room and a clear view of where the business is heading, otherwise work gets deprioritised too early.