Designing forms for
connections that drop

The standard advice for form design assumes the network is a given. Yours might load slowly, the thinking goes, but it will be there. In most of the places I've worked, that assumption is the first thing to break. The link is there at 07:40, gone at 07:43, and back — maybe — after the person filling in your form has given up and gone to do their actual job.

So the design question is not "how do I make this form pleasant?" It is: what happens to this person's work when the connection disappears halfway through? If the answer is "they lose it", your form will be filled in exactly once. People forgive slow. They do not forgive losing five minutes of careful input, and they are right not to.

Treat the network as a user

The mental shift that helped me most: the network is a participant in the form, and it is the least reliable one. It joins late, leaves without warning, and never apologises. Once you design for that user, the rest follows.

Default to normal

In any recurring status report, the overwhelmingly common case is that nothing is wrong. Design for that case first. In the daily service checklist I run, everything defaults to OK — a normal morning is one tap and submit. Reporting only becomes laborious when there is genuinely something to report, which is exactly when people are willing to spend the effort.

This is also a connectivity decision, not just a courtesy. The shorter the interaction, the smaller the window in which the link can fail. A form that takes twenty seconds fits inside most outages' gaps. A form that takes four minutes does not.

Minimise round trips, ruthlessly

The first version of my checklist did what the tutorials show: each field talked to the server as the user went. On a good connection you never notice. On a bad one, every field becomes a place the form can die.

The fix was structural: load the service list once into a local collection at the start, let the user work entirely against that local copy, and write everything back in a single operation at the end. One read, one write. The connection now has exactly two opportunities to ruin someone's morning instead of forty — and if the write fails, the user's work is still sitting in the local collection, ready to retry, not gone.

Make the failure path boring

When the submit does fail, what the user sees next decides whether they ever trust the form again. The bad version is a spinner that never resolves, or worse, silence. The good version says plainly: nothing was lost, tap again when the link is back. Boring, explicit, calm. In my experience users tolerate almost any failure that is honestly reported and cheap to recover from.

Escalation belongs to the system, not to people

This one isn't about bandwidth, but it decides whether daily reporting survives contact with month two. If a human has to notice who hasn't submitted and chase them, the process is already dead — chasing colleagues is socially expensive and nobody does it for long. A scheduled flow that checks submissions and sends the reminder itself costs nothing socially and never gets bored. The escalation being automatic is what makes it sustainable; the reporting being easy is what makes it fair.

What I got wrong

Two things, and they were both attempts to be impressive. The per-service interaction — set a status on every line individually — made a good day as much work as a bad one, which inverts the incentive you want. And the map visual I used for location health looked far better in a demo than a plain grid, while being harder to actually read at 08:00 with coffee in one hand. Replacing the map with a status matrix felt like a downgrade for about a day. It has been the right call every day since.

← All field notes