誤操作を防ぐ (Error Prevention)

「電話番号の形式が正しくありません」「パスワードは8文字以上で入力してください」——フォームを送信してから初めてエラーを知らされる体験は、誰もが経験したことがあるはずです。入力し直して再送信。また別のエラー。これを繰り返すうち、ユーザーは離脱します。

よくある失敗は「エラーメッセージを丁寧にすれば解決する」という思い込みです。しかしニールセンは言います——「優れたエラーメッセージも重要だが、そもそもエラーが発生しないように設計することの方がはるかに優れている」と。エラーメッセージはエラーが起きた後の対処。誤操作を防ぐ原則は、エラーが起きる前の設計です。

「削除」ボタンが「保存」ボタンの隣にある。過去の日付を選べるカレンダー。全角でしか入力できない電話番号欄——これらはすべて、UIの設計がユーザーをエラーに誘導しています。ユーザーのせいではなく、設計のせいです。

1. 原則の定義

誤操作を防ぐ（Error Prevention）とは、ユーザーがエラーを起こしにくい環境を設計によって作り出す原則。制約・デフォルト値・インラインバリデーション・視覚的分離などを活用し、「間違えようのないUI」を目指す。

本質は「ユーザーを信頼しないのではなく、ユーザーが間違えやすい状況を設計で取り除くこと」です。ヤコブ・ニールセンのユーザビリティ10原則の第5原則。エラーには「うっかりミス（スリップ）」と「知識不足による勘違い（ミステイク）」の2種類があり、それぞれ異なる設計対策が必要です。

2. いつ使うか（適用場面）

特に重要になるケース

• フォーム入力: 電話番号・メールアドレス・日付など、形式が決まっている入力欄では、入力前・入力中にガイドを提供する。
• 破壊的操作: データ削除・アカウント解約・決済確定など、取り返しのつかない操作の前には必ず確認または制約を設ける。
• 複雑な設定画面: 管理者権限・公開設定など、誤操作の影響が大きい操作には視覚的な警告と制約を組み合わせる。
• 新規ユーザーが多い場面: 操作に不慣れなユーザーほどエラーを起こしやすい。オンボーディング時は特に誤操作防止を意識する。

トレードオフが起きる場面

• 制約と自由度の兼ね合い: 制約が強すぎると、正しい操作もできなくなる（例：電話番号欄でハイフンを入力できない）。柔軟な入力を許容しながらバリデーションで対応する方が良い場合もある。
• 確認ダイアログの乱用: すべての操作に確認を求めると「確認疲れ」が起き、ユーザーは内容を読まずにOKを押すようになる。本当に重要な操作にのみ使う。

3. なぜ重要か（設計判断の核）

誤操作を防ぐ設計は「ユーザーを制限する」のではなく、「ユーザーが正しく操作できる環境を作る」ことである。

設計判断の基準

• 「このUI要素で、ユーザーはどんな間違いを犯しやすいか？」→ 想定されるミスをリストアップし、それぞれに対策を設計する。
• 「エラーメッセージを書く前に、そのエラーを発生させない方法はないか？」→ まず制約・デフォルト・ガイドで防ぐことを考える。

優先順位の考え方

• 1. 制約（最優先）: そもそも間違った操作ができないようにする（例：過去の日付を選択不可にする、数字以外を入力不可にする）。
• 2. デフォルト値: 最も一般的な・安全な選択肢をデフォルトにする。ユーザーの判断回数を減らす。
• 3. インラインバリデーション: 送信前にリアルタイムでフィードバックを提供する。エラーを送信後ではなく入力中に知らせる。

例外条件

• Undoが完全に機能している場合、確認ダイアログは省略できる（Undoの方がフローを妨げない）。

4. 具体の設計ルール（チェックリスト）

最低ライン（Must - これ守らないと危険）

これがないと、ユーザーはエラーに気づかないまま操作を進めます。

破壊的操作に確認または制約があるか: 削除・解約・決済など取り消せない操作の前に、確認ダイアログまたは「リポジトリ名を入力してください」のような制約があるか？
フォームのエラーが送信前に分かるか: バリデーションは送信後ではなく、入力中または入力欄からフォーカスが外れた時点でフィードバックされるか（インラインバリデーション）？
破壊的ボタンと主要ボタンが視覚的・物理的に分離されているか: 「削除」と「保存」が隣り合っていないか？色・スタイル・位置で明確に区別されているか？

理想ライン（Better - できると強い/プロの品質）

「間違えようのないUI」の状態です。

入力形式の制約または自動補正があるか: 電話番号欄では数字のみ受け付ける、または全角→半角を自動変換するなど、ユーザーの入力ミスを吸収する設計があるか？
デフォルト値が安全側に設定されているか: 公開設定は「非公開」がデフォルト、削除は「ゴミ箱」経由など、誤操作時の被害が最小になるデフォルトになっているか？
入力補助（サジェスト・オートコンプリート）があるか: メールアドレス・住所・検索ワードなど、タイプミスが起きやすい入力欄に候補を提示しているか？

5. UI例

フォームのバリデーション設計で、エラーの発生タイミングが大きく変わります。

改善プロセス

1. エラー発生箇所の棚卸し: サービスのエラーログやサポート問い合わせを分析し、ユーザーが最も多く犯すミスをリストアップする。
2. 制約→デフォルト→バリデーションの順で対策: まず「そもそも間違えられないか」を検討し、次に「安全なデフォルト」、最後に「リアルタイムフィードバック」の順で設計する。
3. 破壊的操作の分離: 削除・解約などの破壊的操作は、主要CTAから物理的・視覚的に分離し、必要に応じて入力制約を設ける。

6. 関連リンク

• 関連リファレンス（理論）: 防衛的デザイン, 防衛的デザインとエラー回避
• 用語集（定義）: エラー防止, 防衛的デザイン, 確認ダイアログ, 意図的な摩擦
• 関連するUI原則（横）: エラーから回復できる (Error Recovery), ユーザーコントロール (User Control), フィードバック (Feedback)
• 関連するUIコンポーネント: Dialog（ダイアログ / モーダル）, AlertDialog（警告ダイアログ）, File Upload（ファイルアップロード）

7. まとめ

今日から直せる一手 担当しているフォームを1つ選んで、「送信ボタンを押した後にしか分からないエラー」を「入力中に分かるエラー」に変えてください。onBlurイベントでバリデーションを実行するだけで、ユーザーの送信失敗率は大きく下がります。

チームに共有するなら一言 「エラーメッセージを改善する前に、そのエラーを発生させないUIを作れ。」