「確認ダイアログを出しておけば安全」という発想は、業務システムで最も広く共有されている誤解のひとつです。すべての操作に確認を挟むと、利用者は内容を読まずにOKを押す習慣を身につけます。本当に危険な操作の確認まで読み飛ばされるようになります。
通知手段の選び分け
| 手段 | 使うべき場面 | 特徴 |
|---|---|---|
| トースト | 成功の通知(保存しました・12件を承認しました) | 数秒で自動消滅。操作を止めない |
| インライン | 項目単位のエラー、フォーム内の注意 | 該当箇所の直下に表示。文脈が明確 |
| バナー | 画面全体に関わる状態(締め処理中・権限不足・メンテ予告) | 画面上部に常駐。自動では消えない |
| モーダル | 続行の判断が必要/取り消せない操作の確認 | 操作を止める。乱発すると価値が下がる |
| 全画面 | 業務が続行不可能(システム障害・セッション切れ) | 最後の手段 |
「利用者の作業を止めてよいか?」で選びます。止める必要がないなら、モーダルは使いません。止めてよいのは、判断が必要なときと、取り消せないときだけです。
確認ダイアログを出す条件
出す:取り消せない、影響範囲が広い、外部へ影響が及ぶ
- 削除(物理削除)、締め処理、月次確定
- 10件以上の一括操作
- 取引先へのメール送信、外部システムへの連携実行
出さない:後から直せる操作
- 通常の登録・更新(完了後に編集できる)
- 下書き保存、検索条件のクリア
- 論理削除で、あとから復元できる削除
確認ダイアログの文言テンプレート
タイトル:何をするのかを疑問形で
「受注データを削除しますか?」
×「確認」「警告」などの汎用語だけは使わない。
本文:対象・影響・取り消し可否
「受注No.20260616-004(株式会社〇〇/125,000円)を削除します。この操作は取り消せません。」
ボタン:動詞で、危険な側を右に置かない
[キャンセル][削除する]。破壊的操作は赤系、既定フォーカスはキャンセル側に置きます。
確認
よろしいですか?
[はい][いいえ]
受注データを削除しますか?
受注No.20260616-004(株式会社〇〇)を削除します。この操作は取り消せません。
[キャンセル][削除する]
影響が特に大きい操作は入力確認を挟む
月次締めや大量削除など、取り返しのつかない操作では、対象名やキーワードを入力させる方式が有効です。ただし乱用すると単なる手間になるため、年に数回レベルの操作に限定してください。
モーダルの実装要件
モーダルは実装の落とし穴が多いUIです。次の要件は標準として明記しておきます。
- 開いたときにモーダル内へフォーカスを移す
- Tabキーのフォーカスがモーダル内で循環する(フォーカストラップ)
- Escキーで閉じられる(ただし入力中の破棄には警告を出す)
- 背景クリックで閉じるかは統一する。入力を伴うモーダルでは閉じない設定を推奨
- 閉じたあと、開く前のフォーカス位置に戻す
- 背景のスクロールを止める
- `role="dialog"` と `aria-modal="true"`、タイトルとの関連付けを行う
モーダルの中からさらにモーダルを開く多重構造。閉じる順序が分からなくなり、Escの挙動も破綻します。2階層目が必要になったら、画面遷移に切り替えるのが正解です。
トーストの設計
| 項目 | 標準 |
|---|---|
| 表示位置 | 画面上部中央、または右上に統一 |
| 表示時間 | 成功3〜4秒/警告6〜8秒/エラーは自動で消さない |
| 内容 | 結果を具体的に(「12件の受注を承認しました」) |
| 操作 | 可能なら「元に戻す」を添える |
| 同時表示 | 3件まで。それ以上は集約する |
エラーをトーストだけで通知するのは危険です。数秒で消える=見逃すということ。エラーは消えない場所(バナーまたは項目直下)に残してください。
ローディングと空状態
- 一覧の読み込み中は、行の形をしたスケルトンを表示すると体感が速い
- 読み込みが3秒を超える見込みなら、進捗または件数を表示する
- 空状態には「まだ登録がありません」+作成ボタン、を必ず添える
- 検索結果0件と初回未検索は区別して表示する
- 権限がなくて表示できない場合は、その旨と申請先を書く
チェックポイント
- 確認ダイアログが「取り消せない操作」に限定されている
- ダイアログ本文に対象・影響・取り消し可否が書かれている
- ボタンが「はい/いいえ」ではなく動詞になっている
- モーダルのフォーカス制御とEsc操作が実装されている
- エラーが自動で消える通知だけになっていない
- 空状態に次の行動が示されている