The Notebook in the Truck

The notebook in the truck

I was at an American Electric Power site doing field research for a different product entirely. Timekeeping wasn’t on my list, but I had the access, so I asked about it and watched a lineman do it.

He kept a notebook in the truck to check it against. Not instead of the app. Ahead of it. Job by job, he’d jot the hours, the job code, the work type on paper. The real entry happened later, on a laptop back at the office. He kept the paper anyway, because payroll had gotten it wrong before: hours missing, hours billed to the wrong rate.

View larger (opens the full image)

That single detail turned out to hold the whole project.

What one entry took

You find the job, by job number. Then you pick the work type, and that’s not one choice, it’s a tree: travel, assess, repair, then which kind of repair, or wait time. That tree exists because it sets the hourly rate. Then you find the work order number and attach it. None of it was filled in ahead of time, and none of it was filtered down to the person already logged in.

The target was forty-five to sixty seconds and three to five taps, set from industry norms and from what I’d already watched people do before the work started. What I observed was two to four minutes, with two and a half minutes the number that kept coming up on a standard job. For a crew lead entering on behalf of three people, the target was roughly triple, because the work really is three times the size.

The system knew his role, his crew, and that there was a storm, and used none of it. A job runs two to four entries, and a shift runs eight to fifteen jobs, so a typical day meant somewhere around sixty to ninety minutes just putting time in. On a storm day, at the heavy end of both ranges, it’s closer to four hours, inside a shift that’s already ten to twelve. Slow entry gets put off, and by the end of a long shift, put off means remembered instead of recorded. That’s a payroll problem waiting to happen, and it’s why the notebook existed.

What was at stake

Two enterprise renewals were in trouble, and timekeeping was one of the named reasons. That came to me through a standing forum I ran with Sales Engineering, where Tino Mathew, VP of Field Engineering, brought concerns straight from the field back to product.

Most of those customers had already bought Crew Manager, which models the entire operation: individuals, crews, equipment, vehicles, lodging. The legacy timecard never touched any of it. It read the logged-in user’s own record and nothing else, so a foreman retyped his crew by hand, every entry, out of a system his company had already paid for.

Arcos had built time entry once already, before there was a UX function. It shipped, and it missed, so the question I pushed into intake was why the last one missed and what had to be different.

Writing the outcome

Arcos ran an adapted Shape Up, with a phase ahead of Shaping called Milestone, which turns a raw business ask into capabilities, not features. What came into intake read like a list of tasks, and none of them said what would become true for anyone.

I wrote it in three parts instead. The outcome: a crew lead can submit time for their crew for the day, from the truck. The signal: the forty-five to sixty second, three to five tap benchmark. The no-gos: a month view, and Crew Manager integration. The integration was wanted, and deferred rather than dropped, on the belief that the crew record would have to be rebuilt inside the new platform and synced back later. That belief turned out to be wrong.

Two designers, two domains

Ales Karoza owned mobile time entry. Oswaldo Vazquez owned the back office. Those were domains, not assignments: opposite ends of the same data model. Each was the authority on their end instead of waiting on me to arbitrate. Ales finalized the Timecards Mobile screens, and I finalized the initial Timecards Management screen. Harmony, the Arcos design system, made that safe by already settling spacing, states, token semantics, and what a destructive action looks like. See Harmony: A Design System Built for Machines.

I documented that ownership as the basis to move both Ales and Oswaldo to Lead Product Designer the next cycle. I was laid off before either promotion could be acted on, and both stayed at Arcos. It’s a case I built, not an outcome I delivered.

What the Rodeo confirmed

Individual-only entry was the working hypothesis. The Milestone scope had every crew member entering their own time, which is what Product’s Gainsight and Pendo reports pointed to, with time entry breaking down worse than almost anywhere else in the app. That told me where to point scarce field time. It didn’t tell me why, or what happens at the end of a twelve-hour shift when somebody’s rebuilding hours from memory.

In August, on the same AEP visit that opened this project, I watched a foreman put in time for his whole crew and saw the mismatch right away. One utility isn’t a sample, so it went to leadership as a concern, not a finding. Arcos’s Linemen’s Rodeo was six weeks out, and the CPO asked whether it could do double duty. Executives held the start of Shaping about two weeks to use it, signing off on validating at scale before any development resource committed. Roughly four hundred linemen and foremen took part, plus Arcos’s Storm Response Advisory Committee, for a total incremental cost of one plane ticket.

