Skip to content
SkillCodex
Menu

UI recipe · Version 1.0.0 · 5 min read

Confirm a risky action

Connect consequence, explicit confirmation, cancellation and a verifiable outcome before deleting a workspace.

Direct answer

Use a confirmation only when the consequence warrants an interruption. Explain what will be lost before asking for a decision, preserve a safe exit, and separate a local acknowledgement from a verified server result.

Sources and revision
Updated
Revision
2026-09-16 · 473f4819df96
Sources
2 sources
Status
Published
Read the sources

Connect and try

Version 1.0.0

  • Alert dialog

    Interrupt a consequential action and ask for an explicit decision.

  • Inline alert

    Keep the consequence or failure visible beside the action.

  • Toast

    Optionally acknowledge a confirmed outcome; never use a brief notification as the only error explanation.

What this recipe does not cover

Local simulation only: no workspace is deleted. This example has no undo; restarting the demo is not recovery. It demonstrates cancellation, pending and success, but not a server failure. Permissions, persistence, duplicate prevention and screen-reader testing remain to be implemented and verified in your product.

Instruction to adapt

Fixed editorial text, separate from Packs. Read the limits above before using it; execution is not guaranteed.

Build a confirmation flow for permanently deleting a workspace. Before confirmation, name the workspace, the affected projects, members and files, and the irreversible consequence. Use an Alert dialog with initial focus on Keep it. Cancellation preserves the workspace and returns focus to the trigger. Disable duplicate actions while pending. Announce success only after the server confirms deletion, with a persistent result. On failure retain the context and explain the next step; reconcile an unknown outcome before retrying. Do not promise undo. Verify cancellation, pending, failure, success, keyboard focus and a 320 px viewport. The local demo does not prove server deletion or accessibility with a screen reader.

In this guide

01

1. Name the consequence

Specify the workspace and affected data. Choose confirmation proportional to the risk; a reversible, low-impact edit does not need the same interruption as permanent deletion.

02

2. Ask for an explicit decision

An Alert dialog focuses the decision. In the example, Keep it receives focus first; cancel and verify that the workspace remains intact. Compare with Modal dialog when the task is editing rather than confirming a consequence.

03

3. Wait, then report the outcome

Confirm and observe the pending text and disabled actions. The demo finishes locally. In a real product, an Inline alert keeps a failure and next step visible; an optional Toast can acknowledge success alongside a persistent result. A timeout is an unknown outcome, not proof of failure.

04

4. Check the boundary

Verify the result before offering another operation. This deletion has no recovery; never add an Undo promise without a working recovery contract. Empty state means the workspace is gone only after confirmed deletion, not merely because its card disappeared.

Keep this

What to verify

  1. 01Cancel: no deletion, focus returns to the trigger.
  2. 02Confirm: pending blocks duplicates, then a readable result appears.
  3. 03Production integration: verify rights, actual deletion, failure and unknown outcomes separately.

Primary sources

Technical claims in this guide connect to first-party specifications and documentation.

Continue