Personal Contributions Automation
Designed operational workflows for managing unallocated transactions and exception handling for personal contributions — 250+ transactions per day — replacing manual processes with structured in-system tooling.
Grow introduced personal contributions as a new feature — allowing members to make voluntary payments on top of employer contributions. The platform processed 250+ transactions per day across multiple payment channels.
When transactions couldn't be automatically matched to a member, they landed in an unallocated queue. The system had no structured way to handle these exceptions — no controls on manual allocations, no linkage between refunds and original transactions, and no unified view across payment types.
Finance and operations teams managed this through manual workarounds — off-system calculations, spreadsheet tracking, and passing information between people rather than through the system. The process couldn't scale.
I worked as the lead product designer alongside a system architect, engineering, and finance stakeholders to design structured workflows that brought exception handling, status tracking, and bulk operations into the system.
Challenges
No single view of the problem
Unallocated transactions were scattered across separate dashboards with no unified view across an entire reporting period. Finance couldn't see the full picture without pulling data from multiple places.
Manual processes everywhere, each with different risks
Manual allocations had no controls — admins could reuse payment references, over-allocate funds, or create entries with no audit trail. Refunds were entirely manual with no linkage to the original transaction. Corrections couldn't be traced back to their source.
Multiple fund clients, different rules
Different fund clients had different file formats, security requirements, and processing behaviours. The system needed to handle these differences without creating separate workarounds for each.
Designing without research — working from domain expertise
No user research was conducted. I worked with the system architect and finance stakeholders to understand the pain points, data flows, and reconciliation logic. The architecture document and finance team's direct input drove design decisions.
Approach
I mapped the full transaction lifecycle with the system architect — from ingestion through allocation, exception handling, refunds, corrections, and reconciliation.
I designed a structured status model — Matched, Unmatched, Partially Matched, Non-EFT. I worked with the admin and finance teams to define the four statuses for the processes.
I built bulk action controls for batch reclassification and resolution, with confirmation states on every action to prevent incorrect allocations at scale. I defined valid state transitions with finance and engineering — protecting against over-allocation, duplicate references, and untraceable corrections.
I delivered the core workflow within the four-month timeline and documented remaining UX debt for future iterations — including edge cases around multi-client file format differences and refund-to-original-transaction linkage.
Unallocated transactions interface
Bulk action controls
Transaction lifecycle mapping
Impact
- Brought exception handling for 250+ daily transactions into the system — replacing manual off-system workarounds and spreadsheet tracking
- Defined a four-status model and valid state transitions that protected against over-allocation, misclassification, and untraceable corrections
- Added audit trail to all bulk actions — making every status change traceable for finance reconciliation
- Documented UX debt and architectural recommendations for future iterations
Reflection
Domain expertise can replace research — when you use it properly. No user research was conducted on this project. Instead, I worked directly with the system architect and finance stakeholders to understand pain points, data flows, and reconciliation logic. In a more mature environment, I recommend contextual observation of the manual process before designing. Given the four-month timeline and the absence of an existing in-system workflow, we built from domain expertise and validated as we went.
Status models are design decisions, not data decisions. The four categories replaced informal labels that varied between team members. Getting the model right meant every administrator could look at a transaction and know what to do next — without asking someone else or checking a spreadsheet.
Scope discipline matters more on tight timelines. Four months for a system this complex meant deliberate trade-offs. I documented what shipped and what didn't — multi-client file format edge cases and refund linkage refinements were scoped for the next phase. The member matching system has continued to improve with AI-assisted.