Sitetracker · infrastructure management platform
Moving quality checks from the desk to the field
A French EV-charging operator adopted punch nationwide and moved off a competitor.
Role
Product Designer
Team
PM, tech lead, web + mobile engineers
Timeline
2025
Punch launched, but it never got used in the field
Every construction project closes with a punch list: issues the crew must fix before closeout. Sitetracker released Punch, ownership lapsed, and my team took it over in 2025.
Mobile use was rare. On one account, only two people used Punch on their phones in three months. The work was happening at a desk. I rebuilt mobile punch creation and the fix-review flow.
I met crews where the work already happened
Defects are found during inspections, and an inspection is completed in a form on Sitetracker mobile. A punch item is a failed checklist answer. Users could already create a punch item from a form, but few knew, and the flow re-asked everything they had just typed.
I reviewed mobile usage with the forms designer and prioritized redesigning the entry point before better filters or search. Smaller build, bigger gain.

The create screen as I designed it: the originating form becomes the punch list, and the failed item’s title and comment become the description.
I ran five customer sessions across three operators. In one session, I did discovery and came back with a six-state workflow. The customer's architect asked for changes, so we made them in the room. He and two other customers asked for a cancelled status, and it shipped immediately.
Now, a single action creates the punch item from the failed entry with subject, comments, and photos. I specced the punch item count on the form as a link, so crews can tap through to the item and return to the inspection.

The failed checklist item, showing the related punch item.
Contractors find defects; punch managers assign them at a desk. Anyone could approve their own fixes, so I narrowed approval to two roles, punch item manager and fix assignee. Both roles inherit from the punch list down to each item. Nobody approves a fix they submitted.

I used a second business line to win priority
Punch came to us as a construction feature. Forms are also how maintenance teams run scheduled inspections, so punch followed forms into maintenance. I argued punch up the list because it was the only work touching a second business line.
Our largest new customer ran only maintenance. Creating the defect in the field was easy. Reaching the right person was not. I worked out the routing with their team and my tech lead: a punch item becomes a corrective-maintenance ticket, and jobs hang off that ticket, each routed to a named person or vendor. When I handed off, this routing was specced, not built.

The punch list determines when a customer gets paid
A telecom-tower operator was forecasting 80,000 punch items a year across 20,000 sites. Defects are scored: minor 1, major 2, critical 6. Six points blocks handover, so one critical defect stops a site.
I designed six states, with an owner for every transition a person triggers. Only four of those states shipped.

On Hold and Reassigned never shipped, and On Hold has no defined exit.
The demo killed my preferred control
The fix-review screen had an approve-or-reject toggle, a reason field, and a separate Submit button. My PM went straight to Submit, missed the toggle, and got stuck. “This kills me, Molly.” My tech lead suggested what we shipped: two buttons, no submit. I conceded the Submit step and pushed for undo in the toast. An accidental reject is recoverable. A missed toggle is not.

This version did not work.
The mobile fix screen hid its own history
I cannot create punch lists on my phone… I tried it several times to do it via my phone. It didn’t work. — Senior manager
On mobile, users only saw the latest fix attempt, and both Approve and Reject were available to whoever submitted the fix. That let a contractor approve their own work. I prioritized both and settled the fallback with the mobile engineer: if carrying the list name forward was too expensive, users would rename the list once so every item landed in it. When I handed it off, the fix timeline was still in verification.

A wrong call should be easy to undo
Over sixteen months, 793 people worked punch lists on phones, and 333 opened the create screen. Those figures cover a broader population and period than the two-user baseline, so they show reach, not lift. Mobile creation never got the success event I should have specified. The durable decision was to move creation into the inspection flow while keeping a wrong call easy to undo.


