Simplifying payroll for healthcare agencies
Simplifying payroll for healthcare agencies
Simplifying payroll for healthcare agencies
View Site
View Site
View Site

GIV 2026
GIV 2026
GIV 2026
GIV 2026
Healthcare
Healthcare
Healthcare
Healthcare
Enterprise
Enterprise
Enterprise
Enterprise
Web App
Web App
Web App
Web App
OVERVIEW
OVERVIEW
Building the missing piece
Building the missing piece
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 the 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.
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 the 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.
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 the 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.
PROBLEM
PROBLEM
Payroll in name only
Payroll in name only
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 accumulating as staff logged time with no summary, no drill-down, no way to correct errors and 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.
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 accumulating as staff logged time with no summary, no drill-down, no way to correct errors and 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.
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 accumulating as staff logged time with no summary, no drill-down, no way to correct errors and 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.
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 accumulating as staff logged time with no summary, no drill-down, no way to correct errors and 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.


Old payroll page
Old payroll page
Old payroll page
APPROACH
APPROACH
Fixing the foundation first
Fixing the foundation first
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 backward 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.
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 backward 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.
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 backward 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.


KEY DECISIONS & SOLUTIONS
KEY DECISIONS & SOLUTIONS
01 — Redesigning timesheet
01 — Redesigning timesheet
01 — Redesigning 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 payroll run. This created a more reliable data foundation for payroll.
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 payroll run. This created a more reliable data foundation for payroll.
KEY DECISIONS & SOLUTIONS
KEY DECISIONS & SOLUTIONS
02 — Payroll becomes a product area
02 — Payroll becomes a product area
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 tab , 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 edit) and other dependencies
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 tab , 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 edit) and other dependencies
KEY DECISIONS & SOLUTIONS
KEY DECISIONS & SOLUTIONS
03 — Locking timesheet post payroll processing
03 — Locking timesheet post payroll processing
03 — Locking timesheet post payroll processing
When a payroll cycle moves into processing states, admins can no longer edit the timesheet cause it could create payroll discrepancies. so it became clear at that point that the timesheets needed a visual cue for user to 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 user understands why they cannot edit any longer. If adjustments really need to be made, they can run that with the off cycle payroll
When a payroll cycle moves into processing states, admins can no longer edit the timesheet cause it could create payroll discrepancies. so it became clear at that point that the timesheets needed a visual cue for user to 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 user understands why they cannot edit any longer. If adjustments really need to be made, they can run that with the off cycle payroll


KEY DECISIONS & SOLUTIONS
KEY DECISIONS & SOLUTIONS
04 — Time off as payroll dependency
04 — Time off as payroll dependency
04 — Time off as payroll dependency
During user testing, agencies stated 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 finalized.
I also designed the underlying accrual policy system, allowing agencies to define how leave is earned and applied.
KEY DECISIONS & SOLUTIONS
KEY DECISIONS & SOLUTIONS
05 — Two entry points for managing time off
05 — Two entry points for managing time off
05 — 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 for simplicity when 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-tab separate so admins could clearly distinguish between managing a policy balance and understanding what happened to it
Admins could assign staff members to a policy during policy creation and return later to add more people. But for simplicity when 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-tab separate so admins could clearly distinguish between managing a policy balance and understanding what happened to it
Admins could assign staff members to a policy during policy creation and return later to add more people. But for simplicity when 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-tab separate so admins could clearly distinguish between managing a policy balance and understanding what happened to it
IMPACT & LEARNING
What came out of it
What came out of it
What came out of it
Product feeback 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, 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.
Product feeback 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, 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.
Other works
Other works
Other works
Giv 2025
Giv 2025
Healthtech
Healthtech
Web App , Mobile
Web App , Mobile
Redesigning staff onboarding and access control
Redesigning staff onboarding and access control
Redesigning staff onboarding and access control
TSA 2026
TSA 2026
Edtech
Edtech
Web App , Website
Web App , Website
A learning and career growth platform for music industry
A learning and career growth platform for music industry
A learning and career growth platform for music industry
PLENTLY 2024
PLENTLY 2024
Fintech
Fintech
Mobile App , Website
Mobile App , Website
Mobile , Website
Digitizing traditional group savings for a more accountable financial experience.
Digitizing traditional group savings for a more accountable financial experience.
Digitizing traditional group savings for a more accountable financial experience.
LET'S GET IN TOUCH
Have a project idea? I am here to help!


