Designing forms for partial failure

Building a form that works when everything works takes an afternoon. Building one that behaves well when something does not is the part that separates a form people complete from one they abandon.

The failures are not exotic. A flaky mobile connection. A tab left open for forty minutes. A backend that takes eight seconds instead of two hundred milliseconds. A visitor who double-taps because nothing seemed to happen.

Each of those is common enough to happen to a real percentage of your submissions, and each has a design response that costs almost nothing.

It is worth being concrete about the scale. Even a low single-digit failure rate on a form that receives a few hundred enquiries a year means a handful of people every year who tried to reach you and concluded you were not interested. None of them will tell you, and the delivery log will not show them either, because their submission never arrived.

What they have in common is that the visitor cannot tell what went wrong and can only act on what your page shows them.

The cardinal rule. If a submission fails for any reason, the fields must still contain what the person entered.

Clearing the form optimistically on submit is the single most damaging pattern in form design, because the failure it interacts with is exactly the one where the person needs to try again. A visitor who has just lost a three-paragraph message does not retype it.

The related failure is a page that navigates away before the request completes, which turns a slow response into a lost message with no error at all.

Keep the values until you have a success. Everything else in this article is a refinement; this one is the difference between a recoverable failure and an abandoned enquiry.

Slow is not the same as broken, and most forms treat them identically or not at all.

A request that has been in flight for ten seconds should be telling the visitor something. A request still in flight at thirty seconds should be offering an alternative rather than continuing to spin.

The reason this matters is that the visitor's model of what happened determines what they do. Silence for thirty seconds reads as failure, so they submit again, and now you have a duplicate and a confused person.

A spinner that becomes still taking longer than usual after a few seconds costs one line of code and removes most of that.

Something went wrong is the least useful sentence in software. It tells the reader nothing they did not already know and offers nothing to do.

The three failures a visitor can experience deserve three different messages. A validation problem should say which field and why, next to the field. A network problem should say the message was not sent, invite a retry, and give an email address. A server problem should say the same, because from their side it is identical.

Notice that two of those three end with an alternative route. That is the part almost every form omits, and it is the part that saves the enquiry when your form genuinely cannot work.

A visible email address on the contact page is not a failure of design. It is the fallback that makes every other failure survivable.

A confirmation should mean the submission was accepted and stored, not that a request was sent.

This sounds obvious and is frequently wrong in practice, because it is easier to show the thank-you state when the request completes than to check what the response said. A form that shows success on any response, including an error, is actively harmful: it tells the visitor to stop worrying about something that did not happen.

The inverse error is showing a failure when the submission was accepted but a later step failed. If a submission is safely stored and only the notification email failed, the visitor should see success, because their part worked.

The rule is that the confirmation reflects acceptance, and everything after acceptance is your problem rather than theirs.

A form whose submission depends entirely on JavaScript has one more failure mode than a form that also works without it: a script that fails to load, an error earlier on the page, an aggressive extension.

Building the form as a plain HTML post that works on its own, then enhancing it with a script that improves the experience, means the underlying capability survives all of those. This is progressive enhancement applied to the one feature where losing it is expensive.

The enhanced version can do the nicer things: submit without a page reload, show inline errors, keep the visitor in place. The base version just works.

It is one of the few architectural decisions in front-end work that reduces both complexity and risk at the same time.

A form split across several screens has more places to lose work, and the loss is proportionally more painful because the visitor invested more.

The defence is to persist between steps rather than accumulating everything in memory until the final submit. Even browser-local storage is enough to survive a refresh or an accidental back navigation.

It is also worth capturing partial progress deliberately if the form is long. A person who completed four steps of six and left is a real signal even without a completed submission, and if your first step collects a contact method you have something actionable.

The alternative, where an abandoned multi-step form leaves you with nothing at all, discards information you already had.

All of this is testable in a browser in about fifteen minutes with no backend changes.

Submit with the network offline and check the fields still hold their contents. Submit on a throttled connection and watch what the page communicates while waiting. Submit twice quickly and see whether the interface prevents it. Disable JavaScript and check the form still functions.

Then read your own error message as though you were a visitor who does not know what a backend is.

Most sites fail at least two of those tests, and each failure has a fix measured in lines rather than days.

Two things, and they are the counterparts of the page-side rules.

It must not couple acceptance to delivery, because that turns every downstream dependency into a reason to reject the visitor's message. And it must not return an error for a failure that happened after the submission was safely stored.

Those two properties are what make honest confirmation possible at all. A page cannot confirm accurately if the response it receives does not distinguish between not saved and saved but not yet delivered.

The rest of the pipeline design follows from there, as the delivery path sets out.

Preserve what they typed. Distinguish slow from broken. Give an action in every error, and an alternative route in the ones you cannot fix. Confirm acceptance rather than optimism. Make the base version work without scripts.

Six rules, all cheap, and together they convert most of the failures your visitors actually encounter from lost enquiries into brief inconveniences.

The measure of success is not that failures stop happening, because they will not. It is that a failure produces a visitor who tries again or emails you, instead of one who leaves believing they made contact. On a contact form that difference is the entire value of the page.

What is the single most important rule?

How long should a form wait before showing a timeout?

Should the form work without JavaScript?

What should an error message say?

Is showing success on any response ever acceptable?

How do I handle abandonment in a long form?

Does a fallback email address undermine the form?

Can I test all this without a staging environment?