A person finishes a long application form, presses Submit, and sees a spinner. After a while, the spinner disappears. The form remains on screen with no confirmation. They press Submit again, then refresh the page. Later, two confirmation emails arrive.
The issue might enter a backlog as duplicate submissions. That description identifies a technical outcome, but it leaves out the uncertainty that preceded it. The person could not tell whether the first attempt had worked, whether their answers were safe, or what action would help. Their second click was a response to the information available.
Bug reports can provide clues to these gaps. Following them requires looking beyond the failing component to the task, the expectations the interface created, and the work needed to recover.
Reconstruct the Interrupted Task
Start with what the person was trying to accomplish. In this example, submitting the form was the final step in an application. The relevant experience includes the time spent entering answers, any documents attached, and what the person expected to happen after pressing the button.
A useful report records the sequence of actions and the visible result at each step. Include the conditions that might matter, such as a slow connection, an expired session, or returning to a tab after an interruption. Keep observations separate from explanations: the absence of a confirmation is something the person saw; a failed database write is a hypothesis until there is evidence for it.
This account gives the debugging investigation a clearer starting point. It also gives the designer something specific to examine: which decision did the interface leave the person unable to make?
Treat Workarounds as Questions
Repeated clicks might indicate missing feedback. Copying answers into another application might indicate concern about losing work. Asking support whether a submission arrived might indicate that the confirmation is difficult to find or trust.
Those interpretations need checking. A second click can also be accidental, and a copied answer may simply be part of someone's established workflow. Ask people what they expected and why they chose their next action. Where observation is possible, watch the task unfold rather than relying only on a summary written after the problem has passed.
A single report does not establish how common an issue is. Equally, few reports do not establish that a task is easy. Some people abandon the process without contacting support. Combine reports with task completion evidence and direct research, while recognising what each source cannot show.
Make the State Understandable
For the application form, several states need different treatment. Before submission, the person can edit their answers. While a request is pending, they need to know that processing has begun. After confirmation, they need a durable indication that the application exists and a way to return to it.
A lost response introduces another possibility: the server may have accepted the application even though the browser cannot confirm it. Showing a definite failure would overstate what the system knows. The product needs a way to resolve that uncertainty, such as looking up the submission using an identifier associated with the attempt.
The language on screen should follow the state the system can establish. A message saying that confirmation is still being checked is useful only if the application actually performs that check. Clear wording depends on an implementation that can support the promise.
Design the Route Back to the Task
When an input problem prevents submission, tell the person what needs attention and preserve the valid work around it. The W3C's guidance on error identification explains that automatically detected input errors must identify the affected item and describe the error in text. A coloured border alone does not provide that explanation.
For the form, a missing attachment should lead to the attachment control with enough context to correct the problem. It should not require re-entering an address or reconstructing a long answer. If a session has expired, the design should consider whether the person can authenticate again and safely resume.
Preserving work also requires a storage decision. Sensitive answers should not be saved indefinitely on a shared device simply because persistence is convenient. Establish what is retained, where, and for how long. The questions behind local-first design are useful here: which work can remain available when a remote operation is interrupted, and what protection does that work need?
Check Whether Feedback Reaches the Person
A confirmation can be present visually while remaining difficult to perceive through assistive technology. The W3C's guidance on status messages addresses making qualifying updates programmatically available so assistive technologies can present them without requiring focus to move to the message.
That does not mean announcing every background event. For this form, the important information is whether submission is in progress, needs attention, or has completed. The interaction should be examined with keyboard navigation and the assistive technologies relevant to the product, including whether the person can find and act on an error.
A fleeting notification may also be inadequate for someone who looks away or changes tabs. A confirmation page or persistent submission record gives the outcome a place to live after the initial announcement disappears.
Repair the Cause and the Conditions Around It
Preventing duplicate submissions needs protection beyond disabling a button. A request may be retried after a connection problem, and a person may return from another device. The service needs an appropriate way to recognise repeated submission of the same intent. The interface still needs to communicate what happened and support recovery.
Use the original report to define scenarios for reviewing the fix: a slow response, a lost confirmation, an input error, and a return to the form after interruption. A mock server can make selected responses and delays repeatable while the team examines the experience.
After release, look for evidence that people can complete the task with less uncertainty. Fewer duplicates are useful evidence, but check that the change has not simply made submission harder. Completion, abandonment, support questions, and direct observation together can give a more credible account.
The bug becomes a breadcrumb when it leads the team to a question the interface had failed to answer. Following that clue can produce a better submission flow: one that records the application correctly, preserves the person's effort, and makes the next step clear when something goes wrong.