ワンクッション必要な操作
取り消しができない・影響範囲が大きい操作を実行する前に、ユーザーに意図確認の機会を与えるパターン。誤操作によるデータ損失を防ぐ。
基本的な考え方
すべての操作にワンクッションを入れる必要はない。2 段階で判断する。
判断フロー
- リスク判定: 操作が取り消せないか、影響範囲が広いか、データ損失を伴うかを確認する。 いずれも当てはまらなければワンクッション不要。
- 対話の方法を選ぶ: リスクがある場合、確認ダイアログ・説明挿入・視覚的優先度低下のいずれかを選ぶ。
対象となる操作の種類
以下のケースではワンクッションを検討する。
- データ削除: 顧客情報・会話履歴・メモなど取り消せない削除
- 設定リセット: テナント設定・通知設定などの初期化
- ステータス変更（復元困難）: 完了済みに変更するなど後戻りが難しい状態変更
- 一括情報更新: 複数件の顧客情報を一括で書き換える
- 情報配付: SMS・メールの一括送信（受信者への影響が即時）
- オブジェクト公開: テンプレートや設定を他のユーザーが参照できる状態にする
- プロセス開始: 一度始めると途中停止が困難な処理の開始
- ダウンロード: 個人情報を含む大量データのエクスポート
パターン 1：確認ダイアログ
最も一般的なワンクッション。操作対象と実行結果をダイアログで提示し、明示的な同意を得る。
- 対象件数と操作内容を必ずダイアログ内に表示する（例：「50 件の顧客に SMS を送信します」）
- 実行ボタンはアクションの内容を示す動詞（「送信する」「削除する」）を使い、「OK」「はい」は使わない
- 削除操作は AlertDialog コンポーネントを使い Esc・オーバーレイクリックで閉じないようにする（AlertDialog の削除操作ルール参照）
- 削除以外の確認は通常の Dialog でよい
パターン 2：説明挿入
一括更新など処理が複雑で「何が起きるか」を事前に伝える必要がある場合、ページ内または Dialog 内に手順と影響を説明する。
- 操作前に「この操作を実行すると〇〇が更新されます。元に戻せません」のように影響範囲を明示する
- 説明が長くなる場合はページ遷移（確認画面）を採用する
- 顧客情報登録画面の「登録確認」→ 内容確認ページ → 登録実行 のフローが典型例
パターン 3：視覚的優先度低下
危険な操作ボタンを目立たなくすることで、意図せずクリックしにくくする。ダイアログを出すほどではない操作に使う。
- レイアウトで距離を置く: 主要操作ボタンと破壊的操作ボタンを離して配置する。同じ行に並べない。
- Ghost ボタンを使う: 破壊的操作に
variant="ghost"を使い、視覚的な重みを下げる。 - 一覧操作列には置かない: テーブルの各行操作列に削除ボタンを直接置くと誤クリックのリスクが高い。行内削除は確認ダイアログとセットにするか、詳細画面に移してから実行させる。