What field technicians need in an app — four conditions that decide it

An app for a field crew is usually designed at a desk, demonstrated at a desk and bought at a desk. The person who has to use it is standing on a ladder at the time.

The conditions it actually runs in come down to four points. Almost everything worth knowing before you buy follows from them.

Four boundary conditions#

One free hand. The other holds a part, a tool or a ladder. Any gesture needing two hands means putting something down and picking it up again.

A screen in direct sun. Phone brightness does not win against midday. Grey text on white disappears, thin field outlines disappear, and subtle colour differences between states stop meaning anything.

Gloves. A capacitive screen responds less precisely through a glove, and some gloves do not register at all. Taking them off for every interaction is a cost that pushes the report to the end of the day.

A four-year-old phone. Usually a personal one, with full storage and a battery that throttles by mid-afternoon. An app that takes eight seconds to load will be opened once a day, not once per job.

These are not edge cases. In field work, this is the default.

Touch target size#

The reference point for a field interface is physical, not digital: a thumb pad inside a glove. Anything you have to hit must be bigger.

Several things follow, all easy to check in a trial:

Fewer elements per screen. A handful, not a dozen. A list where every row carries four icons on the right was designed for a mouse pointer.

No action available only as a gesture. Swipe, long-press, double-tap — each is unreliable through a glove and none is visible on screen. A gesture can be a shortcut; it cannot be the only route.

Irreversible actions well away from daily ones. If "close job" and "delete job" sit side by side, sooner or later a gloved thumb finds the second one.

The main action at the bottom. The top edge of a large phone is out of thumb reach one-handed. A button up there means shifting the phone in your grip — the hand that is not free.

Steps to the most frequent action#

Pick the action a technician performs most often — usually adding a photo, or marking the work done. Count the taps between a locked screen and that action finished.

That number matters more than a feature list, because it multiplies. At eight technicians, six jobs a day and thirty seconds of difference per job, that is twenty-four minutes a day — roughly one extra job a week, without hiring anyone.

The real cost is not in minutes, though. An action that takes too long stops being done on site: it moves to the end of the day and gets reconstructed from memory. Data produced from memory after eight hours of physical work is worse than no data, because it looks credible.

A photo is a data type, not an attachment#

In field work a photo is the fastest way to record the state of something: more accurate than a description, a second's work, no keyboard. Most tools still treat it as an attachment to a form, something added at the end.

Reversing that order changes the work. Camera reachable straight from the job, photo attaching itself to the right line, description optional.

Three things decide whether a photo is worth anything six months later:

Context captured automatically. Job, time, author, stage of work. If it has to be typed in, it will not be.

Findability. A few thousand images in a phone gallery are not documentation. Photos reachable from the site they belong to are.

A caption nobody has to write. One of the few places where a language model pays for itself immediately: it describes the photo and a person confirms it with one tap. The confirmation is the condition — a description filed with nobody approving it is an entry nobody is answerable for.

A map instead of a table#

The questions asked in the field are spatial. Where is it. What is on my route. Will I make it before four. A table answers a different question — which jobs exist and in what state — the right view for a desk.

For a technician the minimum is today's jobs ordered by distance and navigation launched with one tap from the job. Without that, the address gets retyped by hand into another app anyway.

Both depend on the address being data in the system, not text in a description field. A freely typed address looks identical on screen, and you can build neither a map nor a distance sort out of it. That difference is invisible in a demo and decides half of what the tool is worth.

How to check the app before you buy#

A trial evaluated in the office tells you nothing. The conditions have to reproduce a working day, not a meeting room.

Take the oldest phone in the company. Not yours — the one used by someone who has not replaced a handset in four years.

Go outside in the middle of the day. In work gloves, with your other hand in your pocket, literally, for the whole test.

Walk the full path and count the steps. Not "can it be done", but how many taps and how many seconds.

Give it to a technician, not your most enthusiastic foreman. Ideally someone who already thinks the whole thing is unnecessary. Their result is the real one.

Repeat it a week later with no prompting. An interface that has to be learned twice will not be remembered.

Summary in one paragraph#

Four boundary conditions — one hand, sun, gloves and an old phone — are enough to judge a field app without reading its feature list. Check the touch targets, count the steps to the most frequent action, and check whether a photo is a first-class data type and an address real data. Everything else is secondary to whether the person in the field opens the app a second time. The wider context — organising crew work, the licence economics, the rollout itself — is in the guide on managing field teams.