Product design and design system
A scheduling tool for field teams, redesigned around the ninety seconds a technician actually has — and a design system three squads could ship from.
Sundial schedules field technicians for utilities and building services. Their product worked for dispatchers and failed for the people in vans, who were the ones who had to use it in the rain, on a cracked phone, with gloves on. We were brought in for a redesign and spent the first three weeks in vans.
01 — The problem
Sundial's field app had 94% of the dispatcher product's features and about 10% of its usability. Technicians kept a paper list because the app took too long to answer the only question they had: what am I doing next, and where.
Adoption metrics looked fine — the app was opened constantly. It was opened constantly because nobody could find anything.
02 — The thinking
We rode with eleven technicians across three cities and timed every interaction. The median useful window between arriving and starting work was ninety seconds, usually one-handed, often wet.
So the field product was rebuilt around three answers — next job, address, and what is wrong — reachable in three taps from a cold start. Everything else moved behind a deliberate second layer. Feature parity with the dispatcher product was abandoned on purpose, and that was the hardest conversation of the project.
03 — The making
Sundial had three product squads and three divergent interpretations of the same components. We delivered a design system with a deliberately small surface — 24 components, each with its states, its accessibility contract and its do-not-use notes written in plain language.
Touch targets start at 48px because we measured gloved taps. Contrast floors were set against readings taken outdoors in direct sun, not in a dark room. Both rules are in the system as measurements with their source, so nobody has to relitigate them.
04 — The result
The clearest signal was not in the analytics. Within two months of rollout, the technicians we had ridden with had stopped printing their own job lists — the app had finally become faster than paper.
Behind the decisions
Matching the dispatcher product was the cause of the problem, not a constraint on the solution. We wrote down what field users would lose and got sign-off on it explicitly.
44px is the guideline for a bare fingertip. We measured gloved taps in a van and missed targets until 48px, so the system carries the measurement and its source.
A larger library would have preserved three dialects. A small one forced the squads into the same vocabulary within one release cycle.
Selected artefacts
Outcome
3 taps
Down from eleven.
24
Shared by three product squads.
48px
Set by gloved-tap testing, not by guideline.
“They spent three weeks in vans before showing us a single screen. Everything difficult about the project got easier after that.”
Credits
Research
Owen Mbeki, Priya Raman
Product design
Priya Raman, Hana Okada
Design system
Teo Marchetti
Services used
Start a project
A 45-minute call with the people who would do the work. If we are not right for it, we will say so and suggest who is.
