In a benefits application, applicants press Submit, see nothing for six seconds and press again; what feedback should the interaction give instead?

## What feedback is for **Feedback** is the information an interface returns after a person acts: that the action was received, what is happening, and what the result was. It closes what Don Norman called the **gulf of evaluation**, the gap between doing something and knowing whether it worked. Without feedback, people cannot tell a slow system from a broken one, and they fill the gap by acting again. In a benefits application, pressing 'Submit' and seeing nothing for six seconds is a textbook failure. Some applicants press again, some reload the page, some close it unsure whether their claim exists. Each response is rational given what they can see. ## Response-time bands Three limits are commonly cited in interaction design. They come from research on perception and attention, not from any standard, so treat them as rules of thumb: | Delay | How it feels | Feedback needed | |---|---|---| | Up to about 0.1 second | Instantaneous; the control seems to respond directly | The pressed control's own visual change is enough | | Up to about 1 second | Noticeable, but the flow of thought is not broken | Acknowledge the press; a separate indicator is usually unnecessary | | Up to about 10 seconds | Attention holds, but people wonder what is happening | Show that work is in progress | | Beyond about 10 seconds | Attention drifts; people switch tasks or give up | Show progress, say what is happening, let them leave safely | The six-second submission falls in the third band: it needed an immediate acknowledgement and a visible in-progress state. ## Making state transitions visible Many interactions move an object from one **state** to another. A benefits claim moves through states such as: 1. **Draft**: being filled in and saved as the applicant goes. 2. **Submitting**: the request is in flight. 3. **Submitted**: received, with a reference number. 4. **Under review**, and finally **decided**. Good feedback names each transition as it happens. The confirmation after submission should say in words that the application has been **submitted** (not merely saved), give the **reference number**, say **what happens next and when**, and say how the applicant will be contacted. A generic 'Success!' fails because the applicant cannot tell which action succeeded. Feedback should also be **proportionate** and **lasting enough**. A small tick that fades after two seconds may be missed; the claim's current state should be visible wherever the applicant looks for it later. ## Microinteractions A **microinteraction** is a small, single-purpose interaction: saving a draft, uploading one document, switching a notification preference. A widely used model breaks one into four parts: - **Trigger**: what starts it, a person's action or a system condition. - **Rules**: what happens, and in what order. - **Feedback**: how the person learns what the rules did. - **Loops and modes**: how it behaves over time or on repeated use. Thinking in these parts exposes missing feedback. 'Auto-save draft' has a system trigger and invisible rules; without a quiet 'Saved just now' message, applicants cannot trust it and may retype their answers. ## Preventing the double submission Feedback reduces repeat presses; it does not rule them out. Networks retry, people double-tap, pages reload. A robust design layers: - an **immediate visual response** from the pressed control; - an **in-progress state** that ignores further presses of the same action while the request is in flight; - **server-side idempotency**, so a repeated submission of the same application is recognised rather than recorded as a second claim; - a **clear end state**, so the applicant knows there is nothing left to press. The interface prevents most repeats, and the server makes the rest harmless; neither is enough alone. ## Feedback across platforms and people The principle is platform-neutral; the channels are not. Native mobile apps can add haptic feedback to a press. Every platform needs to expose status changes to assistive technology: WCAG 2.2 success criterion 4.1.3 Status Messages (Level AA) asks that status messages can be presented to assistive-technology users without receiving focus, so a screen reader user hears that the application was submitted just as a sighted user sees it. Feedback that exists only as a colour change or a brief animation reaches fewer people than feedback in words.