A field-service app was redesigned in the van, not the meeting room

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

Forty technicians across commercial plumbing and electrical contracts, dispatched daily from one depot: the field-service maintenance company whose job reports feed a legacy system the office depends on for invoicing and warranty claims. The technicians are tradespeople, not software users — their phones are company-issued but personally configured, and their verdict on any new tool spreads through the vans faster than any training session could. The office knows exactly how accurate the reports are, because warranty disputes get settled by whatever the technician typed.

What it was costing

Technicians filled job reports on phones while kneeling in crawl spaces. The app demanded typed paragraphs, needed two hands, and timed out mid-report — so techs wrote reports back at the depot from memory, and the data was fiction.

What they could see

• Job reports were written back at the depot hours later from memory, and the office knew the details were fiction.
• The current app demanded typed paragraphs and two hands, impossible while kneeling in a crawl space wearing gloves.
• The app timed out mid-report on weak signal, discarding twenty minutes of typing and the technician's patience with it.
• Warranty disputes went against the company because photos and measurements were missing, late, or contradicted the typed description.
• Technicians openly coached new hires to fill reports with boilerplate and move on.

The constraints we worked inside

• The existing backend and job system stayed — the design changed the capture experience, not the system.
• Gloves, glare, and one-handed use were the actual interface constraints.
• Technicians would judge it in a week; adoption had to be instant, not trained.

What had been tried before

The job system's vendor demonstrated their mobile module, and the office piloted it with four technicians for a month.

It re-skinned the same desktop forms for smaller screens — typed paragraphs, twenty fields per report — so pilots finished slower in the field and quietly reverted to depot reporting.

A generic dictation app was suggested by the operations manager to remove typing from the flow.

Engine bays and plant rooms defeat voice input; dictation errors in technical vocabulary created correction work longer than the typing it replaced.

The office offered a per-report bonus for on-site completion, treating the problem as motivation.

Technicians weren't unwilling — the tool was genuinely unusable one-handed in the conditions — so the bonus paid for boilerplate reports that looked complete and said less.

What we proposed

We proposed redesigning the capture experience around two days of ride-alongs before drawing anything: voice-friendly input, large targets, photo-first reporting, and offline tolerance, prototyped on the technicians' own phones in real job conditions. The design changes what capture feels like, not the system — reports still land in the same legacy job system the office runs on. Reports preview exactly what the office sees, so technicians trust that what they enter is what arrives. Adoption had to be instant because a tool technicians judge in a week doesn't get a training program.

Just as important is what we ruled out, and why:

• Replacing the legacy job system with a modern field-service platform — Invoicing, warranty history, and the office's daily routines run on the current system; replacing it would turn a capture redesign into a multi-year migration the company never asked for.
• Specifying a new native app for the vendor to build — The vendor's track record was the re-skinned desktop module; another vendor build would repeat it, and the design decisions needed testing before anyone committed code.
• Ruggedized dedicated devices instead of technicians' own phones — Forty rugged handsets cost real money and add a second device to carry; prototype testing showed personal phones with bigger targets handled glare and gloves adequately.

How the work ran

Delivered by the experience pod — designer + researcher over 7 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

Figma

The design file needed to survive contact with a small office team that will never hire designers; Figma's sharing meant the depot PC could open it unaided.

Interactive prototyping

Clickable prototypes with simulated offline states let technicians fail the flow before it was built — the timeout and photo-upload behavior were testable in the van, not just on paper.

Device-based usability testing

Testing ran on the techs' own phones in real conditions because the lab versions lied — glare, gloves, and signal dead zones only show up in crawl spaces.

What went wrong

How we worked together

Cadence

Friday depot demos with the operations manager and two technician volunteers, phones in hand; design changes left the demo approved or dead, never pending.

Client side

The depot's operations manager held the engagement's scope and the vendor relationship; the two senior technicians the vans defer to tested every prototype round, and the office trusted their verdicts.

Decisions

The technicians' verdict settled field-facing decisions; anything touching invoicing or warranty data went to the office manager, whose sign-off was required before prototype rounds continued.

They provided

Two days of ride-along access, the job system's API documentation and vendor contact, and Friday demo hours from technicians between jobs.

What changed

The headline: average job-report completion time on device, measured across the first month — 14 min → 4 min, read from App telemetry plus time study. A second check: reports completed on-site (not from memory at the depot) at +83%.

Reports now get written in the van after the job, not reconstructed at the depot, and the office stopped treating report details as a probability. Warranty disputes that turn on photos and measurements have something to turn on. The technicians' verdict came back as gatekeeping: new hires are shown the report flow first, as proof the company's tools aren't a joke. The office reads the same fields the technician filled, so the quiet distrust between depot and field lost its structural reason.

The result was read from App telemetry plus time study against the pre-engagement baseline over the stated window, with a guardrail check on reports completed on-site (not from memory at the depot). Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The prototype-built capture flow spec, including offline and error states, for the vendor
• The device testing floor: minimum handset spec and the oldest-fleet benchmark results
• A ride-along research summary documenting the field conditions the design answers
• The report structure map showing which fields the legacy system ingests and truncates