Case study · UL Solutions · User Experience Manager
How I designed the time entry tool UL's payroll and revenue reporting depend on
- Problem
- Engineers and lab staff logged hours after the fact, rebuilding their week from calendars, spreadsheets, and notes. Those hours fed payroll, project costing, and revenue.
- What I did
- Owned UX from research through release: interviews, workflow maps, story maps, prototypes, and UX reviews, plus the scope calls that kept design and delivery in step.
- Result
- Tempus shipped and still runs in production. It feeds payroll and project costing, and its approvals are part of five SOX controls.
- My role
- UX lead, research through execution. Product owned scope and priority. Engineering built the integrations.
There are no adoption or satisfaction numbers for Tempus, and the original go-live date isn't on record. The figures here are what my research found in 2020, not results.
The problem
In 2020, people across UL's certification work, from project engineers to lab technicians, did their work in one system and logged their hours in another. Most entered time once a week. In my interviews they rebuilt the week from Outlook calendars, spreadsheets, and handwritten notes. The project search in the old time tool was opened by mistake about 30% of the time, and people outside the main project system made incorrect submissions every two to three months, each one needing a service ticket.
Those hours weren't just admin. They fed payroll and project costing, and the first time entry on a task starts the revenue-recognition clock. A wrong timecard is a finance problem.
My role
I owned UX for Tempus from research through execution. Product leadership owned the business direction, a product lead ran the backlog, and engineering built the connections to the project system, the lab system, Oracle, and the revenue calculation engine.
What I tried first
The first concept, in January 2020, assumed the systems could share and match orders, projects, order lines, and tasks. If they couldn't, a large part of the screen wouldn't work. So I wrote those assumptions into the prototype itself, marked where it could break, and drew fallback layouts in case the automatic matching proved infeasible. That put the architecture question in front of engineering before anyone wrote code.
It also showed me how much of the plan rested on guesses about how people actually tracked their time.
What changed
In March and April 2020 I wrote a discovery plan and research questions designed not to lead people toward an answer, then interviewed users and studied how they really logged time. The workarounds were the finding: calendars, spreadsheets, sticky notes, and memory, with entry pushed to the end of the week. Those findings became the core requirements. Time should be captured close to where the work happens, and people should see one weekly timecard instead of hunting across systems.
The research also surfaced a risk nobody had logged. Lab staff had daily habits built around spreadsheet exports and uploads, and moving them to Tempus was a big change. I documented it, mapped their current workflow, and it became a tracked risk in planning.
In October 2020, lab users told us they couldn't match hours in Tempus to the work they'd done, because the screen didn't show the lab's own project and request numbers. One option on the table was adding more search. I pushed for real examples first, and the team ended up showing the identifiers people needed instead of building search they didn't.
What we delivered
- A weekly timecard that pulls project work and lab activity in automatically, keeps non-project time in the same place, and goes to a manager for approval before it reaches payroll and costing.
- Clearer release scope. When save, submit, undo, and history got tangled across two releases in September 2020, I audited the backlog against the UX specs, proposed the "Save draft" wording, and split the documentation by release.
- A fix to the handoff. In October 2020 an approved design wasn't being built. I traced the approval back through the tickets and raised it as a gap in how design reached development.
Not everything made the first release. Some features lost out to the schedule and moved to later phases, and I kept the UX documentation in step so no one was surprised at rollout.
What I'd do differently
I'd set up a check from the first sprint that compares what got built against what was approved. I found that gap months in, by accident.