The brief said "a dashboard for our fleet". Discovery turned that into three separate products with one shared data spine, and the reason was a single question about connectivity.
The question that reframed it
"Where is the person when they need this information?" The answer was: in a vehicle, often outside coverage, usually with one hand free. That ruled out a browser dashboard as the primary surface and turned offline behaviour from a nice-to-have into the central design constraint.
Three surfaces, not one
- In the vehicle — a phone app that works with no signal and reconciles later.
- In the office — a live view where the interesting question is always "what changed in the last ten minutes".
- In the ledger — the billing and reporting layer, where correctness matters more than freshness.
Each has a different tolerance for stale data. Building them as one thing would have forced the strictest requirement onto every surface.
Sync conflicts are a product decision
Two people can update the same job from two vans. Someone has to decide who wins, and it is not the engineer at 2am. We wrote the rules down with the operations manager: last write wins for status, append-only for notes, and a human review queue for anything touching money.
Every offline-first product has a conflict policy. The only question is whether it was chosen or inherited.
What we measured
Time from job completion to the record being visible in the office, on a bad connection. The number the client cared about was not average latency, it was the worst case they had to explain to a customer.
What we would repeat
Spending a day in the vehicles before writing the scope. Everything expensive we avoided came out of that day.