例外と関係
ここまで設計方針を紹介してきました。しかし、すべての状況でこれらが最適とは限りません。
例外を知ることで、原則の適用範囲が明確になります。
原則同士の関係
Section titled “原則同士の関係”設計方針は独立しているわけではなく、互いに関係しています。
上から順に取り組むと、自然と下の原則も適用しやすくなります。逆に、下の原則だけを適用しようとすると、上の問題が残ったままになりやすいです。
確認画面が必要な場合
Section titled “確認画面が必要な場合”以下のような場合は、確認画面を残す方が適切なこともあります。ただし、まず代替案を検討してください。
-
外部システムへの課金が発生する操作
- 決済処理、外部API呼び出しなど
- 取り消しが技術的に困難
-
法的な同意が必要な操作
- 利用規約への同意
- 個人情報の取り扱いに関する確認
-
取り消しが不可能な操作
- 外部への通知送信
- 物理的なプロセスの開始（印刷、発送など）
これらの場合でも、確認画面ではなく確認モーダルで済むことが多いです。画面を増やす前に、より軽量な手段を検討してください。
ステップフォームが有効な場合
Section titled “ステップフォームが有効な場合”以下のような場合は、ステップ形式が適していることもあります。ただし、セクション分割+不足表示で代替できないか先に検討してください。
-
初回ユーザーのオンボーディング
- 順を追って説明が必要
- 一度に多くの情報を見せると混乱する
-
入力に依存関係がある場合
- 前の選択によって後の選択肢が変わる
- 例：国を選ぶと都市の選択肢が変わる
-
規制要件で順序が定められている場合
- 法律や業界ルールで手順が決まっている
編集画面を分離した方がよい場合
Section titled “編集画面を分離した方がよい場合”以下のような場合は、編集専用の画面を設ける方が適切なこともあります。ただし、モーダルやサイドパネルで代替できないか先に検討してください。
-
編集が複雑で、専用のUIが必要な場合
- リッチテキストエディタ
- 画像編集、ドラッグ&ドロップ操作
-
編集中に他のデータを参照する必要がある場合
- 複数のデータを見比べながら編集
- 別ウィンドウや別タブでの作業が前提
モーダルが適している場合
Section titled “モーダルが適している場合”以下のような場合は、モーダルの方が適切なこともあります。ただし、インライン表示で代替できないか先に検討してください。
-
短い確認や入力で済む場合
- 削除確認
- 名前の変更など、1〜2項目の入力
-
コンテキストを保持したい場合
- 背景を見ながら判断したい
- ただし、長いフォームには向かない
例外に該当するかどうかの判断に迷ったら、以下を考えてみてください。
| 問い | Yes なら |
|---|---|
| 取り消しが技術的に困難か？ | 確認画面を検討 |
| 法的・規制上の要件があるか？ | 要件に従う |
| ユーザーが初めて使う機能か？ | ステップ形式を検討 |
| 入力が複雑で専用UIが必要か？ | 編集画面を分離 |
ただし、これらに該当しても、より良い代替案がないか一度は検討してみる価値があります。
原則は「常にこうすべき」というルールではありません。
状況に応じて判断するための指針であり、例外があることを前提としています。
重要なのは、なぜその設計を選んだのかを説明できることです。「なんとなく確認画面を入れた」ではなく、「課金処理があるから確認画面を入れた」と言えるかどうかが大切です。