Building the missing piece
Giv is a B2B platform for IDD care agencies in the US, supporting the operational needs of agencies that manage caregivers, clients, schedules, billing and documentation.
Payroll was missing. As the designer on the team, I worked closely with the product manager, design manager and engineers to design the payroll experience from the ground up, building on top of a third-party payroll API and navigating its technical constraints along the way.
Payroll in name only
When I took over the payroll module, Giv already had a tab labelled “Payroll”, but it wasn’t actually a payroll system. It was essentially a flat list of time entries that accumulated as staff logged time, with no summary, no drill-down and no way to correct errors. Agencies were cobbling together spreadsheets and third-party tools to pay their staff.
The challenge was not simply designing payroll. The bigger issue was that the data itself wasn’t sufficient to support a reliable payroll system, and payroll is only as accurate as the data feeding into it.
Fixing the foundation first
The question wasn’t just “How do we build payroll?” It was “How do we build payroll that can be trusted, and what does that depend on?”
We worked backwards and decided to redesign the timesheet experience first as V1. At the time, agencies were already running payroll through a third-party provider and exporting timesheet data from Giv. Improving the timesheet experience would make that existing workflow more reliable while creating the data foundation our payroll system would eventually depend on.
With the timesheet foundation in place, we moved to the payroll core as V2. Giv’s payroll system was built on third-party payroll infrastructure that provided embedded components for compliance-heavy workflows. Rather than rebuilding every part of payroll setup internally, I worked within the capabilities and constraints of the existing infrastructure, collaborating closely with Product and Engineering to identify where Giv needed custom experiences around it.
01 — Redesigning the timesheet
The first thing I did was rename the old “Payroll” tab to “Timesheet” because it was not actually a payroll experience yet. Then I redesigned the flat time entry list into a structured workflow.
The redesign lets admins drill into individual staff timesheets, review shift-level detail and correct errors before the payroll run. This created a more reliable data foundation for payroll.
02 — Payroll becomes a product area
Once the timesheet redesign shipped, I moved to the core payroll experience. I renamed the parent tab back to Payroll and added a sub-nav to give payroll a dedicated home that could grow as new capabilities were introduced.
The sub-nav also adapts to each agency’s setup. Before activating embedded payroll, admins see Timesheets and Pay rules tabs, enough to review and export clean data to third-party tools as before.
Once they activate payroll, the nav expands to include the payroll dashboard, staff, settings (for post-setup edits) and other dependencies.
03 — Running payroll
Since payroll was built on third-party infrastructure, calculations and money movement ran on embedded components I could not change. But we owned everything around them.
To make that boundary clear, I labelled every screen in Figma as provider-owned, Giv-built on provider data or purely Giv. This helped engineers scope work quickly and showed where we could shape the experience.
Admins select a payrun (agencies can have multiple pay schedules), review it, then approve and submit. Once it’s in progress, that period’s timesheets lock.
04 — Locking timesheets after payroll processing
When a payroll cycle moves into processing states, admins can no longer edit the timesheet because it could create payroll discrepancies. At that point, it became clear that timesheets needed a visual cue to help users distinguish between editable and locked data.
To address that, I introduced a status column to the timesheet table that shows the payroll status of a particular time entry so users understand why they can no longer edit it. If adjustments really need to be made, they can make them with an off-cycle payroll.
05 — Time off as a payroll dependency
During user testing, agencies flagged time off as an important addition because paid leave directly impacts payroll calculations.
I designed a mobile request flow for staff to submit time off requests, alongside an admin experience for reviewing and approving them on the web. Approved paid time off then flows into timesheets before payroll is finalised.
I also designed the underlying accrual policy system, allowing agencies to define how leave is earned and applied.
06 — Two entry points for managing time off
Admins could assign staff members to a policy during policy creation and return later to add more people. But to simplify assigning an existing policy to just one staff member, I added a Time Off tab to individual staff profiles, which gives admins a second path to manage time off policies at the individual level, not just at scale.
The tab has two sub-tabs: Assigned Policies for assigning policies and adjusting balances, and Balance Log as a read-only chronological record of all balance activity.
I kept the two sub-tabs separate so admins could clearly distinguish between managing a policy balance and understanding what happened to it.
What came out of it
Product feedback from user testing and sales calls showed strong adoption intent before launch, with agencies already in the pipeline.
Since launch, multiple agencies have onboarded to Giv payroll. It was the first time users could process payroll entirely within Giv without exporting data to third-party tools.
This project taught me that complex product design is not just about designing a feature. It’s about understanding the system and dependencies behind it before layering on functionality.
Working within third-party infrastructure also showed me that constraints aren’t always problems to solve. Sometimes the best move is finding the right place in the product to work with them.
