How To Manage Dangerous Actions In User Interfaces — Smashing Magazine

Why Certain Actions Demand Extra Safeguards

Murphy’s Law applies no less to digital products than it does to the rest of life: anything that can go wrong eventually will. Since an interface is the communication layer between the user and a system, every interaction carries the risk of triggering an outcome the user did not intend. Some outcomes are merely inconvenient; others are critical or practically irreversible. The usability heuristic known as “Error Prevention” states it plainly:

“Good error messages are important, but the best designs carefully prevent problems from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.”

The challenge is deciding which actions qualify as dangerous enough to warrant extra protection — and that decision is not always as obvious as it seems.

Defining “Dangerous” in Interface Terms

It is a common assumption that a dangerous action must involve deleting data. In practice, the definition is broader and more context-dependent. A single tap can commit a user to a legally binding agreement or move real money, without any deletion involved whatsoever.

For instance, in a banking application, a lender may approve a loan, and the user can accept it with one tap on a button labeled “Get Money.” Clicking that button signs the necessary documents and actively draws the loan. An accidental tap there means the user has taken on a loan they never asked for — categorically a significant and dangerous action even though no destructive operation occurs.

Dangerous actions, then, are better defined by their consequences than by their mechanics. Common examples include:

• Sending an email
• Placing an order
• Publishing a post
• Making a bank transaction
• Signing a legal document
• Permanently blocking a user
• Granting or revoking permissions

Confirmation Dialogs Done Right

Modal dialogs remain one of the most common ways to protect users from irreversible actions — but only when implemented thoughtfully. The key factor is modality: a modal dialog prevents interaction with the parent view until dismissed, forcing an explicit response. Non-modal elements like toast messages don't interrupt the workflow and are better suited for less critical feedback.

Modal confirmations work best when the consequences are serious and potentially irreversible — deleting a project, authorizing a payment, or sending a message that can't be recalled. The danger is overuse. When modals appear for routine actions, users develop a habit of clicking through them on autopilot, defeating their purpose entirely.

Writing Confirmation Dialogs That Actually Work

A well-designed confirmation dialog leaves no room for ambiguity. Generic phrasing like "Are you sure?" gives users nothing to pause over. Instead, follow these practices:

• State the exact action in the title. Name the entity that will be affected — the project, user, or amount.
• Include a warning icon. This not only signals danger but also helps users with color blindness who might otherwise miss a red-only indicator.
• Be specific in the description. Highlight the critical information users need to evaluate the consequence.
• Use action-reflecting CTA labels. "Delete," "Pay $97," or "Send Message" are far more informative than a bare "Confirm."

When Typing Becomes the Guardrail

For especially destructive actions, asking users to type a specific word or phrase adds a meaningful layer of friction. This is usually paired with a disabled submit button that only becomes active after the correct input. ConvertKit, for example, requires entering "DO IT" before removing subscribers — and notably places the buttons on the left, closer to the form, following the law of proximity. Resend takes the same approach for API key deletion, asking users to type "DELETE."

Resend's modal demonstrates best practice well:

• The title names the action: "Delete API Key."
• The specific key name appears in bold, colored text within the description.
• A red label states the action cannot be undone.
• Typing "DELETE" is required before the CTA becomes available.
• The button itself is labeled "Delete API Key" — not a generic "Confirm."

While disabled buttons are generally discouraged, this is a case where they're acceptable — the request is clearly stated and the requirement is unambiguous. For simpler extra-effort cases, like entering a 4-6 digit OTP or 2FA code, you can even skip the submit button entirely. The form auto-submits once all digits are entered. It's a reasonable trade-off: the flow is streamlined, and in the rare case of a typo, users can quickly re-enter the digits. This approach is commonly seen in banking apps that omit the login button entirely.

Danger Zones and Inline Confirmation

The Dedicated Danger Zone

For the most critical actions — account deletion, data wiping, permission changes — a visually separated "danger zone" is a common pattern. These zones typically sit at the bottom of a settings page or on a dedicated page when there are multiple high-risk actions to group.

Effective danger zones follow a few principles:

• Use visual differentiation. Red borders, warning icons, or background colors separate these actions from the rest of the interface.
• Describe the consequences. Each action needs its own clear explanation of what will happen if the user proceeds.
• Require extra effort. Since these actions are often irreversible, asking for a password re-entry or 2FA adds protection against unauthorized access.
• Keep the list short. Only truly critical actions belong here — don't create a danger zone for the sake of having one.

The Two-Step Inline Guard

Apps like Zapier and Typefully have popularized an inline confirmation pattern: click a dangerous action once, and the button label changes to ask for a second click. This sparked considerable debate within the design community, largely because of the risk that a user could execute the action accidentally with a double-click.

That concern is worth addressing, but several factors make the pattern viable:

• It's meant for accidental clicks, not for alerting users to serious consequences — those warrant a more substantial confirmation.
• Pairing it with an undo option or an archive for deleted items provides a safety net.
• A small delay of 100–200ms before the button changes can help prevent double-click misfires.

Jakob's Law says users prefer interfaces to work like the other sites they already know. But that doesn't mean new patterns can't be introduced — if the web never evolved past familiar conventions, we'd still be using skeuomorphic designs. Context matters too. A user base that tends to click rapidly and repeatedly may not be suited for this pattern, but for apps like Zapier and Typefully, the trade-off appears to work.

Beyond the Dialog: 2FA, Passkeys, and Approvals

Two-Factor Confirmation

Some actions are sensitive enough to warrant verifying the user's identity through a second channel — SMS, email, an authenticator app, push notification, or messenger. This is a confirmation step, distinct from the login process itself. Crypto exchanges commonly require this: you submit a transfer request on the website, then must approve it via email or another device.

