Time Tracking
iPro Suite's field workers and drivers had no way to record time on-site — the only tool was a desktop-style manual entry form that assumed you'd log work after the fact. I partnered with the PM and Tech Lead, using stakeholder interviews and a product audit to catch a structural gap in the PRD: vehicles had no Overtime logic, a billing risk no one had flagged. From a system with no real-time capability, it became a mobile-first Timer with role-aware modes and a unified time model that the desktop system then adopted.
My role
Lead designer
Duration
July - Sept 2025
Tools
Figma
Team
Design Manager, CEO, 4 Engs
|
From manual entry to a real-time Timer
I redefined iPro Suite’s time tracking experience from a desktop-style manual entry form into a real-time Timer built for mobile fieldwork. Instead of asking users to record time after the fact, this solution enabled field workers and drivers to start, switch, and stop time directly on-site, turning time tracking into a live workflow rather than a retrospective admin task.
|
Continuous state switching in one session
I designed the Timer as a continuous session that supports seamless switching between Regular Time, Overtime, Break, and Travel. Rather than treating each time type as a separate entry, this solution reflected how work actually unfolds in the field, reduced interaction friction, and established a clearer logic for both users and the system.
|
Role-aware context with a unified time model
I built the Timer around role-specific contexts, creating distinct experiences for User only and Driver + User scenarios. By surfacing booking, vehicle, and role information directly in the interface — and by introducing a unified overtime model for both people and vehicles — the solution made time records more accurate, resolved a critical billing logic gap, and created a foundation that could later extend into the desktop system.
Most Memorable Moment:
Influence Is a Walkthrough, Not a Debate.
What stayed with me wasn't the disagreement. It was the moment I realized defending my position wasn't going to move anything. So I stopped arguing and just showed everyone what would actually happen.
We were mid-project when I spotted a logic gap in the requirements: the system had overtime rules for people, but not for vehicles, even though vehicles generated the same kind of cost overruns in real operations. I flagged it, and the CEO pushed back immediately. Scope was getting big. The concern was real. But instead of debating the point, I pulled the team into a session and walked through the actual end-to-end scenario. What a driver does, what the vehicle does, where the billing breaks down if the gap stays. Once everyone was looking at the same journey, the disagreement dissolved. The requirements were updated.
What I learned is that when a room is stuck on opinions, the fastest way through isn't a better argument. It's a clearer picture. People don't usually resist the right answer. They resist uncertainty. Show them the consequence, not the conclusion, and the path forward tends to open up on its own.
|
Impact
What We Achieved
The Impact
The system finally works.
This project established a new operational capability for iPro Suite. By turning manual time entry into a real-time Timer, resolving a critical overtime logic gap, and defining a scalable time model, the work shaped not just the mobile experience, but the broader product system.
From Zero Capability to a System That Scales
Problem reframing
Stakeholder alignment
Cross-functional influence
Systems thinking
|
Section 1
Questioning. Reframing. Redirecting.
Problem reframing
Stakeholder interviews
Product audit
Mobile-first strategy
When this project started, I was handed a task that looked like a mobile adaptation — take the existing time-entry form and make it work on a phone. But early product audits and stakeholder interviews made one thing clear: the existing tool was built for retrospective logging, not real-time field work. So I reframed the project entirely — from adapting a form to building a capability that didn't yet exist. That decision changed everything that followed: the structure, the logic, the scope. What I learned is that the most important design move sometimes happens before any design work begins — it's deciding what problem you're actually solving.
|
Section 2
From conflict to clarity.
Dealing with ambiguity
Cross-functional alignment
Deep-dive facilitation
Requirements update
As discovery progressed, I noticed a structural gap no one had flagged: the requirements gave users overtime rules, but vehicles had none — even though vehicles generated the same cost overruns in real rental operations. I could have raised it as an opinion. Instead, I organized a session with the CEO, Tech Lead, and Product Lead, and walked the room through the end-to-end scenario step by step. Once everyone saw the same breakdown, the disagreement dissolved. The requirements were updated. What I learned is that resistance usually isn't about the answer — it's about uncertainty. Show people the consequence clearly enough, and the decision tends to make itself.
|
Section 3
Not the screen. The system.
Design iteration
Solution comparison
Handoff documentation
Desktop extension
Once the direction became clear, I explored two design approaches: a lighter version that handled basic state switching, and a fuller version that surfaced role, booking, and vehicle context directly inside the Timer. I chose the second — not because it was more complete, but because it was the only one that could scale into the desktop system later. Every state, every role mode, every edge case I resolved in the mobile design became the foundation the desktop inherited. What I learned is that execution is where system thinking either proves itself or disappears — the choices that look small in a Figma file have a way of compounding across the product.
|
Projects
|
