状態と例外を先に設計する (States & Edge Cases)

Figmaのモックアップは美しい。データが完璧に揃い、テキストはちょうどいい長さで、エラーは一切起きない——しかし現実のUIは違います。APIが遅延してローディングが続く。ユーザーが初めてアクセスしてデータが空。入力が長すぎてレイアウトが崩れる。ネットワークが切れてエラーが発生する。

よくある失敗パターンは「ハッピーパス（正常系）だけを設計する」ことです。デザイナーが「うまくいったとき」のUIだけを描き、エンジニアが実装時に初めて「ローディング中はどうする？」「エラーが出たらどう表示する？」「データが0件のときは？」と気づく——この後付けの状態設計が、UIの品質を下げる最大の原因です。

状態と例外を後回しにすると、実装後に必ず壊れます。ローディングスピナーが消えないまま画面が止まる。エラーメッセージが「undefined」と表示される。空のリストが真っ白なままで何も案内がない——これらはすべて、設計段階で状態を定義していなかった結果です。

1. 原則の定義

状態と例外を先に設計する（States & Edge Cases）とは、UIの「正常系（ハッピーパス）」だけでなく、ローディング・エラー・空状態・境界値（文字数上限・0件・大量データ）などすべての状態を設計段階で定義し、どの状態でもUIが意味のある体験を提供できるよう設計する原則。

本質は「UIは状態機械である」ということです。すべてのUIコンポーネントは複数の状態を持ちます。ボタンには「通常・ホバー・押下・無効・ローディング」がある。リストには「ローディング中・データあり・空・エラー」がある。これらの状態をすべて定義することが、完成したUIの設計です。

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

特に重要になるケース

• 非同期データを扱うUI: APIからデータを取得するリスト・ダッシュボード・検索結果。ローディング・成功・エラー・空の4状態を必ず設計する。
• フォーム・入力UI: バリデーション前・入力中・エラー・成功・送信中・送信完了の各状態を定義する。
• ユーザー生成コンテンツ: 投稿が0件・1件・大量件数・テキストが極端に長い/短いケースを設計する。
• 権限・認証が絡むUI: ログイン済み・未ログイン・権限なし・セッション切れの各状態を設計する。

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

• 設計コストの増大: すべての状態を設計すると、モックアップの枚数が数倍になる。重要度の低いエッジケースは「テキスト仕様」で済ませ、主要な状態のみビジュアル設計する。
• 過剰なエラーハンドリング: すべてのエラーに詳細なUIを用意すると、実装コストが膨らむ。エラーの重大度に応じて「フルページエラー」「インラインエラー」「トースト通知」を使い分ける。

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

UIは「うまくいったとき」だけ使われない。壊れたとき・空のとき・遅いとき——それらすべてが「体験」だ。

設計判断の基準

• 「このUIコンポーネントは何種類の状態を持つか？」→ すべての状態をリストアップし、それぞれのUIを定義する。
• 「データが0件のとき、このUIは何を表示するか？」→ 空状態のUIが未定義なら、設計が未完成。

優先順位の考え方

• 1. エラー状態（最優先）: ユーザーがタスクを完了できない状態。何が起きたか・どう回復するかを明示する。
• 2. ローディング状態: データ取得中の待機状態。スケルトンスクリーン・スピナーで「処理中」を伝える。
• 3. 空状態: データが0件の状態。「なぜ空か」「どうすれば追加できるか」を案内する。
• 4. 境界値: 文字数上限・大量データ・特殊文字など、通常範囲外の入力への対応。

例外条件

• 静的コンテンツ（マーケティングページ・ランディングページなど）は非同期データを持たないため、ローディング・エラー状態の設計は不要な場合がある。

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

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

これがないと、実装後に必ずUIが壊れた状態で公開されます。

非同期UIの4状態が定義されているか: データを取得するすべてのUIに「ローディング・成功・エラー・空」の4状態のデザインまたは仕様があるか？
エラー状態が「何が起きたか」と「どう回復するか」を伝えているか: 「エラーが発生しました」だけでなく、「再試行する」「ホームに戻る」などの回復アクションが提供されているか？
空状態が案内を提供しているか: データが0件のとき、真っ白な画面ではなく「まだデータがありません」「〇〇を追加してみましょう」などの案内があるか？

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

「動く」を超えて「どの状態でも良い体験」の状態です。

スケルトンスクリーンを使っているか: ローディング中にスピナーだけでなく、コンテンツの形を模したスケルトンUIを表示し、レイアウトシフトを防いでいるか？
境界値のテストをデザイン段階で行っているか: 文字数が1文字・上限・上限+1のケース、リストが1件・100件・1000件のケースでUIが崩れないか確認しているか？
空状態がブランドの機会になっているか: 空状態を「ネガティブな状態」ではなく、ユーザーを次のアクションへ誘導する「チャンス」として設計しているか？

5. UI例

同じ「タスクリスト」でも、状態設計の有無でユーザー体験は大きく変わります。

改善プロセス

1. 4状態をリストアップする: 非同期UIを設計するとき、最初に「ローディング・成功・エラー・空」の4状態をリストアップし、それぞれのUIを定義する。
2. スケルトンスクリーンに変える: ローディング中のスピナーをスケルトンスクリーンに変えることで、コンテンツの形が見え、レイアウトシフトが減る。
3. 空状態に次のアクションを追加する: 真っ白な空状態に「まだデータがありません」＋「追加ボタン」を加えることで、ユーザーを次のアクションへ誘導できる。

6. 関連リンク

• 関連リファレンス（理論）: 防衛的デザイン (Defensive Design)
• 用語集（定義）: 防衛的デザイン, エラー防止
• 関連するUI原則（横）: 誤操作を防ぐ (Error Prevention), エラーから回復できる (Error Recovery), 目的と制約を先に置く (Goals & Constraints First)

7. まとめ

今日から直せる一手 担当しているサービスの主要なリスト画面を確認してください。「データが0件のとき」何が表示されるか確認してください。真っ白な画面なら、今日中に「まだデータがありません」＋次のアクションへの案内を追加してください。

チームに共有するなら一言 「デザインは『うまくいったとき』だけ描かない。ローディング・エラー・空状態——それらすべてが体験だ。」