Recurring Contribution Visibility
Designed an operational tool for finance teams to manage 600–800 monthly contributions across complex settlement cycles — built as a strategic bridge to PayTo instant payments.
Grow introduced a new recurring direct debit feature for personal contributions — processing 600–800 transactions monthly, with batch runs on the 21st of each month. This was the first time the platform supported this capability.
Finance and operations had no existing tooling for this. There was no structured way to track contribution status, identify failures, or manage exceptions. Multi-day settlement cycles (from initiation to T+4) meant transactions could appear delayed without anyone knowing whether it was a timing issue or a genuine failure. The system needed to support dishonour tracking, cancellations, and exception management.
I was the lead product designer, collaborating directly with an engineering lead. The tool was also designed as a strategic bridge — PayTo instant payments would replace this system within 18 months, so the data structures and status patterns needed to transition cleanly.
Challenges
Building for a workflow that didn't exist yet
There was no previous system to reference. The team had never managed recurring contributions at this scale. I couldn't observe an existing workflow — I had to anticipate operational needs by interviewing domain specialists, mapping the full data flow from bank to system to member, and working closely with finance to understand settlement logic before designing anything.
Making invisible timing visible
Up to T+4 settlement cycles meant a contribution could sit in a pending state for days. Without a timing context, administrators couldn't tell whether a transaction was delayed or failed — leading to unnecessary escalations and wasted investigation time. I needed to surface the settlement timing inline so the team could make confident decisions.
Designing for transition, not permanence
PayTo instant payments would eventually replace this system. I needed to build something operationally stable now — but deliberately lean, so the data structures and status patterns could transition cleanly to the new model in 18 months. Every design decision had to balance "good enough for now" with "doesn't create migration debt later."
Approach
I mapped the full data flow — from bank file receipt through settlement to member allocation — before touching the UI. I collaborated with the engineering lead to identify which transaction states, timing data, and exception types needed to surface in the interface.
I built the default view to surface the most actionable information first. The interface handled both routine daily processing and high-volume batch events on the 21st, with filtering and status views that scaled without requiring workflow changes from the team.
I surfaced settlement timing inline so administrators could distinguish between a delay and a failure — reducing unnecessary escalations. I deliberately kept the solution lean — establishing clear data structures and status patterns that transition cleanly to PayTo's instant payment model in the future state.
After release, I conducted user research interviews with the operations team to evaluate how the tool was actually being used. This revealed that direct debit management remained highly manual — particularly around dishonour tracking, cancellations, and processing password-protected bank attachments. Administrators couldn't easily track consecutive dishonours, and there was no automated case creation or member notifications.
These findings directly informed the next iteration roadmap — including automatic cancellation after 3 consecutive dishonours, system-generated case creation for dishonours, and standardised member communication templates.
Summary view
Contribution settlement cycles
Post-release user research
Impact
- Shipped the first-ever contribution visibility tool for the operations team — replacing zero existing tooling
- 5 administrators gained a structured way to track and manage 600–800 monthly contributions across settlement cycles up to T+4
- Post-release research with the operations team generated a prioritised improvement roadmap — including automatic dishonour cancellation, bulk-file processing automation, and member notification templates
- Established data structures designed to transition cleanly to PayTo instant payments, ahead of the migration timeline
Reflection
Build first, then validate with real usage. Because this was a net-new feature, there was no existing workflow to observe before launch. The most valuable research came after release — watching how staff actually used the tool revealed pain points that couldn't have been anticipated from requirements alone.
Design for the team, not just the task. Each administrator had a slightly different approach — some relied on status filters, others started from member records, others worked from email attachments. The tool needed to support multiple entry points into the same workflow without forcing a single path.
Transition-aware design saves future effort. Designing with PayTo migration in mind meant every status model and data structure decision was evaluated twice — does it work now, and will it migrate cleanly? This added constraint actually simplified decisions: when in doubt, keep it lean.