Originally published:2025-11-18 · Last updated:2025-11-19

On writing software for people who work outside

Most software is designed by people sitting at desks, for people sitting at desks. When that software ends up being used by people who are standing in a field in the rain, wearing gloves, squinting at a screen in direct sunlight, the mismatch becomes immediately apparent.

The environment changes everything

Outdoor and field use introduces constraints that are invisible in normal development and testing:

• Sunlight readability. A screen that looks fine indoors is unreadable in direct sunlight. High contrast, large text, and reduced reliance on colour differentiation are not accessibility features in this context — they are basic usability requirements.
• Gloved hands. Capacitive touchscreens do not respond reliably to gloved fingers. Any workflow that requires precise touch interaction will fail. Large tap targets and hardware button support where available are not nice-to-haves.
• One hand. Field workers frequently have one hand occupied. Workflows that require two hands to navigate are workflows that require the user to put something down, which may not be possible.
• Intermittent attention. A field worker is not staring at the screen. They glance at it between tasks. State must be obvious at a glance; the user should never have to reconstruct where they are in a workflow.

Failure modes matter more outside

In an office, a software failure is an inconvenience. In the field, it may mean a wasted journey, a missed measurement window, or a safety issue. Software for field use should fail gracefully and loudly, not silently and confusingly.

This means offline capability where connectivity cannot be guaranteed, explicit error states that tell the user what happened and what to do next, and data that is saved locally before it is sent anywhere.

The best interface is less interface

The temptation when building field software is to port the full desktop or web experience to a mobile form factor. The correct approach is to ask what the minimum viable interaction is for each field task and build only that.

A field worker collecting a measurement reading does not need a dashboard. They need to see the current value, confirm it looks right, and record it with one tap. Everything else is overhead.

Summary

Software for people who work outside requires deliberately different design decisions than software for office use. The constraints are physical and environmental, not technical. They are also consistent and well understood — the difficulty is not in solving them but in remembering to account for them when the entire development team is sitting indoors.