Giv Billing + Design System

The Challenge

Agency billing coordinators were managing Medicaid reimbursement for dozens or hundreds of clients using spreadsheets or standalone billing software that connected to nothing else in the agency. That disconnection created a constant reconciliation problem: services were documented in one system, scheduled in another, and billed from a third. When those records didn't match, claims got rejected. When claims got rejected, agencies didn't get paid. For small agencies operating on thin margins in an underfunded space, billing errors weren't an accounting problem -- they were an existential one.

The domain was genuinely complex. Medicaid authorizations were set per client per budget period, with unit limits that had to be tracked in real time. Service codes varied by activity type and had to match exactly what DSPs documented in the field. EVV data had to be reported to state systems on a schedule. Electronic Remittance Advice (ERA) files -- the machine-readable documents payers sent back explaining how each claim was paid, adjusted, or denied -- had to be processed and surfaced in a way a billing coordinator could act on without understanding EDI transaction formats. No single system had held all of this in one place before.

The Strategy

A year of collaboration with a PM and dev team went into mapping the billing domain before the first screen was designed. The goal was to absorb the complexity on the system side and surface only the decisions a billing coordinator actually needed to make. The core insight was that billing automation was only possible because scheduling and shift documentation were already in the same database. Service records didn't need to be created manually -- they could be auto-generated from completed shifts. Budget tracking didn't require a spreadsheet -- it could update in real time as services were rendered.

The design mandate was to make billing feel like review and correction rather than assembly. Coordinators should arrive at the billing module and find the work largely done, with clear signals for what needed attention and straightforward paths to resolve it.

The Execution

The Revenue Hub covered Medicaid budget management (client authorizations entered once, tracked automatically against real-time service usage, with safeguards to prevent over-budget service delivery), service record creation (auto-generated from completed shifts, with a manual creation and correction workflow for exceptions), claim batching and submission, payer management (per-insurance rules and contacts stored at the system level), and ERA processing with error handling.

The error handling design required particular care. When a claim was rejected, the billing coordinator needed to understand why, know what could be corrected and what couldn't, and be able to resubmit without re-entering the underlying data. EVV errors -- visits where the required location verification had failed or was incomplete -- were surfaced in a separate log with clear categorization of the error type and the resolution path. The interaction design throughout the billing module prioritized reversibility and clear error states: a system handling Medicaid reimbursement cannot afford ambiguous feedback.

Three React prototypes were built to test and validate key billing interactions before development: manual service record creation, ERA error handling and claim correction, and the claim batching workflow. These prototypes allowed the team to test complex multi-step flows with real billing staff before committing to implementation.

Design System

The design system work ran in parallel with billing and spanned the full arc of the Giv tenure. At the start, the system was a color palette and a font. Version 1 was built from scratch: component library, interaction patterns, documentation for each component covering variants, states, and usage guidance. When three additional designers joined, the system was refined into Version 2 through a collaborative process. The interaction design side -- how components behaved across loading, empty, error, and success states -- was a primary focus throughout.

With five teams building simultaneously, the design system was what kept the product coherent. Components that behaved predictably across the application reduced the cognitive load on both users and developers. Documented patterns meant new designers and engineers could contribute to the product without needing to reverse-engineer decisions made earlier. The system wasn't a constraint on the product -- it was what made scale possible.

The Results

The billing module made Giv's foundational value proposition concrete: because scheduling, documentation, and billing lived in the same system, the manual reconciliation that had defined IDD agency billing was replaced by automated service record generation. Billing coordinators reviewed and corrected rather than assembled claims from scratch. The design system gave four designers and five development teams a shared language, with components documented well enough that the product could grow without fragmenting.

Design System Components

A selection of components and documentation from the Giv design system V2.