This method suits money transfers, ownership changes, and account deletion, and is frequently layered after a dialog confirmation. The methods described here are rarely used in isolation — they combine into a defense-in-depth approach that protects across the entire business process.

Passkeys as a Better Alternative

Passkeys offer a password-less authentication approach that's increasingly supported across devices. The user's secret is stored on their device and unlocked with biometrics — a fingerprint, facial recognition, or a device PIN.

Compared to 2FA, passkeys have several advantages:

• No device switching. There's no waiting for a code — authentication is immediate and happens on the same device.
• Phishing resistance. No secret code travels over the network. Public-private key cryptography makes passkeys immune to SMS interception and similar attacks.
• Less cognitive load. No passwords to remember or codes to type.
• Near-instant confirmation. Users don't have to open an email inbox or copy a code from another device.

Two-Person Approval Workflows

Some decisions are too consequential for a single person to make. In these cases, one user initiates an action while a second — an approver — must confirm it. The UI can still use confirmation dialogs at each step, but the real safeguard is the separation of responsibilities.

This pattern is familiar across many contexts:

• GitHub and similar code platforms: pull request review before merging.
• Workflow tools like Jira: moving issues through stages may require manager approval.
• Banking: high-value transactions sometimes need verification for legal reasons.
• Platforms like Deel: a contract is drafted by one party and accepted by another.

In medicine, the Council of Physicians embodies the same logic — seeking collective, diverse perspectives leads to better decisions. From a UI perspective, this method isn't a distinct widget or interaction pattern so much as an approach to business logic. The approval action itself remains dangerous; it's just now someone else's responsibility to confirm it.

Confirmation Modals Fight Human Nature

The uncomfortable truth about destructive-action confirmations is that users often click through them without real thought. Psychological research offers several explanations for this behavior:

• Cognitive inertia: People stick with familiar decisions even when inappropriate. Most users accept lengthy user agreements without reading them because doing so is legally necessary and routinized.
• Availability heuristic: When users see recurring popups, they base decisions on past successful interactions with similar prompts rather than evaluating the current situation.
• Cognitive miser: The human mind defaults to the simplest, least effortful solution. Clicking “yes” or “agree” requires far less effort than parsing the text in front of you.
• Banner blindness: While not directly about confirmations, this phenomenon illustrates the same underlying human tendency to ignore repetitive visual information.

Gentle Alternatives to Confirmation

Since we cannot fully control how users engage with our prompts, we can influence their behavior through smarter interaction design. Two particularly effective patterns stand out.

Delaying the Action

Instead of asking for confirmation, some interfaces artificially delay execution in a graceful manner. The food delivery app Glovo provides an instructive example. When you place an order, you pass through a sequence of screens: first a cart with items, then a screen confirming the order. What makes the second screen clever is that the order details fade in gradually while a progress bar advances at the bottom. That progress bar is not tracking a real process — it is a visual technique to occupy users for a few seconds while they naturally review their order one final time.

Only after this interlude does the app move to the actual payment, showing a real processing state and then the order status. Highlighting that the order preparation has begun exploits the Goal-Gradient Effect: seeing a process in motion reassures users that their transaction completed successfully. The earlier version of the app prevented users from skipping this review step. The newer version added a “Continue” button that effectively acts as a “Yes, I’m sure” confirmation. This reintroduces the possibility of blind skipping, but the design still achieves its purpose better than a classic modal. Users at least sometimes pay attention to the address and price during that delay window, and the Cancel option remains available rather than the binary yes/no that encourages immediate confirmation.

The Undo Option

Undo offers a different approach: let users complete the action, then provide a straightforward way to reverse it. As a safety net, this pattern reduces the anxiety around making mistakes and avoids interrupting the workflow with confirmation demands.

When to use it: Undo fits non-destructive, reversible actions without significant immediate consequences:

• Editing a document (ctrl + z).
• Deleting a file that lands first in a trash or recycle bin.
• Marking a task complete or incomplete.
• Removing a message from a chat conversation.
• Applying filters to a photo.

Combined with a timer, you expand the range of undoable actions to include tasks like sending an email or authorizing a payment.

When you cannot use it: Irreversible or high-stakes actions demand other patterns:

• Deleting an account.
• Submitting legal documents.
• Purchasing goods — a refund is not the same as undoing a purchase.
• Mutating external state via a third-party API in most cases.

Implementation approaches:

1. Keyboard shortcuts: The familiar ctrl + z works well for text editors and generally when moving or editing local content.
2. Toast notifications: Web and mobile apps commonly surface an undo link in a temporary message. The toast must be visible enough — tucked away in a corner with muted colors, especially on wide screens, it will fail.
3. Inline button: Place an undo button near the control that triggered the action. This is the most straightforward pattern.

Soft Deleting as an Enabler

Undo relies on a backend concept called soft deleting, common in frameworks such as Laravel. The UI hides data from users as if it were deleted, but the underlying record remains in the database marked as deleted. Since nothing is actually removed, reversing the action is trivial.

Not every table requires this treatment. If a user deletes an account and you must comply with the legal obligation to erase data completely, you should perform a hard delete. But in most cases, soft deleting is a conservative and reversible choice. Worst case, you can manually restore user-visible data when no UI path exists to do so.

The Exception Is the Rule

No UX pattern reliably works in every context. Each interface experience differs based on the audience, the action in question, business constraints, and constant iteration informed by real user feedback. Local factors — country, age, culture, and familiarity with particular patterns — all influence whether a person reads carefully, clicks blindly, or seeks out the undo button.

The constant remains the same: stay in control of user data and be prepared when an action goes wrong. Adhere to industry best practices, but verify that they behave as expected in your specific case. Like chess, interface design has many rules and an even larger set of exceptions.