Build for the connection you have. Not the one you wish for.

A sample opinion piece. Scenarios are hypothetical and imagery is illustrative.

Picture a merchant completing an order on her phone. The customer is waiting, the stock is packed, and the connection disappears just as she taps confirm. What should the screen say?

“Something went wrong” is technically plausible and practically useless. She needs to know whether the order exists, whether the money moved, and whether trying again will create a duplicate. This imagined moment belongs in a product brief long before the team chooses its animations.

Make uncertainty visible

A reliable interface distinguishes between saved on this device, waiting to sync, confirmed by the server, and failed. Those states carry different promises. Collapsing them into a single green tick creates confidence the system has not earned.

For payment-related actions, an offline screen must never imply that a payment has cleared. The product can preserve an order draft while making the pending payment state explicit.

Resilience is something a person should be able to understand, not just something an engineer can explain.

Design the retry before the happy path

Decide what happens when a request arrives twice. Decide how the device reconciles a local change with a newer server version. Decide how users recover work after closing the app. These decisions shape both the data model and the interface.

Keep essential screens light. Let people review previously loaded information without fetching it again. Make large downloads optional, and explain their size before they start. A small payload is a product feature when someone is paying for each bundle of data.

Test outside the office

A fast office connection conceals weak assumptions. Test with intermittent connectivity, slow requests and interruptions during a save. Include older devices, low storage and the experience of returning to the app after a long pause.

• Can a person tell what has and has not been saved?
• Can they safely retry without duplicating an action?
• Can they leave the screen without losing their work?
• Can they recover without contacting support?

The lesson travels

Designing for a market in Kisumu can teach the same discipline needed for a delivery driver in Manchester or a field technician in rural Canada. Connectivity is a condition that changes. Good software makes that change manageable.