Embedded System: Customer Proximity at Two Levels

Digital transformation in field operations has a specific failure mode: IT builds what the office needs, drivers get an app that doesn't work the way they work, and adoption collapses.

We embedded at two levels: with the Owner and Office Administration teams on business requirements and reporting needs, and with drivers during beta testing to understand the real-world constraints of field use.

Direct access without gatekeeping: Direct Slack access to the Owner and Office Administration team. Prototype builds shared weekly, not in staged review cycles. When a driver raised a UX issue during beta, we had the driver on a call the same afternoon.

Decision-making structure: Omar approved what the app needed to do. Halcrow made all decisions about how it did it. We didn't bring mockups for approval on every interaction screen — we built, shared, and iterated.

Continuous deployment: Progressive rollout. Three drivers on the beta before any wider deployment. Real jobs, real data, real dockets. Issues identified from actual use, not from QA scenarios.

Build Phases

Phase 1: Driver Workflow Mapping

Objective: Understand the paper docket process well enough to replace it.

This phase produced the most important design insight of the project: the paper docket wasn't just a data capture form. It was the communication mechanism between the driver, the site supervisor, and the customer. The customer signature on the docket was the moment of mutual agreement — "yes, this is what was delivered."

Any digital replacement had to preserve that moment. An app that captured data but removed the customer signature would break the dispute resolution function entirely.

Design decisions from this phase:

• Customer digital signature captured at end of each delivery, on the driver's device

• The signed job report immediately emailed to the customer — not at end of day, in real time

• No feature the paper docket didn't have, until the paper docket features worked perfectly

Phase 2: MVP Build

Core features:

• Driver login (individual accounts, job assignments visible immediately)

• Trip logging: departure time, arrival time, GPS location captured automatically

• Delivery recording: material type, tonnage, load count (driver-entered with validation)

• Customer signoff: digital signature capture with timestamp

• Job report: auto-generated PDF from the day's records, emailed to customer and office simultaneously

The UX challenge that almost broke adoption:

First beta with three drivers. Week two: one driver stopped using the app. We called him. The problem: the material type dropdown had 47 options. On a touchscreen, wearing gloves, in a truck cab, scrolling through 47 options was intolerable.

Paper docket: one line, driver writes "blue metal" in their own shorthand. App: driver scrolls through a categorised material list.

Fix deployed within 48 hours: recently used materials appear at the top. Custom shorthand entries allowed. Dropdown replaced with a search-first input.

Driver adoption for that driver: 100% from week three onward.

Law 1: Distance is the enemy of speed. The fix to a critical adoption issue went from driver feedback to production deployment in 48 hours because we were inside the project, not servicing it from outside.

Phase 3: Office Integration

Objective: Make the data visible and useful.

The driver-facing app was half the product. The office dashboard was the other half.

Administrator's dashboard:

• Live job status: which drivers are on which jobs, current trip count, expected completion time

• Daily docket summary: all trips, tonnages, and materials for each driver, exportable for invoicing

• Signed job reports: searchable by customer, date, driver — no more physical filing

• Exception flagging: missing signatures, incomplete records, trips without matching job assignments

Omar's view:

• Fleet overview: where are my trucks right now

• Job completion rate: are jobs running to schedule

• Revenue dashboard: estimated billing for the day based on completed trips

Invoicing workflow change: Before: Office Administrator reconciles paper dockets end of day, manually enters into accounting system, identifies discrepancies next morning. After: Office Administrator reviews daily digital summary at end of day, approves, exports to accounting system. Discrepancies flagged automatically when driver record doesn't match job schedule.

Time saved on invoicing reconciliation: approximately 2-3 hours per day.

Phase 4: Full Fleet Rollout (Months 6-8)

Objective: All drivers on the app, paper dockets retired.

Staged rollout: three drivers in beta, then eight, then full fleet. Each cohort's feedback incorporated before the next rollout.

What changed with scale: At full fleet, the GPS data became operationally useful beyond trip logging. Omar could see pattern data: which job sites took longer, which material suppliers were causing delays, which routes were efficient. This wasn't in the original brief — it emerged from having the data in the first place.

Law 5: Earlier beats perfect. The MVP captured enough data to generate insights we didn't plan for. Getting drivers on the app early — with an incomplete feature set — meant we had real operational data much earlier than a full-spec build would have allowed.