TriNet
Real-world payroll complexity, meeting an interface that hadn’t caught up to it.
As Senior UX Designer leading a small team, I took on payroll flows where the UI looked finished but hadn’t been designed for the job it had to do. The through-line: every place the interface failed to capture what the platform actually needed, a human — usually a Customer Service Rep — absorbed the difference.
It worked. But it leaked.
TriNet is a professional employer organization — payroll, benefits, and HR for small businesses. The flows I worked on weren’t broken, exactly. They were ported: the layout was there, the fields were there, but they hadn’t been designed for the branching, region-specific, legally-constrained reality of real payroll.
One of the hardest things a payroll platform can do.
Terminating an employee isn’t a form — it’s a branching legal-and-financial event: final paychecks, net-check math, live checks vs. direct deposit, mid-pay-period timing, region-specific rules. I designed the flows against a permutation spreadsheet of every way a termination could resolve, so the interface could hold every branch instead of pretending it was linear — and made the legal constraints legible right where they bite.
The full story — Net Check, compliance-driven Final Pay, and the honest call on the “additional information” field:
Read more about TerminationsA single “Terminate” action fans out into net-check, live-check, and direct-deposit paths — each with its own timing and compliance sub-branches. The interface had to hold all of them.
One employee, more than one rate — without the overrides.
A dishwasher who makes $10 and also hosts at $12 used to mean a pile of manual payroll overrides. Multiple Rates of Pay replaced that with something native — a request from one of TriNet’s largest customers that rippled across the whole product. A page-by-page audit, an “Add Rate of Pay” pattern inside the familiar change-request flow, and a bulk-upload wizard that solved the hard SSN-merge and error-handling problems.
The full story — the cross-product audit, the change-request pattern, and bulk upload at scale:
Read more about Multiple Rates of PayA strong PM, a weekly rhythm, and a spreadsheet of every branch.
I met with the lead of the terminations CSR team to learn what was actually coming in — what was ambiguous, what forced a callback, what generated errors. That conversation reframed the whole project around the money: figuring out what a departing employee is legally owed.
With the product owner I built a spreadsheet spelling out every permutation of pay type, timing, and distribution. It became the spec I designed against — the interface could hold every branch instead of pretending termination was linear.
Sometimes the interface’s real job is to make an impossibly branching process legible — to the person filing it and the person who catches it downstream.
Honest ending: I didn’t stay long enough to watch these ship and measure their effect. The work was validated qualitatively by the people closest to the pain — the CSR lead confirmed the incoming problems; the product owner confirmed the requirements and legal constraints — but I don’t have post-launch numbers, so I don’t quote any.