In a government benefits application, many applicants enter wrong bank details and some withdraw claims by accident; how would you apply error prevention and recovery principles?

## Slips and mistakes Error prevention starts with knowing what kind of error you are preventing. A classic distinction from human-error research, popularised in design by Don Norman: | Type | What went wrong | Benefits-application example | Best defence | |---|---|---|---| | **Slip** | Right intention, wrong execution | Two digits of a known account number swapped while typing | Constraints, checks, forgiving input, undo | | **Mistake** | Wrong intention, from a wrong understanding | Entering a partner's account because the question seemed to allow it | Clearer questions, explanations, a better mental model | A check on the digits cannot catch a mistake, because the numbers are valid; a clearer question cannot stop a slip, because the applicant already understood it. Classifying the errors first, from support contacts, correction data or observation, tells you which tools to reach for. ## Prevention: constraints and forgiving input **Constraints** make wrong actions impossible or unlikely. The best ones are unnoticeable when used correctly and explain themselves when hit. - **Say the rule up front.** If payments can only go to an account in the applicant's own name, say so in the question, not after submission. - **Accept harmless variation.** Account numbers typed with spaces or dashes should be accepted and normalised, not rejected. Over-strict formats create errors rather than preventing them. - **Check early.** Where the account format has a known length or a check digit, verify it as soon as the field is complete, while the applicant still has the details in front of them. - **Use good defaults.** Pre-fill what the service already knows, with a way to change it, so fewer values are typed at all. - **Separate dangerous actions.** Keep 'Withdraw claim' away from 'Continue', and word it so it cannot be mistaken for a navigation step. ## Checking before commitment For consequential data, show it back in plain words before it becomes final: 'Payments will go to the account ending 4821, held in the name of J. Rivera.' Seeing the name and the last digits catches slips that typing did not. A review step listing every answer with a way to change each one does the same for the whole application. For web content, WCAG 2.2 makes this a requirement in exactly this situation. **Success criterion 3.3.4 Error Prevention (Legal, Financial, Data)**, Level AA, covers submissions that cause legal commitments or financial transactions, modify or delete user-controllable data, or submit test responses, and requires **at least one** of three safeguards: 1. **Reversible**: the submission can be reversed. 2. **Checked**: entered data is checked for input errors and the user can correct them. 3. **Confirmed**: the user can review, confirm and correct the information before finalising. A benefits claim is squarely in scope, and a well-designed service usually provides more than one. ## Recovery: prefer undo to warnings Accidental withdrawal is a slip on a destructive, consequential action. There are two broad ways to handle it: - **Confirmation**: ask 'Are you sure?' before withdrawing. It interrupts every withdrawal, including every intended one, so people learn to accept it without reading, and the accidental case gets through anyway. This is **habituation**. - **Reversibility**: let the withdrawal happen, then make it undoable, at once through an undo action and for a grace period by reinstating the claim. The intended path costs nothing and the accidental one is rescued. Reversibility is usually the stronger design. Confirmation still has a place for actions that genuinely cannot be undone, and it works better when it names the specific consequence ('Your claim will close and payments will stop') than when it asks a generic question. ## Error messages that help recovery When an error does occur, the message is part of the recovery path: - say **what** went wrong and **how** to fix it, in the applicant's words, not in system codes; - keep what the applicant entered, so fixing one digit does not mean retyping everything; - tie the message to the place where the problem is, so people can go straight to it. WCAG 2.2 sets a floor here too: 3.3.1 Error Identification (Level A) requires detected input errors to be identified and described in text, and 3.3.3 Error Suggestion (Level AA) requires known corrections to be suggested unless that would jeopardise security or purpose. Exact placement and timing of messages is a matter of form design; the principle is that every error message is a step back onto the path. ## Knowing whether it worked Track outcomes, not screens: how many payments fail because of wrong bank details, how many withdrawn claims are reinstated, how many applicants contact support to correct an entry. A falling rate of failed payments is evidence that prevention works; reinstatements show the recovery path is being used, which is far better than those applicants having lost their claims.