skip to content

For a delete-confirmation modal in a pharmacy refill app, users click through it without reading and then ask support to restore prescriptions; how would you redesign it?

level: seniorimportance: should knowfreq 45%

answer

  1. confirmation fatigue
  2. generic question, generic buttons
  3. name the object and consequence
  4. reversible beats confirmed when possible

basics

~20 s

Users click through confirmations that look the same every time. Name the prescription and the consequence, label buttons with verbs, focus the safe choice, and where possible replace the confirmation with an undo so the action is reversible.

solid answer

~40 s

The diagnosis is **confirmation fatigue**: an 'Are you sure? OK / Cancel' dialog that appears for every action trains users to press OK without reading. I would first ask whether the removal can be made **reversible** — a restore period or an undo — because an undo protects users without interrupting them, and WCAG 2.2 success criterion 3.3.4 accepts reversible as one way to prevent errors. Where a confirmation stays, make it specific: a title that names the medication, a sentence saying future refills stop, verb labels like 'Remove prescription' and 'Keep prescription', and initial focus on the safe action. Build it on the Authoring Practices alert-dialog pattern so the message is announced with the title. Reserve confirmations for consequential, hard-to-reverse actions, then measure restore requests to see whether it worked.

go deeper

for a junior

Recall what a confirmation dialog needs: a specific title, the consequence, and buttons labelled with what they do.

for a middle

Explain why generic confirmations cause click-through, and how the alert-dialog pattern, safe initial focus and Escape-as-cancel make one work.

for a senior

Diagnose confirmation fatigue from support data, choose undo over confirmation where the action can be reversed, and verify the change with restore-request numbers.

for a principal

Weigh interruption cost against error cost across the product, and decide which actions the system allows to be irreversible at all.

## Diagnosing the failure A **confirmation dialog** is a modal that interrupts the user to ask whether they really mean an action. It only protects users if they read it. When every action in an app — archive, remove, sign out — raises the same 'Are you sure? OK / Cancel' dialog, users learn its shape and press the same spot without reading. This is **confirmation fatigue**, and the evidence is exactly the symptom described: users confirm, then contact support to undo. Working through the likely causes in a pharmacy prescription-refill app: - **The dialog is generic.** 'Are you sure?' does not say which prescription or what happens next. - **The buttons do not describe the outcome.** 'OK' and 'Cancel' force users to map a yes/no answer onto a question they skimmed. - **Focus sits on the destructive action**, so pressing Enter removes the prescription. - **It appears too often**, including for trivial actions, which devalues it. - **The action is irreversible** when it need not be, so every mistake becomes a support ticket. ## Prefer reversible over confirmed **WCAG 2.2 success criterion 3.3.4 Error Prevention (Legal, Financial, Data)** is Level AA. For pages that cause legal commitments or financial transactions, that modify or delete user-controllable data in storage, or that submit test responses, it requires at least one of three things: the submission is **reversible**, the data is **checked** for input errors with a chance to correct them, or there is a mechanism to **review, confirm and correct** before finalising. A confirmation dialog is one way to satisfy it, not the only one. For removing a prescription from a refill list, reversibility is usually the better route: remove it at once, show an undo affordance, and keep the record restorable for a period. The user who meant it is not interrupted; the user who slipped can recover. Keep confirmations for actions that genuinely cannot be reversed, such as permanently erasing an account's prescription history. ## Making the confirmation that remains work | Element | Weak | Strong | |---|---|---| | Title | Are you sure? | Remove Metformin 500 mg from auto-refill? | | Body | This cannot be undone. | Your next refill, due 3 October, will not be sent. You can add it back from Prescriptions. | | Actions | OK / Cancel | Remove prescription / Keep prescription | | Initial focus | the destructive action | Keep prescription | | Frequency | every removal of anything | only consequential, hard-to-reverse actions | The structure follows the WAI-ARIA Authoring Practices **alert dialog** pattern, the modal dialog meant for interrupting the user to communicate an important message and get a response — its own examples include action confirmation prompts. Its container references the alert message as the dialog's description, so a screen reader announces the consequence together with the title, not just 'dialog, OK button'. It reuses the modal dialog keyboard contract: Escape closes it, which on a confirmation means Keep. For the initial focus, the dialog pattern notes that for a final step that is not easily reversible it may be advisable to focus the least destructive action. For rare, catastrophic actions — deleting an entire account — some teams add friction such as typing the item's name. That works precisely because it is rare; applied to routine removals it becomes another habit users perform without thinking. ## Rolling it out and checking it 1. **Inventory** every confirmation in the app and classify each action as reversible, reversible with work, or irreversible. 2. **Replace** confirmations on reversible actions with immediate action plus undo. 3. **Rewrite** the remaining ones with specific titles, consequences and verb labels, as a dialog variant in the design system so product teams cannot fall back to OK / Cancel. 4. **Measure** restore requests to support and undo usage before and after; a working design shows fewer restore tickets. On native mobile the same rules hold for system-style alerts and action sheets: a specific title, a destructive action labelled with its verb, and a cancel that is always present. ## What a strong answer avoids - Treating more friction as more safety: a second dialog or a typed phrase on routine actions becomes habit just as fast. - Treating the confirmation as a legal shield: 3.3.4 accepts reversible or checked submissions as well, and a confirmation nobody reads protects no one. - Designing the dialog in isolation: the fix usually spans the action itself, the undo path and the support process that restores records.

  • Would adding a second 'Are you really sure?' step fix the accidental removals?
    No. A second generic step is learned just as fast as the first, so users click twice instead of once, and legitimate users are slowed down. The fix is making the one dialog specific, or making the action reversible so no confirmation is needed at all.
  • Does WCAG 2.2 require a confirmation dialog before any deletion?
    No. Success criterion 3.3.4 Error Prevention (Legal, Financial, Data), Level AA, covers legal, financial and stored-data changes and asks for at least one of reversible, checked, or confirmed. An undo or restore period meets it without any dialog, and actions outside its scope are not covered by it.

saying these in an interview costs you the question

  • Adding a second confirmation step will stop accidental deletes.
  • OK and Cancel are fine button labels for any confirmation dialog.
  • Every destructive action needs a confirmation dialog, however easy it is to undo.
  • WCAG requires a confirmation dialog before any data is deleted.
  • Pressing Escape on a confirmation dialog should confirm the action.