It held: team leads enter for the crew, and that’s always been true. Individual entry was never wrong, only incomplete for the case that matters most. Storm response is where the crew model counts. The second finding was the work order: every entry needed one attached, including in storm, against an assumption that storm was the exception to nearly everything else about storm.

Both were in the data model, not the screen. Caught on a convention floor, they’re a prototype revision. Caught in build, they’re a schema change.

What changed: the crew shows up already filled in, with add and remove for whoever’s out that day. Hours go in for everybody at once, or you switch over and enter them one at a time. The work order requirement got a notes field in the first release, which wasn’t the real answer, but was the honest one for a v1.

“He suggested and then built a vibe coded prototype so that we could conduct user testing as quickly as possible… which ultimately saved us weeks of development time and put our product on a successful path.”

Nick Nelson, Sr Product Director, Arcos

Twice on purpose, once by chance

After the Rodeo, I built Mark 2.1, the crew-entry revision, in about 12 hours across three days on Harmony-themed components. From there my proof-of-concept work went to the senior designers for delivery refinement, and Ales Karoza, our senior designer for mobile, picked up that code as Mark 2.2, integrating and refining it within the larger coded application. A wired Figma prototype of the same scope would have taken roughly 40 hours. That is my estimate of the alternative, not the timing of a Figma version anyone built for comparison.

Research ran twice on purpose: problem validation at Milestone, before a solution existed to bias the answer, and solution validation at the Rodeo. A third pass happened because the chance showed up.

It came in December, mid-build. Mark 2 was a browser analog of the React Native app already in development, coded agentically against Harmony, so its numbers carried over to the real app. I put Pendo tags on it and ran an unmoderated test during a Duke Energy storm simulation, surfaced through the Storm Response Advisory Committee. It was measured against baseline on time to goal, click-backs, and error corrections.

The numbers said the flow worked. One field user said why:

“It’s like it knows who I am and where in the process I am at… it just drops me there, and this is what I need to do right now.”

A field user, Duke Energy storm simulation

Two negative findings came out of the same session. One user wanted the work order auto-attached to the job rather than found by hand, which the notes field hadn’t solved. Another said the equipment naming was wrong: the product said bucket truck, and his crew says cherry-picker. Neither finding changed v1. Both went into v2 planning.

What shipped

Timecards Mobile and Timecards Management shipped in June 2026, in beta, and reached production in September 2026, after I left. Arcos Field’s AI Companion v1 also shipped in beta that month. One of the two at-risk renewals closed on the presented capability, before anything had shipped. The second was still open when I left; Timecards was a factor, but I’d put it third, behind API extensions and platform speed.

A crew lead could now submit time for their crew for the day, from the truck: the Milestone outcome, in the same words. In alpha, with internal experts, a single entry came in at sixty seconds, the top of the original target range. Because crew edits were bulk, that same sixty seconds covered a whole crew on a typical shift, beating the roughly-triple crew-lead target rather than just meeting it.

An agent that leaves the last step to a person

I was the only designer on the AI Expense Agent in Arcos Field. A crew member sends a receipt, and the agent does the filing. Its confirmation doesn’t just say “done.” It names each thing it did as its own status: the expense submitted to today’s report and awaiting review, the exception it validated and who submitted it, and the meal break added to the timecard as a draft, with a way to view it. Nothing the agent touched is final until a person acts on it.

This is a protected imageClick to unlock protected images

How well that holds up, I can’t say. It was tested with internal users and five utility managers from the Storm Response Advisory Committee, and a scope cut kept it from field technicians before I left, so I have no usage data on how people trusted it. It reached production in September 2026, after I left, and is available to customers who sign up for the feature.

What I’d do differently

I never got a hard number proving the crew-level fix held in the field. Product owned Pendo and the quantitative side of the beta, and that tracking never firmed up once real crews were working long stretches with no connection. I hadn’t defined what I needed to see before calling the fix proven, so I had nothing else lined up. I can tell you what the problem cost, and that the target was hit in a room with experts in it. I can’t tell you it held in the field. Whether the lineman still keeps his notebook, I don’t know.

The fix is a habit: agree on the after-number before build starts, and plan a manual check if tracking might not reach the field. The second lesson cuts both ways. The Crew Manager no-go was written on a belief that the crew data was unreachable, and late in Shaping an engineering lead mentioned that a more granular Crew API was already coming from the legacy side. That’s a structural gap, not anyone’s failure, and one engineering lead in the room at the end of Milestone fixes most of it.