Summary - 1/4
Contribution settlement cycles - 2/4
Table filter - 3/4
Post-release user interview mind map created by NotebookLM - 4/4
Project Details
The Problem
The new recurring contributions feature was processing 600–800 transactions every month on the 21st of each month. Finance and administrators had no structured way to track contribution status, identify failures, or manage exceptions at scale. With multi-day settlement cycles (T+1, T+2) and multiple edge cases — failed payments, delays, member matches — the operational risk was real.
My Role
Solo product designer collaborating directly with an engineering lead. I was responsible for translating complex financial domain logic into a clear, actionable interface for a small internal finance team of up to 5 administrators.
Key Design Decisions
1. Built for daily operations and large-scale peaks
The tool needed to handle both routine daily processing and high-volume batch events. I designed the interface to surface the most actionable information first, with filtering and status views that scaled without requiring workflow changes from the team.
The tool needed to handle both routine daily processing and high-volume batch events. I designed the interface to surface the most actionable information first, with filtering and status views that scaled without requiring workflow changes from the team.
2. Made settlement cycles visible, not assumed
T+1 and T+2 settlement timing was invisible to administrators, creating confusion when contributions appeared delayed. I surfaced timing context inline so the team could distinguish between a delay and a failure — reducing unnecessary escalations.
T+1 and T+2 settlement timing was invisible to administrators, creating confusion when contributions appeared delayed. I surfaced timing context inline so the team could distinguish between a delay and a failure — reducing unnecessary escalations.
3. Designed for the transition, not just the moment
Rather than designing for permanence, I kept the solution deliberately lean — establishing clear data structures and status patterns that cleanly overwrap and transitioning to PayTo's instant payment model. The goal was operational stability now, and a smooth handoff in 18 months.
Rather than designing for permanence, I kept the solution deliberately lean — establishing clear data structures and status patterns that cleanly overwrap and transitioning to PayTo's instant payment model. The goal was operational stability now, and a smooth handoff in 18 months.
Outcome
+ Shipped a functioning contribution visibility tool used by the operations team ahead of the PayTo migration timeline
+ Gave administrators a structured, reliable way to track and manage 600–800 monthly contributions for the first time
+ Reduced operational ambiguity around settlement cycles and exception states
+ Gave administrators a structured, reliable way to track and manage 600–800 monthly contributions for the first time
+ Reduced operational ambiguity around settlement cycles and exception states
Ongoing Operational Insights
Post-release interviews with the operations team revealed several opportunities for improvement:
+ Direct debit management remains highly manual, particularly for cancellations and dishonours.
+ Direct debit management remains highly manual, particularly for cancellations and dishonours.
+ Staff process multiple password-protected bank attachments, creating operational overhead.
+ Tracking consecutive dishonours manually requires reviewing individual member histories.
+ Automation for bulk-file processing and dishonour cancellations is being developed to reduce manual work.
