Designing mobile apps for the aisle, not the showroom

Mobile apps are designed in offices with reliable Wi-Fi and demonstrated to buyers in the same offices. They are used in a cold store, a plant yard and a basement retail store.

That gap explains most field-app abandonment. It is not a connectivity problem alone — it is a design process that never met the user.

Assume the network is absent, not intermittent

Offline-first is usually treated as a feature to add later. It is cheaper to design in from the start, because it changes the data model.

The rule: the local device is the source of truth for anything the user is doing now. Capture locally, synchronise opportunistically, never require a round trip to record work.

This means the interaction between the app and the backend is asynchronous by construction. A user completes a task, and the app is immediately truthful about it. Synchronisation is a background concern with visible status.

If you design assuming a round trip, you will spend the second half of the project retrofitting queueing, retry and conflict handling into code that assumed a response would arrive.

Conflict resolution is where these systems fail

Two devices sync changes to the same record. Now what?

This is a specification problem, and it gets skipped because it is genuinely hard. Most failures happen here rather than in the capture layer.

The approach that works is to be explicit per field about which strategy applies:

• Last write wins — acceptable for non-critical annotations. Simple, and occasionally wrong in a way nobody notices.
• Server authoritative — the backend decides. Correct for stock levels and pricing. Requires the user to be online.
• Additive — both entries kept. Right for inspections, deliveries and notes. Never loses data.
• Explicit merge — surface the conflict to a supervisor. Right for anything with financial or safety consequence.

Deciding this per field during design takes a day. Deciding it after two devices in a warehouse have diverged takes a release cycle and a difficult conversation with the customer.

Make synchronisation visible and boring

Users trust a system that tells the truth about its state. Build a simple status:

• how many items are waiting to sync
• whether sync is blocked and why
• a manual retry that always works
• a clear indicator when a record is known to conflict

Do not hide it. A sync indicator that says "3 pending" converts a support call into a five-second check.

Test in the conditions that actually occur

Device lab testing proves the app works on good Wi-Fi. Build the test cases that matter:

• hard drop mid-transaction, then restore
• airplane mode for a full shift
• two devices editing the same record
• a battery-saver mode that restricts background work
• genuinely poor signal: a lift, a basement, a plant floor

Every one of these will find something. The airplane-mode test is the most productive per hour spent.

Size the sync payload for a real network

Teams build sync that assumes a 10 Mbps connection. Field devices on cellular manage considerably less, and the operator is paying for every megabyte.

Practical consequences:

• sync deltas, not full records
• compress payloads; most JSON compresses to a fraction
• prioritise: critical updates first, bulk data on Wi-Fi only
• set explicit retry backoff so a flapping link does not drain a battery

Design the smallest useful app

The most common failure is shipping the full product spec to the field and expecting adoption.

A technician needs six actions. Everything else belongs on a desktop, behind a login the technician does not have.

Ship the six. Watch them use it. Add the seventh only when a specific person asks for it. This also keeps the offline conflict surface small, because fewer fields mean fewer divergent writes.