原則の運用

ここまで設計方針を紹介してきました。しかし、すべての状況でこれらが最適とは限りません。

例外を知ることで、原則の適用範囲が明確になります。

原則同士の関係

設計方針は独立しているわけではなく、互いに関係しています。

原則同士の関係

上位から下位へ

順序	原則	取り組みやすさ
1	画面名は「何を見ているか」で名付ける	命名の見直しから始められる
2	見たいものを先に見せる	入口の統合から始められる
3	登録・編集はその場で行う	UI変更で対応可能
4	確認画面は最低限にする	Undo機能の追加が必要
5	モードレスを優先する	UI設計の見直しが必要
6	状態と操作を分離する	DB・API設計の見直しが必要
7	ステップではなく不足条件で示す	DB・UI両方の見直しが必要

上位の原則から順に取り組むと、自然と下位の原則も適用しやすくなります。逆に、下位の原則だけを適用しようとすると、上位の問題が残ったままになりやすいです。

段階的に移行する

既存システムを改善する場合、一度に目標状態へ移行する必要はありません。小さく、安全に、段階的に進めることで、リスクを抑えながら改善できます。

例：確認画面からUndoへの移行

確認画面を一気に削除せず、段階的な移行が可能です。

段階	状態	リスク
1	確認画面は残したまま、Undo機能を追加	低（既存機能に影響なし）
2	一部ユーザーに確認画面スキップを提供（オプトイン）	低（選択制）
3	確認画面スキップをデフォルトに（オプトアウト）	中（ユーザー観察が必要）
4	確認画面を削除（または非表示に）	低（段階3で検証済み）

なぜ段階的に進めるか

各段階で学べる: ユーザーの反応を見て、次の段階に進むか判断できる
戻せる: 問題があれば前の段階に戻せる
リスクが小さい: 一度に大きく変えると、何が問題か分からなくなる

「目標状態」と「現状」のギャップが大きいほど、中間状態を設計する価値があります。

例外ケース

確認画面が必要な場合

以下のような場合は、確認画面を残す方が適切なこともあります。ただし、まず代替案を検討してください。

外部システムへの課金が発生する操作
- 決済処理、外部API呼び出しなど
- 取り消しが技術的に困難
法的な同意が必要な操作
- 利用規約への同意
- 個人情報の取り扱いに関する確認
取り消しが不可能な操作
- 外部への通知送信
- 物理的なプロセスの開始（印刷、発送など）

これらの場合でも、確認画面ではなく確認モーダルで済むことが多いです。画面を増やす前に、より軽量な手段を検討してください。

ステップフォームが有効な場合

以下のような場合は、ステップ形式が適していることもあります。ただし、セクション分割+不足表示で代替できないか先に検討してください。

初回ユーザーのオンボーディング
- 順を追って説明が必要
- 一度に多くの情報を見せると混乱する
入力に依存関係がある場合
- 前の選択によって後の選択肢が変わる
- 例：国を選ぶと都市の選択肢が変わる
規制要件で順序が定められている場合
- 法律や業界ルールで手順が決まっている

編集画面を分離した方がよい場合

以下のような場合は、編集専用の画面を設ける方が適切なこともあります。ただし、モーダルやサイドパネルで代替できないか先に検討してください。

編集が複雑で、専用のUIが必要な場合
- リッチテキストエディタ
- 画像編集、ドラッグ&ドロップ操作
編集中に他のデータを参照する必要がある場合
- 複数のデータを見比べながら編集
- 別ウィンドウや別タブでの作業が前提

モーダルが適している場合

以下のような場合は、モーダルの方が適切なこともあります。ただし、インライン表示で代替できないか先に検討してください。

短い確認や入力で済む場合
- 削除確認
- 名前の変更など、1〜2項目の入力
コンテキストを保持したい場合
- 背景を見ながら判断したい
- ただし、長いフォームには向かない

判断の目安

例外に該当するかどうかの判断に迷ったら、以下を考えてみてください。

問い	Yes なら
取り消しが技術的に困難か？	確認画面を検討
法的・規制上の要件があるか？	要件に従う
ユーザーが初めて使う機能か？	ステップ形式を検討
入力が複雑で専用UIが必要か？	編集画面を分離

ただし、これらに該当しても、より良い代替案がないか一度は検討してみる価値があります。

いつ取り組むか

原則を適用するかどうかは、コストと効果のバランスで判断します。

改善コストと放置コスト

	説明
改善コスト	設計変更にかかる工数、テスト、リリース作業
放置コスト	現状のまま続けることで積み重なるコスト

放置コストは見えにくいですが、以下のように積み重なります：

放置コスト = 1回あたりの無駄な時間 × 操作頻度 × ユーザー数 × 期間

例：確認画面の放置コスト

確認画面の通過に 10秒 かかる
この操作は 1日50回 行われる
1年続けると: 10秒 × 50回 × 250日 = 約35時間/年

この35時間と、確認画面を削除する工数を比較して判断します。

取り組むタイミング

タイミング	理由
バグ修正のついでに	すでにその画面を触っているので、追加コストが小さい
機能追加のついでに	新機能と一緒に改善すると、テスト範囲をまとめられる
頻繁に使われる画面	放置コストが大きいので、改善の効果も大きい
問い合わせが多い画面	ユーザーの困りごとが明確なので、効果を示しやすい

取り組まない判断も正しい

改善コストが放置コストを上回るなら、今はやらないという判断も正しいです。

ただし、その判断は記録しておくと良いでしょう。状況が変われば（利用頻度が上がる、ついでに触る機会ができる）、判断も変わります。

補足

原則は「常にこうすべき」というルールではありません。

状況に応じて判断するための指針であり、例外があることを前提としています。

重要なのは、なぜその設計を選んだのかを説明できることです。「なんとなく確認画面を入れた」ではなく、「課金処理があるから確認画面を入れた」と言えるかどうかが大切です。