SSaaS GuideGuidelines

確認與破壞性操作

刪除東西到底該不該跳確認框？這章用「後端能不能復原」當判準：可復原就直接做 + Undo toast，不可復原才彈 modal，高風險再加 type-to-confirm。重點是避免「confirmation 疲勞」——能 Undo 的事就別一直問。當你在設計刪除、封存、取消訂閱這類動作時，翻這頁定案。

決策樹：什麼時候要 double check

這是什麼

依動作風險決定要不要多問一次：日常操作直接做；可復原的刪除用「復原」提示；無法復原才用確認彈窗；最高風險要輸入名稱才放行。

什麼時候用

設計刪除、封存、批次操作時先對照這張表，避免每個按鈕都跳確認，也避免該問卻沒問。

預覽依本指南規則實作
動作類型怎麼處理
標記已讀、改 status直接執行 + toast
可復原刪除 / 封存直接執行 + Undo toast（10 秒）
不可復原刪除（少量）Confirmation modal
刪 workspace / productionModal + type-to-confirm
Bulk destructiveModal +「影響 N 筆」
動作類型怎麼處理
Routine action直接執行 + toast
可復原刪除Undo toast 10 秒
不可復原刪除Confirmation modal
高風險Modal + type-to-confirm
Bulk destructiveModal + 影響 N 筆

Undo toast 比事前 confirmation 更友善，能避免 confirmation 疲勞。

Confirmation Modal 結構

這是什麼

標題寫動作、內文寫後果；「取消」與「刪除」按鈕外觀要明顯區分；預設焦點在「取消」。

什麼時候用

任何不可復原的確認彈窗都應遵守，降低誤刪；刪除按鈕用紅色並寫具體動詞（例如「刪除專案」）。

預覽依本指南規則實作
  • Title：問句或明確動作（Delete project?），不用 Are you sure?。
  • Body：重述後果 + 不可逆。
  • Primary：具體動詞 + 受詞（Delete project），不用 Confirm / OK。
  • Default focus 在 Cancel；ESC = Cancel；destructive primary 用紅色 + icon。

Type-to-Confirm

這是什麼

最高風險操作（例如刪除整個工作區）要使用者輸入資源名稱，名稱正確後刪除按鈕才會啟用。

什麼時候用

影響整個團隊或正式環境時才用；一般單筆刪除用確認彈窗即可，不必每次都打字。

預覽依本指南規則實作

刪除工作區？

將永久刪除「Acme」工作區及其所有專案、檔案與成員。此動作無法復原。

規格速查

動作類型怎麼處理
Routine（改狀態）直接執行 + toast
可復原的刪除直接執行 + Undo toast（10 秒）
不可復原的刪除Confirmation modal
高風險Confirmation modal + type-to-confirm
Bulk destructiveConfirmation modal + 明寫「影響 N 筆」

可復原 = 後端 soft delete／trash（可即時 Undo，或保留 30 天可還原）。Confirmation modal 須重述後果、default focus 落在 Cancel、primary 用紅色 + trash icon。

常見做錯

做錯正確
可復原刪除也彈 modal可復原改用 Undo toast，避免 confirmation 疲勞
title 只寫「Are you sure」title 寫明確動作，如「Delete project?」
primary 只寫「Confirm」primary 用動作 + 受詞，如「Delete project」
default focus 落在 Deletedefault focus 落在 Cancel（安全鍵）
高風險動作沒有 type-to-confirm刪 workspace／production 等高風險須輸入名稱才解鎖

相關章節

  • 回饋 — Undo toast 的時長與樣式
  • Modal 與覆層 — confirmation modal 的結構與關閉行為
  • 按鈕 — destructive 按鈕的紅色、icon 與文案
  • 批次操作 — bulk destructive 的確認與「影響 N 筆」