Client
GROW Inc.
Date
2024
Duration
12 weeks
Team
Ashleigh Beath, Anisa Edwards, Alex Constanti, James Wallbank, Jimmy Tang, Sam Goodger, Lorence Tolentino, Dhruv Mohindru, Dawid Wrzos, and Stanley Wu
Product Design — Case and Workflow Management
GROW is a fintech SaaS scale-up providing software and administrative services in the Superannuation space.
The core back-office system, DLTA, is underpinned by cases and Case Management. Cases capture events across multiple sources such as member requests (paper, digital or phone), complaints and third-parties such as SuperStream, insurance providers, Chandler (document management) and trustees.
Workflow and workload management was the first initiative I was tasked with upon joining GROW and focuses on optimising administrator productivity, enhancing member experience, reducing time spent on trivial tasks and providing more visibility to our administrators and teams.
Design problem
Case Management is the operational backbone of DLTA, enabling administrators to manage work efficiently by capturing every interaction across superannuation administration. As GROW scaled, the need to optimise workflow and workload management became essential to sustaining high service quality, meeting SLAs and administrator effectiveness.
However, limitations in search and filtering significantly reduced administrators' ability to locate and action cases efficiently. Case visibility was further constrained by architectural decisions that required pre-defined date ranges to retrieve data due to excessive volumes. This resulted in difficulty managing workloads, breached SLAs, user frustration and an incomplete view of the work in progress.
These challenges were further compounded by performance and scalability limitations due to our R3 Corda blockchain implementation which slowed day to day operations and limited the platform's ability to scale alongside the business. As a result, workarounds emerged from MVP of MVP solutions, adding friction and debt to every task.
Despite two years of discovery and design, the initiative had not progressed into delivery and for a fast pace SaaS scale-up, this pace of execution highlighted the need to prioritise and move decisively from discovery to iterative delivery.
Primary objectives
Because this was a large-scale initiative, we broke this down into several initiatives and various milestones of execution which evolved as we delivered. However, our primary objectives for case management included:
- Establishing a clear delivery path to avoid long running, stalled initiatives
- Learning, adapting and resolving quickly
- Redesigning search and filtering to enable fast and precise case discovery, enabling SLA adherence
- Delivering real-time case visibility across active and closed cases, eliminating the reliance on pre-defined date ranges
- Improving platform performance by addressing technical bottlenecks impacting day to day administrative workflows
- Improving case management and platform resilience by supporting significant increase in volume, load and cross-fund operations, stemming from the onboarding of HESTA
- Reducing operational friction by eliminating manual workarounds, where applicable
- Streamlining administrator workflows to enable the prioritisation of work and improve member experience
- Reducing cognitive load for administrators through clearer information hierarchy and prioritisation
- Decommissioning legacy case management solution once the new solution is in a stable state
- Improving onboarding and learnability for new administrators through consistent patterns and workflows
- Creating feedback loops between operations, product and design to inform continuous improvement
- Fixing our SLA calculation across funds to deliver accurate SLAs as contractually agreed upon
Understanding the platform and research
I began by understanding DLTA, and consuming the existing research assets, as the Case Management portion of work had been in discovery and design for over 2 years without any plan for delivery. This helped deepen my knowledge of the product, DLTA, and teased out other potential opportunities that could enhance workflow and workload management. Furthermore, I conducted 4 shadowing sessions (observational studies) to void ambiguity, learning administrative workflows and developing relationships with our internal users to build trust.
What did the research uncover?
14 administrators participated in an affinity mapping exercise with 2 sessions being held, 1 in Sydney on the 5th of April 2023 and the other in Melbourne on the 27th of May 2023.
This workshop uncovered a multitude of pain points spanning across the entirety of the product, however the themes related to workflow and workload management include
- Improving the search and filter experience
- Setting follow-ups / reminders for on hold cases
- Focusing on what's in my case queue
- Bulk actions such as assigning administrator cases
- Changing case type and/or identity (this is addressed in the workflow enhancements project)
Additionally, through the shadowing sessions, I was able to uncover 3 key user groups, each with varying needs in relation to their authority. This influenced the way we needed to curate permissions for different functionalities, as well as shaped other workflow and workload management enhancements such as Dashboards.
"Repeatedly filtering the same content is time-consuming, especially when trying to view our queue and find relevant cases and members."
GROW staff
Adminisrator Insurance
Design synthesis
Building on the existing solutions and additional research insights, I conducted a time-boxed, 2 day design synthesis to re-evaluate the proposal and test viability. This exercise focused on assessing component scalability and reusability, establishing clear component documentation and usage guidelines (design patterns), and ensuring accessibility and general usability standards.
The synthesis also included a parity analysis against the existing Case Management solution to identify gaps, alongside the exploration of additional opportunities and future enhancements beyond the immediate scope.
Throughout this process, I actively collaborated with relevant stakeholders across the business, including administrators, squad members and the wider design team, to draw on their domain expertise and technical knowledge. These working sessions and feedback loops were critical in validating assumptions, challenging new concepts, and aligning on the direction.
As a result, there were a few changes from the initial proposal which included:
- Changing the alignment of the search and filter to be left aligned, reducing mouse movement between the Case Side Bar
- Changing the + icon to a filter icon for better visual association
- Adding in the Outcomes field to the table, as this supports exception handling
- Making the Reference searchable
- Amending the Time left to be Due, aligned to the BE value of dueAt
- Changing the Member / Acc No to Identity / Acc No so that it can cater for the Identity level cases initiative
High-level planning
In parallel with the design synthesis, I worked closely with the Product Manager and Engineering Lead to break down, prioritise and plan for the delivery of this initiative, balancing new findings alongside existing commitments.
This resulted in a high-level plan that created focus within the team and enabled the incremental delivery of value and functionality, aligned with business needs and laying the foundations for longer term capability.
Delivery and handoff
Once a high-level execution plan was established, we brought this to the squad for further discussion and alignment. Together, we groomed and refined tickets (FE, BE and MW), ensuring scope, dependencies, feasibility and sequencing were clearly understood ahead of development.
Design files were prepared for engineering handoff aligned to the high-level plan, clearly articulating all interactions and user flows. Where required, edge cases, error states, and un-happy paths were documented for smoother implementation, reducing ambiguity, and minimising rework during development.
I was also responsible for owning GROW's design system, ensuring it incorporated the new components that stemmed from the new case management. All new components were fully documented with usage guidelines and examples of how they could be applied in other contexts to clearly articulate consistent design patterns. This aimed to ensure consistency and long-term scalability, allowing consumers to clearly understand and follow component constraints to support future features across the platform.
Demos and feedback
To continue to validate the solution and gather feedback, I conducted two demos, one on 26th June 2024 for the Pensions, Member Payments and Member Services teams, and another on the 28th June 2024 for the Insurance and Claims Administration team. These sessions provided stakeholders with an early opportunity to see the new functionality being introduced and to provide feedback after testing it in UAT, helping inform subsequent iterations and refinement of the solution.
The early feedback was largely positive, with administrators expressing appreciation for being able to see their own queues and bulk assigning of cases. However, there were several usability questions raised, including expectations around user preferences and default views, which were addressed through saved filters in milestone 2.
Squashing bugs and building trust
Case management beta was released into production 2 weeks after the demos, and through ongoing observation and feedback from real world usage, we gathered valuable insights and resolved issues that helped continue the refinement of the solution while delivering against the planned milestones.
During this period, several functional issues were identified and addressed including:
- Filter reset behaviour not working as intended
- Bulk reassignment causing cases to skip process steps
- Reassigned users not displaying correctly in the table compared to case side bar and case management classic
- Case states failing to synchronise
- Varied SLA calculations within the same fund
Unfortunately, due to these issues, confidence in adoption was initially low, and continued improvements and encouragement was required to rebuild trust with our administrators. This was addressed through prioritising bug fixes, clear and open communication with stakeholders and reinforcing reliability and confidence in case management beta over time.
"This is amazing! Having my case queue just pop-up without needing to add filters everytime I click back will save me so much time!"
Liz Pike
Administrator Pensions
Outcomes and impact
Despite the early challenges in adoption, Case Management beta successfully transitioned from a long, stalled concept into a daily used DLTA capability. The incremental approach helped establish clearer ways of working within the product trio (design, product and engineering), and enabled the team to ship functionality regularly, while maintaining alignment with business needs and new insights.
Over time, administrators gained more visibility into their own queues and workloads, and the foundations were laid for a more scalable and consistent approach to handling cases across teams and funds.
Today, Case Management beta is used by all of our internal administrators (approx 150+ users), call centre staff and the trustees and services multiple funds including Vanguard, Australian Ethical, NGS and HESTA with an estimated average volume of 1.2 million cases combined per month. This has significantly reduced SLA breaches, improved administrative workflow and reduced workload allocation time by up to 90%.
Key learnings
With Case Management being such a core part of the platform, building trust with users and addressing bugs timely is integral to its success. While demos and feedback loops were created, adoption depended on reliability, stability and performance, and due to some of the larger issues found, we lost the trust of our administrators, resulting in regression back to Case Management Classic.
Since then, we have triaged and resolved these issues and Case Managmenet beta is now the Case Management of choice for all of our administrators.
Next steps
So what are our next steps?
- Continuous observation and feedback loops with SME's to improve Case Management
- Decommission Case Management classic once we solve for our dead letter queue issue through our Domain events and Kafka initiative
- Improve search and filter functionality though the implementation of Apache Lucene
- Improve table display behaviours such as hiding cases that are STP or awaiting the ingestion of data to progress
- Introduce off hold reminders
- Redefine case meta data (though this is related to cases and not Case Management directly)
- Introduce Identity level cases to align to our evolving product service offering
