削除確認のUX設計：取り消しと確認画面の使い分け

削除確認の目的は、操作を一度止めること自体ではありません。何が消え、元に戻せるのかを実行前に判断できるようにすることです。復元可能な個人用下書きなら、削除後に「元に戻す」を示すほうが作業を妨げません。一方、ほかのメンバーが使う共有プロジェクトには、対象と影響範囲を示す確認画面が必要です。ここでは架空のデザインチームを例に両方の導線を設計し、Pixsoのプロトタイピング機能で検証する方法まで見ていきます。

赤いボタンより先に、削除対象を特定する

この例では、Mayaが「Autumn launch」という名前の個人用下書きと、６つのデザインファイルを含む同名の共有プロジェクトを持っています。表示名が同じでも、削除の結果は違います。下書きは本人だけが使用し、復元可能なゴミ箱に移動します。共有プロジェクトは８人のチームメンバーが使用しており、削除すると通常のアクセス手段を失います。ダイアログを描く前に、対象、含まれるファイル、影響を受ける人を明確にします。

操作の仕様を「個人用下書きを30日間ゴミ箱へ移動する」「共有プロジェクトと６つのファイルを削除し、メンバーのアクセスをなくす」のように書き分けます。30日という期間はこの架空の例の設定であり、Pixsoの保持期間を示すものではありません。実際の製品に復元手段がないのなら、見慣れたUIだからという理由で「元に戻す」を置いてはいけません。

注意喚起と権限も別の問題です。警告は結果を伝えますが、削除権限を与えるわけではありません。ここでは所有者に実行権限があるものとし、その人が結果を理解して選べるかに焦点を当てます。

結果に応じて「元に戻す」、確認、事前レビューを選ぶ

大きな誤操作を防げる範囲で、できるだけ作業を遮らない方法を選びます。確実に取り消せる操作なら、実行後にわかりやすい取り消し手段を示せます。取り返しにくい操作なら、確定前に結果を示します。小さな操作にも毎回モーダルを出すと、内容を読まずに閉じる習慣を生みかねません。

プロジェクト名の入力を、すべての危険操作に求める必要はありません。復元できず、多くの人やファイルに影響するなら検討に値しますが、入力は機械的に済まされることもあります。まず対象と結果を正確に示し、最後のボタンに具体的な動詞を使います。追加の入力は、リスクと利用者テストで必要性が確かめられた場合に限ります。下書きの取り消しも、一瞬で消える通知だけに頼らない設計にします。

「何を、誰に、次にどうなるか」を文章にする

「本当によろしいですか？」では、判断材料を利用者自身が探さなければなりません。共有プロジェクトなら「共有プロジェクト『Autumn launch』を削除しますか？」と問い、「６つのデザインファイルが８人のメンバーから利用できなくなります」と続けます。一定期間復元できるなら、誰がどこで復元できるかを書きます。バックエンドに復元手段がない場合にだけ「完全に削除」と明記します。実行ボタンは「プロジェクトを削除」、キャンセル側は「プロジェクトを残す」と具体化します。

名前、所有者、対象ファイル数、メンバーへの影響を一緒に示します。件数は現在のデータを使い、ダイアログを開いている間に内容が変わったら更新します。古い件数を確定時に表示するくらいなら、件数を出さないほうがましです。ファイルが非常に多い場合は、長い一覧をモーダルに詰め込まず、件数と範囲を確認できる導線を用意します。

強い警告色は、最終操作と重要な結果に絞ります。安全側の選択肢も見つけやすく保ちます。色だけでは意味が伝わらないため、両方のボタンに動詞を入れます。

成功だけでなく、結果が不明な場合も設計する

削除ボタンを押したところでフローを終わらせません。下書きなら、ゴミ箱への移動を伝え、取り消し操作と後からゴミ箱を見つける経路を用意します。復元できたら元の場所に戻し、その結果を伝えます。その間に下書きが更新されていたら、新しい内容を黙って上書きせず、競合を説明します。

共有プロジェクトでは送信中の二重実行を防ぎます。成功したら所有者を適切な親画面に移し、通常のナビゲーションから対象を除きます。ほかのメンバーへの通知は、実際の製品仕様に合わせます。失敗したらプロジェクトと確認画面の文脈を保ち、再試行を判断できるようにします。通信タイムアウトは特に注意が必要です。応答がなくても削除だけ成功した可能性があります。もう一度危険な要求を送る前に、対象や要求の状態を確認します。

別のメンバーが開いたままのファイルをどう扱うかも決めます。閲覧専用にする、画面を閉じる、削除通知を出すなど、実装構成によって答えは異なります。実際のサービス仕様にないメール通知やローカルコピーの消去を約束しないようにします。

マウスなしでも判断できる確認画面にする

モーダルには見えるタイトル、読める結果の説明、到達できる操作、明確なフォーカス表示、戻り方が必要です。W3Cのモーダルダイアログの指針では、取り消しにくい最終操作の場合、最初のフォーカスを最も破壊的でない選択肢に置く例を挙げています。アラートダイアログの指針も、確認画面の名前とメッセージを適切に結び付ける方法を示しています。指針に沿った見た目の画像だけで、アクセシビリティが保証されるわけではありません。

Escapeキーと閉じるボタンは、削除を実行せず保留中の判断を取り消します。閉じた後のフォーカスは通常、起点のボタンに戻します。成功後にそのボタンが消えるなら、プロジェクト一覧の見出しなど、意味のある移動先を選びます。通信待ちの状態も伝え、反応のない画面に利用者を閉じ込めないようにします。

Pixsoで二つの導線を並べて検証する

Pixsoのキャンバス上に、個人用下書きと共有プロジェクトのフローを並べます。下書きは「削除」から「ゴミ箱へ移動」「元に戻す」「復元完了」へつなぎます。共有プロジェクトは「削除」から「対象範囲の確認」「送信中」「成功後の画面」「エラーからの復帰」へつなぎます。両方で同じ名前を使い、ファイル数と人数にも矛盾がないか確かめます。確認画面だけが整っていても、その次の状態が説明と違えば意味がありません。

レビュー担当者に「どちらのAutumn launchを削除するのか」「誰がアクセスを失うのか」「間違えた場合はどうできるのか」を答えてもらいます。推測が必要なら、対象名、結果、復元画面を修正します。開発者には、保持期間、権限、通知、要求状態の実際の仕様とともにフローを渡します。Pixsoは画面と操作の検討に役立ちますが、本番環境の削除処理やバックエンドの復元方針を実行・保証するものではありません。Pixsoで二つのフローを検討する。