Choose typed confirmation when one accidental activation could delete or reset a repository, project, workspace, account, production dataset, root credential, or broad permission scope and the user must prove they are targeting the exact object.
Choose typed confirmation when one accidental activation could delete or reset a repository, project, workspace, account, production dataset, root credential, or broad permission scope and the user must prove they are targeting the exact object.
Practice the judgment: Imagine this situation: The system accepts a partial or wrong-case repository path even though the UI claims exact target verification. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Typed confirmation | Destructive action confirmation | Confirmation dialog | Password input |
|---|---|---|---|---|
| UI or UX | UI + UX - Exact target phrase gate before severe commit | UI + UX - Final destructive commit review | UI + UX - Consequential alert decision | UI + UX - Authentication secret entry control |
| UI guidance | Render a visible non-secret text field inside a destructive or high-consequence confirmation, labelled with the exact target phrase the user must type before the final action enables. | Render a destructive confirmation after the user invokes a destructive command, with a title and final action button that repeat the destructive verb and target, such as Delete workspace or Cancel subscription. | Render an alert-style modal decision with a specific title, consequence description, safe cancellation, and a destructive action label that names the object or scope. | Render password entry as a labelled password field that is hidden by default, uses the correct autocomplete purpose, offers a clear show and hide control, disables spellcheck and automatic capitalization, and keeps helper and error text connected to the input. |
| UX guidance | Use typed confirmation only when reproducing the target phrase meaningfully reduces severe wrong-object or wrong-scope mistakes, such as deleting a repository, project, account, workspace, production dataset, or root credential. | Make the safe path explicit and easy, keep the destructive action unavailable until required review is satisfied, and report whether the object was kept, blocked, or permanently committed. | Help the person reach a clear task outcome. | Use password input when a user enters an existing secret to sign in, reauthenticate, unlock a protected action, or confirm account ownership. |
| Good UI | Delete repository acme/payments-api? requires typing acme/payments-api, shows a mismatch until the exact path matches, and then enables Delete repository. | Delete Payments project? lists 4 dashboards, 12 saved views, 3 webhooks, and 8 shared links, offers Keep project, and labels the danger action Delete Payments project. | Delete Research archive? explains that 14 notes and shared links will be permanently removed, offers Keep archive, and labels the danger action Delete archive. | A reauthentication dialog asks for Current password, lets the user show it temporarily, accepts a pasted manager value, and clears the field after an incorrect attempt. |
| Bad UI | The typed field is masked like a password, making users unable to check the repository name they entered. | A soft archive action opens the same severe deletion confirmation used for permanent account closure. | The red destructive action is enabled immediately and sits where users expect the routine primary button. | A login form uses a normal text field named Password and leaves the secret visible on screen. |
| Good UX | A user starts deleting acme/payments-api, mistypes the repository path, sees the mismatch, and cancels before deleting the wrong repository. | A user opens Delete workspace, reviews the object count and webhooks, cancels, and returns to the same workspace with nothing changed. | Cancel, Escape, and Keep archive leave the archive unchanged and return focus to Delete archive. | The person reaches the intended result with clear feedback. |
| Bad UX | A user believes typing the phrase is the only safeguard, but the dialog hides forks, members, billing effects, and recovery limits. | A user confirms deletion because OK looks like the primary next step, then discovers shared links and child reports were lost. | Every archive, filter, and dismiss action opens the same confirmation until users click through automatically. | A failed login page says the password is wrong, confirming that the username exists. |
| Best fit | A severe action affects repository, project, workspace, account, production, security, billing, or organization-wide scope. | A user has initiated a destructive command that can permanently remove, revoke, reset, deactivate, or cancel something valuable. | The action is destructive, irreversible, costly, security-sensitive, privacy-affecting, or externally visible. | The user needs to enter an existing password, passphrase, or PIN-like memorized secret. |
| Avoid when | The action is routine, reversible, local, or recoverable through undo or trash restore. | The action is a routine reversible archive, hide, dismiss, move, reorder, or trash move. | The action is routine and easily reversible. | The task is choosing a new password and needs creation-specific guidance, strength feedback, and blocklist rejection. |
| Required state | Required phrase state showing the exact target phrase to reproduce. | Review state that names the destructive verb, target object, and affected scope. | Pre-action state with an explicit consequential trigger. | Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control. |
| Accessibility burden | Associate the input with a label that includes or references the required phrase. | Use alertdialog semantics or platform equivalent when the destructive decision requires an immediate response. | Use alertdialog semantics or platform equivalent when the decision is urgent and requires a response. | Use a visible label that names the password purpose, such as Password or Current password. |
| Common misuse | Requiring users to type yes, confirm, or delete instead of the target name. | Labelling the destructive commit OK, Yes, Continue, or Confirm. | Asking users to confirm every routine action until they stop reading. | Using type text for passwords. |