Handoff

Design and prototype an experience that helps maintenance supervisors understand what work should move next, who owns it, what is blocked, and what action gets an asset back in service. The work is focused on supervisor planning and triage, and the prototype runs on mocked, telematics-like maintenance data.

Handoff is not a replacement for Work Orders, PM schedules, Faults, DVIRs, Parts, Dispatch, or Vendors. It is the live operating layer above them — the place where cross-asset maintenance work becomes accountable.

• Triage assets, not signals.
• Plan continuously, not once a day.
• Make every item accountable: one state, one owner, one next action.

• Live Workboard with mutually exclusive states
• Handoff Health for timing & accountability issues
• Asset-centered queue and task detail
• Sources, fault review, readiness & priority rationale
• Work order assignment flow
• Capacity planning with technician selection & pending impact
• Dispatch hold request flow
• Dismiss / monitor with reason and follow-up
• Completion / return-to-service disposition
• Activity scoped to the selected asset / work item

The prototype intentionally avoids full dispatching. Most technician work should flow through technician-managed queues. Assignment order gives supervisors a simple way to accelerate urgent work by placing it as the technician’s next item, while routine work can be added to the end of the queue.

• The customer has enough maintenance volume that prioritization is a daily coordination problem.
• A telematics platform can access the core data objects: assets, DVIRs, faults, PM schedules, work orders, technician availability/skills, parts, vendors, location, and dispatch context.
• Data quality varies, so the experience should surface unknowns rather than hide them.
• Prioritization and capacity planning are supervisor-led and communicated to technicians manually; technicians don’t yet have their own interface to self-assign or re-prioritize (likely a V2 capability).
• Supervisors do not need to actively schedule every technician task in the MVP. The key need is a simple way to insert urgent work at the front of a technician’s queue when required.
• V1 is supervisor-led and deploys at a single shop or across multiple shop locations — intentionally built to scale across different sizes of operation.
• The shift supervisor works from a large-format screen — a desktop or a full-size tablet/iPad. The prototype is usable on mobile, but a smaller-screen layout would need additional optimization.
• The prototype uses mocked data to demonstrate the workflow — see the data model & production inventory for how each data point would map to a real the telematics platform source.

• How supervisors weigh safety, compliance, route impact, readiness, and cost.
• What still happens on the whiteboard, and why.
• Which signals operators trust vs. ignore.
• How often work is blocked by parts, asset availability, technician skill, or dispatch.
• Which actions customers would trust to automate under guardrails.
• How capacity planning and prioritization actually happen internally. Today I assume priority is set by a supervisor or technician and communicated manually; a user study would map the real process — and putting prioritization and self-assignment in technicians’ hands may be better suited to a V2 with technician-facing interfaces.
• What’s essential vs. noise. My prototype is information-dense by design, and I’d work with real supervisors and fleet managers to learn what matters most — and what could be omitted, hidden, or collapsed by default — to ease that density without losing decision context.

A companion worksheet for taking this from prototype to production: every data point the prototype relies on, mapped to a likely telematics source system and flagged as available, derived, or to-build — meant for triaging what we already have versus what we’d need to build with an engineer.

I used an AI-assisted workflow end to end. I used ChatGPT for customer and domain research and for prompt building, then Claude Code to move quickly from product framing to a working prototype — iterating on the state model, interaction design, mock data, and UI hierarchy. I directed and reviewed the product decisions, UX trade-offs, and the final proposal.

It’s a self-contained, single-page prototype running on realistic mock data. Every action updates the board live, and a “Reset demo” button restores a clean slate — no backend, login, or setup needed to try it.

Everything above was a human-directed, AI-assisted build. As an experiment, I also handed the same take-home to an autonomous coding agent (OpenAI Codex) with no steering from me — no product framing, no UX direction, no review loop — to see how far it would get on its own and where my judgment actually changed the outcome.