The platform is an automation suite built for healthcare billing operations. At its core, it replaces manual reconciliation of deposits against insurance payments and remittances with an AI-assisted matching engine, and pairs it with an automated lockbox system for digitizing incoming payment documents. Around that core, it also gives practices a reason to bank with us directly, offering bill management, payments, transfers, recipient/vendor management, and automation rules, so day-to-day banking and reconciliation live in one place instead of two.
I led product design on the platform from early discovery through to engineering handoff, working alongside a cross-functional team and a set of design partners inside real healthcare finance organizations.
My Role & Team
I was the sole product designer on the platform, embedded with a team of engineers, a product manager, and a group of external design partners — finance and billing staff at healthcare organizations who used early versions of the tool and gave ongoing feedback.
My responsibilities:
◗ Owned end-to-end UX: research, flows, wireframes, and high-fidelity UI
◗ Built and maintained the design system used across the platform
◗ Ran design partner sessions to validate reconciliation and lockbox workflows
◗ Partnered directly with engineering on feasibility and phased delivery
The Problem
Before the platform was built, reconciling deposits was an entirely manual, deposit-by-deposit process. When a practice received a deposit, staff had to manually cross-reference it against the corresponding check number and the associated remit file (or 837 electronic remittance) to confirm the deposit matched what the payer said they were paying.
In practice, this meant:
◗ Pulling up each deposit and locating its matching check number by hand
◗ Cross-checking that check number and related values against the remit/837 file to confirm the payment was accounted for
◗ Repeating this process for every deposit, with no automated way to confirm a match
◗ Only discovering discrepancies after manually working through the comparison
There was no shortcut; every remit had to be manually verified against its deposit to make sure it had actually been paid, regardless of how routine or straightforward the match should have been.
This didn't scale without headcount: practices needed a team of around 10 people dedicated to working through this manual matching process, just to keep up with incoming deposits and remits.
Streamlined Reconciliation
The core design solution was an auto-resolving reconciliation engine: instead of staff manually comparing every deposit against its check number and remit/837 file, the platform automatically matches deposits to remits using the check number and a set of supporting values pulled from the same remit. When those values align, the deposit is auto-reconciled with no manual work required.
Design decisions that shaped this:
◗ An exceptions/review queue — rather than surfacing every deposit for manual confirmation, the system only routes deposits to staff when the automated match fails or is ambiguous, so attention goes to the cases that actually need a human judgment call
◗ Matching logic built on check number + supporting remit values — designed so a match isn't based on a single fragile identifier, reducing false positives/negatives in auto-resolution
◗ An unmatched payments view — surfaces payments and remits that couldn't be auto-matched side by side, giving staff visibility into both sides of the gap and a manual matching option when the automated match genuinely can't be made
The Goal!: Automate 90%+ of reconciliation work that was previously manual — matching a deposit to its remit as soon as both are received, rather than relying on a team of staff to work through the comparison by hand, and freeing that attention for only the exceptions the system couldn't confidently resolve on its own.
Banking Experience
Beyond reconciliation, the platform gave healthcare practices a reason to move their operating money into our banking system directly — turning the product into a full banking experience rather than just a reconciliation tool layered on top of an existing bank.
Once a practice's funds lived in the platform, we built out a suite of banking features around that money:
◗ Bill management — tracking and paying incoming bills from within the platform
◗ Payments — sending payments out directly, without switching to a separate banking tool
◗ Transfers — moving money between accounts
◗ Recipient and vendor management — maintaining the people and organizations a practice regularly pays
◗ Automation rules — letting practices set up recurring or conditional actions (e.g., auto-pay a recurring vendor, auto-transfer based on a threshold) instead of doing them manually each time.
This piece of the product went through the most rounds of validation with design partners, since "what does a finance lead need to see and control at a glance" turned out to be different for a solo practice than for a multi-location group — a solo practice wanted simplicity above all, while larger groups needed more granular control over rules, recipients, and approvals.
Designing for Multiple Roles
The platform wasn't built for a single generic user — different people at a practice needed different levels of access and different views of the same underlying data:
◗ Admins — oversee the account and configuration broadly
◗ Bookkeepers — handle accounting and post payments, working closely with the reconciliation and matching data
◗ Billing teams — focused on the billing side of the workflow
◗ Authorized signers and authorized users — the only roles with access to the banking side of the platform (payments, transfers, bill management, etc.)
This meant permissions weren't just a settings toggle — they shaped the core information architecture. Banking functionality specifically had to be walled off so that only authorized signers and authorized users could see or act on it, while bookkeepers and billing teams worked within reconciliation and accounting without exposure to banking controls they weren't authorized for.
Automated Lockbox Digitization
Incoming physical payments and documents are digitized and routed automatically, reducing manual document handling and the errors that come with it — while also creating a defensible audit trail for compliance.
A Second Product: Review Tooling for Outsourced Teams
Alongside the core platform, we identified a distinct need: outsourcing teams responsible for reviewing complex, low-confidence files needed their own specialized tool — one built around strict OCR accuracy requirements rather than day-to-day finance workflows.
This became a separate but connected product, giving reviewers a focused interface for correcting and validating extracted data before it flows back into the main reconciliation pipeline.
Design System & Cross-Team Handoff
Because the platform spanned two products and a fast-moving engineering team, I built an adaptable design system early on — shared components, patterns for data-dense tables, and states for automated vs. manual review — so that new flows could be added consistently as scope grew.
I worked closely with engineers throughout, translating flows and system components into implementation-ready specs to keep design and development in sync as the product evolved.
Optimizing the design-to-frontend pipeline with MCP. To close the gap between design and implementation even further, we incorporated MCP (Model Context Protocol) so that Claude Code could read our design screens directly and work against the existing design system rather than starting from scratch. In practice, this meant:
◗ Claude Code reads a screen or flow and checks it against our existing component library first
◗ Where a match exists, it reuses the existing component instead of generating a duplicate one-off
◗ Where no match exists, it creates a new component following our established design system conventions
◗ Storybook is updated automatically as part of this process, so the component library stays current without a separate manual documentation step
This shortened the distance between a design handoff and working, on-system frontend code, and kept the design system itself from drifting out of sync with what was actually shipped.
Outcomes
◗ Reduced a manual process that previously required a team of ~10 people down to an automated match that happens as soon as the deposit and remit are received.
◗ Automating 96%+ of transactions that previously required manual matching — surpassing the initial 90% target
◗ Reduced document-handling errors via automated lockbox digitization
◗ Shipped a dedicated OCR review tool for outsourced teams, improving data extraction accuracy (~24hrs)
The platform required designing for two very different audiences under one roof: internal finance teams who needed clarity and trust in automated decisions, and outsourced reviewers who needed precision tooling for edge cases. Balancing those needs — while keeping a single design system flexible enough for both — was the core design challenge of the project.
