Designing for field teams
Your user is not at a desk. They are standing, in sunlight, wearing gloves, with one hand full. Design that looks good in the office does not survive out there.
Apps designed in offices get tested in offices: at a desk, in good light, with two hands, on strong wifi. Then they go into the field and nobody uses them.
The reason is rarely the code. The field does not satisfy a single one of the office's assumptions.
What the field is actually like
One hand is busy. The other is holding a tool, a box, a steering wheel, a door. Nothing important should live outside the bottom half of the screen.
Gloves. Small tap targets do not work. Buttons need to be large and well separated; two small icons side by side means mis-taps.
Sunlight. Light grey on white looks elegant indoors and is invisible outdoors. High contrast is not a preference, it is a requirement.
No connection. Basements, warehouses, rural sites. A "connection error, please try again" screen throws the app away.
Haste. The user does not love your app, they want to finish the job. Every extra tap raises the odds of going back to WhatsApp.
Offline is not just "store the data"
The common mistake is treating offline support as "keep it on the device, send it later". The hard part is elsewhere.
The hard parts:
- The user must know the state. Was it sent, is it queued, did it fail? Every record needs a visible status.
- Conflict resolution. What happens when two people edit the same record while offline? Silently overwriting one is the worst option.
- The queue must not jam. If ten records are waiting and the third one fails, the rest should still go.
- Storage limits. An app that takes photos can fill a phone while offline.
If these are not planned from the start, adding them later is close to a rewrite. "Let's do online first and add offline later" is one of the most expensive architectural sentences there is.
The photo flow
Most field apps involve photos, and most get this wrong.
Things to decide: whether capture happens inside the app or through the system camera, whether the image is downscaled on the device (sending a 12-megapixel photo as-is is both slow and expensive on data), where it is written while offline, and whether the user can delete a bad shot.
And sequencing: if the user takes five photos, upload them in the background rather than making them wait on an upload screen. Someone forced to wait does not take photos next time.
Remove screens
In office software, several steps is normal. In the field, every screen is a cost.
If you can turn "pick work order → open detail → change status → add note → save" into "swipe on the list, pick a status", your app becomes usable. That is not a visual improvement, it is a flow decision.
Test in the field
The most important point. Try the app with the people who will actually use it, where they will actually use it. For one day.
Things invisible in the office that surface within five minutes in the field: a checkbox that gloves cannot hit, a warning unreadable in sunlight, a list that jumps while the vehicle moves, a screen that freezes when the signal drops.
The cost of that day is nothing next to three months of "the team isn't using it" after launch.
What success looks like
For field apps, success is not download count. It is this: did the team abandon their old method?
If the WhatsApp group is still running and the paper forms are still being filled in, the app has failed even if it is technically flawless. People pick whichever option is less effort — and your job is to make the app that option.