Your form timed out. Help users check before they submit again
You fill in a form, choose Submit and wait. Then the page says “Something went wrong. Try again.” Did the request disappear, or did the service receive it without sending a reply?
That uncertainty is a product decision as well as a technical problem. A second click might create extra work, while leaving someone with no next step makes them investigate the failure themselves. Product, design, development and support colleagues need an agreed answer.
This guide helps you map one interrupted submission, write honest status messages and agree how someone can check the result before starting again.
Trust includes the awkward moment after Submit
Mind the Product’s 26 October 2026 recap of Kathy Pham’s keynote argues for treating trust as a product feature. This exercise takes a narrower, everyday case: explaining an interrupted form submission without claiming more than the system knows. It is an evergreen design exercise prompted by recent coverage.
A timeout is the point at which a caller stops waiting for a response. It does not, by itself, establish what happened at the receiving service. Amazon’s engineering guidance on timeouts and retries explains that an operation may have taken effect even when the caller sees a timeout or failure. Retrying can also add load.
Separate three ideas: “we are waiting”, “we know the result” and “we cannot confirm the result”. Treating all three as failure creates misleading instructions.
An example: requesting a loan laptop
Jun requests a loan laptop for a training session. The proposed service creates an attempt reference, Q17, before submission and associates it with any request it records. That lets an authorised status check look up the same attempt, even if the reply is lost.
These are design assumptions to verify with an engineer, not features to assume every form has. Q17 identifies the submission attempt; it is not proof that a laptop is reserved or that the loan has been approved.
Jun chooses Submit. The page waits, then receives no usable result. The team should design the next screen around evidence, rather than guessing that nothing happened.
| What is confirmed? | What can the screen say? |
|---|---|
| A request record exists for Q17. | “Request L204 received. View its status.” Received does not mean approved. |
| The service confirms rejection before creating a request. | Explain that reason and how to correct it. Do not describe an unknown result as rejection. |
| The service confirms Q17 is still processing. | “Your request is still processing.” Provide the agreed check or support route. |
| The status check cannot establish the outcome. | “We cannot confirm whether this request was received.” Keep the uncertainty visible. |
Design the next action with the technical owner
1. Give uncertainty a useful message
Purpose: Say what is known and offer a route the service actually supports.
For the unresolved case, proposed copy is: “We could not confirm whether your laptop request was received. Check attempt Q17 before submitting again.” A Check request control should retrieve status, not silently create another request.
If no reliable check exists, name an established support route and the reference it needs. Do not invent a response deadline. Keep useful entered answers available according to the agreed privacy and storage rules; avoid promising that details are saved unless that behaviour has been verified.
2. Agree what repeating the action means
Purpose: Prevent the recovery instruction from creating another problem.
An engineer may use an idempotent operation: repeating the same intended action does not create additional effects. Amazon’s guidance on safe retries explains why this matters for operations that change records. A reference displayed on screen is not, by itself, duplicate protection.
Agree how the service recognises the same attempt, how long that protection applies and what happens when the details change. Disabling Submit can reduce repeated clicks in that page, but cannot settle what an earlier request did. Do not label retrying “safe” until the underlying behaviour is implemented and checked.
3. Make the status available to everyone
Purpose: Ensure the recovery information can be found and understood.
Use readable text, not just a spinner, colour or icon. Label the check and support controls by their purpose and test keyboard use. Distinguish received, processing and approved consistently across the page, email and support view.
For status updates added without moving focus, W3C’s explanation of WCAG status messages describes making the information available to assistive technology through appropriate roles or properties. Check the implementation with the team’s accessibility testing approach; this design exercise does not establish conformance.
Rehearse the missing reply
In an authorised test environment with invented data, ask an engineer to arrange two controlled cases. First, stop the submission before the service stores it. Second, let the service store it but withhold the reply. Those different outcomes can look identical to Jun.
Follow the proposed check route in both cases. Record the visible message, the actual stored records and whether another action creates a duplicate. Include a failed status lookup. If a result remains uncertain, the screen should keep saying so rather than turning an empty search into reassurance.
Use this short agreement before implementation or review:
Choose one existing form and trace what happens after an interrupted submission. Finish with one agreed status message and one verified next action. If the system cannot support that action yet, record the gap before publishing the instruction.
You May Also Like
Customers are leaving. How do you find out whether the product is the problem?
How to write an accessibility bug report a developer can reproduce
