| 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. | Use destructive action confirmation to create one informed stop before permanent or externally visible loss, not to slow every routine cleanup action. | Interrupt users only when the action has a meaningful consequence that cannot be safely recovered afterward. | 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 sign-in form has Email and Password fields, the password field uses autocomplete current-password, a Show button, no spellcheck, and an account-details error after failed login. |
| Bad UI | A dialog asks users to type YES before deleting a workspace, so the text does not verify the target object. | A modal says Are you sure? with OK and Cancel after the user clicks Delete, without naming the project or what disappears. | A popup says Are you sure? with OK and Cancel but does not name the project, notes, or irreversible outcome. | 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. | A user pastes a generated password from a password manager, toggles Show to inspect one character, hides it again, and signs in without the value appearing later in review or history. |
| Bad UX | A user types DELETE by habit and passes the gate without checking which workspace will be removed. | 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 user cannot paste from a password manager and shortens the password to something easier to type. |
| 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 value is not a secret, such as a name, email address, account number, search query, reference, or ordinary note. |
| Required state | No-typed-gate state for actions that do not need target-text escalation. | Idle state where the destructive command is visible but not committed. | 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. | Using a vague Are you sure prompt that does not name the object, count, or consequence. | Asking users to confirm every routine action until they stop reading. | Using type text for passwords. |