Procare Payroll
Bringing payroll in-house for childcare centers, and navigating the vendor complexity that came with it.
COMPANY:
Procare Solutions
TEAM:
Designer, PM, Engineering Lead
My Role:
Product Designer
TIMELINE:
10 months
status:
Designed · Shelved
Problem
Payroll was the last major workflow that childcare centers were running outside of Procare. Directors were exporting staff hours into QuickBooks or Gusto, manually re-entering data, and reconciling across two or three systems just to run a single pay period. Every cycle was a chance for error. Every error had real consequences for real people's paychecks.
Procare saw an opportunity to close that gap. Bringing payroll in-house would reduce friction for customers, decrease churn risk, and establish Procare as a full financial operations platform. The problem wasn't the vision. It was what we walked into when we started building it.
Payroll sits at the intersection of time tracking, staff management, billing, and compliance. Getting it wrong isn't a UX issue. It's a trust issue.
Constraints and Reality
The deal was already done
By the time the design team was involved, Procare had already signed a contract with CheckHQ. The investment was significant and stakeholders wanted to move fast. CheckHQ offered a boilerplate UI we could use immediately.
My tri-team and I pushed back. The template looked like a third-party product because it was one. It didn't match Procare's design system, terminology, or information architecture. Childcare admins running payroll for their staff needed to trust what they were looking at. The boilerplate wasn't going to get us there. We held that line.
What we didn't fully anticipate was how much untangling each CheckHQ connection point would require. Components described as ready needed significantly more work to implement. We held recurring sessions with CheckHQ's team throughout. They were collaborative and responsive. But the complexity was real.
Research
We knew the users. We mapped the gaps.
We didn't start from zero. The payroll workflow lived adjacent to features we'd already designed, and we knew the user base well. Research focused on where the existing process broke down and what Phase 1 had to accomplish.
How we got to a solution
The first decision wasn't a UI pattern. The biggest early decision was whether to use CheckHQ's boilerplate at all.
Design decisions
Designing a step-gap for missing timecard data
Timecard sync wasn't available in Phase 1. Rather than blocking admins from running payroll, I designed a modal that surfaced employees with incomplete data and let admins resolve it inline before proceeding. The workflow kept moving. The data gap was visible and solvable, not hidden or blocking. It also set up a clean handoff to Phase 2, where sync would eliminate the need for the step entirely.
Scoping Phase 1 around user trust, not just feasibility
When engineering constraints required cutting contractors, overtime, sync timing, and autosave from Phase 1, leadership made the call. But I contributed a design perspective on what the MVP needed to feel coherent and trustworthy, separate from what was technically possible. There is a difference between a feature that is missing and an experience that feels broken. I advocated for keeping the elements that were load-bearing for trust and flagged the ones whose absence would create confusion rather than just inconvenience.
Rebuilding the UI to match Procare's system
CheckHQ's components used a different hierarchy, different terminology, and a visual language that read as third-party to anyone familiar with Procare. I rebuilt the entire interface within Procare's design system: nav patterns, typography, component behavior, and labeling. Childcare center admins who use Procare daily have a strong mental model of how the product works. The payroll feature needed to feel like it had always been there.
Outcome
The design held up. The timing didn't.
The project was designed, shelved for business and engineering prioritization reasons, and later validated by Bain's market research, which found that demand for in-product payroll wasn't where leadership had projected at that time.
