削除

システムの保持するデータに破壊的な処理を行うがゆえに、削除というアクションを前にしてユーザーは無意識的でもいくらかの緊張を強いられます。そうした重みのある動作が安全に確実に実行される実感を抱けるようにUIが適切にデザインされていることが、ユーザーがシステムを信頼して使えるために重要です。そのためには削除動作にまつわる外見および手順が、ユーザーの持つ概念モデルにマッチしているとともに、紛らわしくないかたちで一貫性を持っている必要があります。

削除ボタン

復帰困難で破壊的な処理を実行するという性質上、「削除」というアクションはユーザーによる明示的な指示を必要とします。したがって、多くの場合ボタンがその起点になります。操作ミスによる破壊を防ぐために、慣例的に「削除」の概念とマッチした外見を備え、その配置や視覚的なふるまいに一貫性を持つことで、まぎらわしさを避けます。

削除ボタンのスタイル

破壊的処理をともなうアクションとして、色は共通の警告色であるDangerを使用します。文言は「削除」、ゴミ箱のアイコン「」も慣用的です。リストや表組み内の各行につける場合にはよりシンプルな「」にします。

ボタンの種類は画面の中でのメインのアクションに該当するなら「ベーシック」で、サブ的なら「反転」に。他にメインのアクションのためのボタンが存在するなら「ホバー」「反転ホバー」とし、削除以外の他のボタンとの目立ち度合いのバランスも考慮して適切に調節することで、ユーザーが重要度や優先度を感じ取れるようにします。

削除ボタンの場所の例

削除ボタンは誤操作を防ぐために、メインのアクションやその他の高頻度で使用するボタンとは離し、並列に近接して配置しないように配慮します。

レコード詳細画面の削除ボタン

各レコード詳細の編集画面において、最下部左側にそのレコードを削除するボタンです。

各レコード詳細 編集のサンプル

表組でチェックしたものを一括削除

レコード検索結果の一覧で一括削除をする場合などに用います。

レコード検索のサンプル

リストから削除

ユーザーが表組に行を追加していく形でリスト編集できるパターンなどで用います。

ここでの削除ボタンは実際にデータベース上の情報に変更を及ぼすわけではなく、UIの表示上のリスト項目を削除し、ページ下部の[変更を保存]ボタンをクリックすることによってリストの内容を確定しデータベースの内容を書き換えることになります。そのため、この各行の[]ボタンをクリック時にいちいち後述の確認ダイアログを表示する必要はありません。

削除確認ダイアログ

うっかりデータを破壊してしまうことを防ぐために、削除ボタンクリックによるユーザーの意思表示のあとに本当に削除を実行して良いか確認のダイアログを表示します。

これは、後戻りができない動作の前にあえていったん動作をさえぎるものになります。安全とそれによる全体のユーザー体験のために重要ですが、あまり頻繁だとユーザーのストレスを招きます。上記のリスト編集のパターンのようにその時点では後戻りが可能な場合には削除確認ダイアログは不要です。

また、後戻りができないために実行の前に事前確認をしているわけですから、後戻りができるようにすることで確認ダイアログを省略するというアプローチもできます。並んだデータをより気軽に削除を繰り返していくような動作がマッチする場合には、削除確認ダイアログを表示せずに（表面上は）削除を実行することで動作を遮る煩わしさを回避する代わりに、後述する削除完了通知に時限的な[元に戻す]リンクを設けるというやりかたも有効です。

削除完了通知

削除を実行後、それが確かに完了したことをフィードバックするところまでが、削除の一連の動作になります。破壊的な処理が確実に実行され完了した感覚をきちんとユーザーが感じられるようにすることで、安心してシステムを使うことができます。

前述のように、削除確認ダイアログを省略するかわりに、削除完了通知に[元に戻す]リンクを設けることもできます。削除を取り消して元に戻すアクションを取るための時間的猶予を与えつつ、そのまま削除でよい場合にも長すぎないと感じられる時間だけ表示したあとに自動で消えるようにします。