Time Tracking, Approval & Billing

The Problem

The existing time tracking, approval, and billing flow was broken enough to earn a near-complete rebuild instead of a UI refresh. People had built real workarounds just to get their time entered and billed correctly, and at any given step, roughly half the information on screen had nothing to do with the task at hand.

Time tracking, approval, and billing aren’t three separate features. They’re one continuous journey, touched by four different roles: the person logging time, the approver, the biller, and whoever’s client-facing on the invoice. I treated it as a systems problem from the start, because a redesign that only looked better at each individual step would have fallen apart the moment those steps had to hold together.

Research

I ran competitive research against tools built specifically for this problem (Harvest, QuickBooks, and others) to see which patterns were standard and where our product was diverging without a good reason. Then I talked to the people actually living in the current system: what they relied on, what was missing, and what they’d fight me to keep if I tried to redesign it away. From there I mapped the full journey end to end, time entry → approval → billing → invoicing, and traced every role that touched the data at each stage.

The Insight That Changed the Design

The most important thing I learned didn’t come from a support ticket. It came from watching how billers actually worked: time tracked is not the same thing as time billed. People logged their hours as a reference point, then billers routinely adjusted those numbers to reflect what they actually wanted to invoice. That meant the data model needed to treat tracked time and billed time as related but separate entities, not one flowing automatically into the other.

Designing for Constraints, Not Around Them

• Features shipped at different rates: approval got pulled from an early release and re-added later; because the flow was built modularly, it slotted back in clean
• No mobile app existed yet: real, vocal demand for a mobile-friendly experience got buy-in to build for mobile and desktop together from the start
• The design system grew with it: supporting mobile meant new mobile components, built to extend the system rather than become a one-off exception

Outcome

The redesign shipped in full and is in active use today. Formal metrics weren’t tracked for this release, but the core problem is solved by design, not just redesigned around: tracked time and billed time are now separate, related fields instead of one flowing silently into the other, so the workarounds people used to build for themselves to reconcile the two are no longer necessary.