Terminations
Not a form — a branching legal-and-financial event.
TriNet had moved terminations into a new UI, and on the surface it looked finished. But it hadn’t been designed for the job — it had been ported. Final paychecks, net-check math, live checks vs. direct deposit, mid-pay-period timing, region-specific rules: a pile of edge cases that only surface when a real person in payroll ends a real person’s employment.
It worked. But every gap leaked onto a CSR’s desk.
When the online process was ambiguous or incomplete, the work didn’t disappear — it landed on a Customer Service Rep as manual intervention. Someone in payroll would file a termination, leave something unclear, and a CSR would have to chase it down, interpret it, and reconcile it by hand. The end user was confused and the CSR was overloaded, at the same time, for the same reason.
Serve both audiences, or you’ve solved nothing.
Improve usability so it reduces the manual work CSRs do once a termination is submitted — by adding the right detail at the UI level and streamlining the flow for clarity. The guiding principle: if a design only made things nicer for the person filing orthe CSR catching it, it wasn’t solving the actual problem.
Make the money legible at a glance.
Net pay is what’s left after taxes, benefits, and deductions — and the new UI had no real way to determine it for a terminated employee. On Step 5, the person filing picks among Live Check, Net Check, and Direct Deposit, each with its own icon. The bones existed; what it lacked was legibility, so I rearranged the components and added iconography so the process could be understood rather than decoded.
Net Check forked into two sub-paths — “I want TriNet to provide the calculation” vs. “I’m providing it” — and I made each consequence legible in the flow: the TriNet-calculated path spells out next steps (roughly a 4-hour turnaround if received before the noon cutoff, next day after, with a specialist following up); the self-provided path asks for a final amount and warns the employee stays active until the check reaches TriNet.
Building one flow that absorbed every permutation of how a net check could resolve was the hardest part — exactly what the permutation spreadsheet was for.
Where “design” turned into “compliance.”
Determining a final paycheck for someone terminated mid-pay-period isn’t a preference — it’s the law. We did a deep dive into what’s legally required: when a live check must be cut instead of a direct deposit, and how quickly payment legally has to be in the employee’s hands.
So I designed final pay to make those limitations explicit at the moment they bite — inline info banners tied to the payment choice, so the person filing understood what the process could and couldn’t do, and why.
The legal rails are the design. Surface them where the decision happens, not in a footnote.
The right call was a sequencing call.
A free-text “additional information” field passed context to the CSR team — and it was being overused, constantly, for things that belonged elsewhere in the UI. Every entry is manual work for a CSR. But I couldn’t just delete it: the UI still had holes that made the field genuinely necessary.
My call: keep the field, but reduce its prominence — behind a toggle rather than front-and-center — so truly-additional cases kept a home while reflexive over-use dropped off as the rest of the flow got better at capturing detail up front.
Terminating an employee is more complicated than anyone realizes.
The flows were fully defined against every permutation in the spreadsheet, validated qualitatively by the CSR lead and product owner. Two lessons stuck: the weekly rhythm with the product owner was what made it work — and sometimes the right design decision is a sequencing decision, not a layout one.
Honest ending: I left before implementation, so I have no measured results (CSR-intervention reduction, error-rate change) to quote — the work is qualitatively validated, not numerically proven.