Field software for people who are never at a desk

A Würth sales representative finishes a call at a workshop, walks back to the van and has maybe ninety seconds before the next thing. One hand is holding a box of fixings. It is bright out. The phone is at nineteen per cent because it has been navigating since seven. If logging that visit takes longer than the walk to the van, it does not get logged, and every figure downstream of it becomes a guess.

We built Würth's field CRM to replace a patchwork of third-party tools across roughly thirty thousand representatives. The web side was ordinary enterprise engineering. The mobile side was a different discipline, and a good deal of what we knew about designing software for people at desks turned out to be either useless or actively wrong.

The assumptions that come from the desk

Ordinary enterprise interfaces rest on a set of conditions nobody writes down: mains power, a stable network, two free hands, a flat surface, indoor light, and enough uninterrupted time to complete a form. Not one of those holds in a customer car park. They are load-bearing assumptions and they are all invisible from an office in a capital city.

When they break, the software does not fall over. That is what makes it hard to catch. Field software gets worked around instead. Representatives keep a paper notebook and enter five visits at nine in the evening from the sofa, from memory, with the location captured at their kitchen table. The dashboard shows complete data. The data is fiction, and it takes about two quarters before anyone notices that the visit records and the sales figures no longer explain each other.

Field software rarely fails outright. It gets worked around, and the workaround looks like adoption in the reports.

Connectivity is intermittent, not absent

Treating the network as a binary is the most common design error we see. Offline is easy to reason about. The genuinely hostile state is a connection that exists and does not work: two bars in a basement plant room, a lift, a train, the seam between two cells on a ring road. Requests do not fail fast. They hang.

Naive request code with a spinner and a default timeout produces the worst possible experience here. The representative watches a spinner for forty seconds, force-closes the app and reopens it, and now nobody is sure whether the record was written once, twice or not at all. We have inherited more than one field application whose duplicate-record problem was entirely a product of impatient users doing the rational thing.

The rule we hold to is that the interface never waits on the network to confirm something a human has already done. The visit happened. Write it locally, show it as saved, and treat the upload as a separate concern with its own visible state. Timeouts are short and aggressive rather than generous, because failing in four seconds and queueing is honest, and hanging for sixty seconds is not.

Battery is a specification with a number attached

If the application is the reason the phone dies at three in the afternoon, it will be closed before lunch and there is no product decision that recovers from it. Battery draw belongs in the requirements alongside response time, and it needs a target that someone tests against.

Location is where the budget goes. Continuous high-accuracy positioning for visit verification will take half a working day off a phone, and it buys almost nothing, because the question being answered is whether the representative was at the customer site when the visit was recorded. That is two moments, not a continuous track. Sampling at arrival and departure, leaning on significant-change notifications rather than a fixed polling interval, and batching uploads on a schedule and on charge rather than on every field change, all of it is unremarkable engineering with a large effect on whether anyone uses the thing at four o'clock.

The other half is the test estate. A field force does not carry current handsets. The average phone is two or three years old with a battery to match, running an operating system version a couple behind, on a plan with a data cap that matters to the person paying it. Testing on a new device sitting on a desk next to a charger says very little about any of that.

Gloves, sunlight and one hand

Capacitive touch through a work glove is unreliable and gets worse as the glove gets dirtier. Anything that matters needs a target large enough to be hit with the side of a thumb by someone who is not looking very carefully. Small controls sitting close together are a desk pattern, and they fail in a way that produces wrong data rather than no data, because the adjacent option gets selected and nobody notices.

Contrast is the one that embarrassed us. A palette that comfortably passes an accessibility audit on a monitor can be close to unreadable on a phone held at arm's length in direct midday sun with a screen that has been polished by a jacket pocket. We now review the important screens outdoors before release. It sounds like theatre. It changes the design every time.

Reach matters too. Enterprise interfaces habitually place the primary action in the top right corner, which on a large phone held in one hand is the single hardest point on the glass to get to. Primary actions belong in the lower third. So does navigation, if there has to be any.

Text entry is the enemy throughout. Every free-text field is a decision to make somebody stop walking and use both hands. Defaults, pickers, the previous value, a barcode scan, a photo, a voice note: any of these is worth an hour of engineering if it removes a keyboard from a screen that gets opened twenty times a day.

The record is captured in the moment or it is not captured

For Würth we consolidated lead, visit, pipeline and timesheet workflows that had lived in four different products into a single data model. That consolidation is the part that appears in the case study. The part that determined whether any of it worked was reducing a visit record to a handful of taps: who was seen, what came of it, what happens next. Everything else is optional or derived.

Derivation does most of the work. Time, duration, location, which customer (from proximity to a known site), which price list applies, which territory it counts against. None of that needs a human. A field that can be inferred and is asked for anyway is a small tax charged twenty times a day to thirty thousand people, and it is the reason the paper notebook comes back.

The heuristic we use when reviewing a capture screen: if recording the interaction takes longer than the interaction itself, it will not survive the first genuinely busy week.

Verification, and how it reads to the person being verified

Geolocation-verified visit tracking was a real requirement at Würth, and it is a reasonable one. Commission, territory planning and customer coverage all depend on visits having actually happened. The engineering is trivial. The politics are not.

To the representative, a phone that records where they were reads as surveillance, and if that is all it reads as, the workarounds start immediately: the phone stays in the van, the app is opened once at the start of a route, the record is entered later from somewhere convenient. A verification mechanism people are motivated to defeat produces data that is worse than no data, because it carries the appearance of rigour.

Three things helped. The representative sees exactly the record their manager sees, with no hidden fields. Location is captured at defined events rather than continuously, and the application says so plainly. And the platform gives something back on the same screen: route planning, an end to entering the same customer into three systems, timesheets that fill themselves from visits already logged. Multi-tier access mattered here as well. A regional manager sees their own territory and not the next one, which is partly a data protection requirement and partly a way of making the boundary legible to the people inside it.

What we got wrong

We designed for tablets first. The early interface assumed a ten-inch screen mounted or resting in a vehicle, because that is what the specification described and it is a much easier canvas to design for. Representatives did not carry the tablets. They carried the phone that was already in their pocket, and a good deal of the interface moved across as a retrofit rather than a redesign. Which screens had been born on a tablet was still obvious a year later.

The second one is smaller and more instructive. We shipped a sync indicator that was technically accurate and told people that three of seven records were queued, with a spinner for the current one. It was correct and nobody understood it. What a representative wants to know before they drive away is whether everything from today is safe. We replaced it with one line of plain language and a single state, and support contacts about lost data dropped almost immediately. The information had been there the whole time in a form that only made sense to the people who wrote it.

The pattern is not confined to sales

The same constraints appear anywhere the user is standing up. Ground transport is a close cousin: the booking platform we built for WTI Cabs coordinates more than 2,500 vehicles across fourteen cities, and the interface a driver touches has to work in a moving vehicle, at night, with a passenger waiting. Logistics clients, Mahindra Logistics among them, deal with a harder version again, because the person holding the device is frequently not the person who benefits from the software, which changes the adoption problem entirely.

None of this is advanced engineering. It is a long list of small constraints, each of them obvious the moment it is stated and most of them invisible from a building with a canteen. Field programmes rarely fail on architecture. They fail because the software was specified by people who were sitting down.