空状態のデザインパターン：利用者を次の行動へ導く

空状態は、なぜコンテンツがないのかと、次に役立つ行動を説明します。新しいプロジェクトなら最初のファイルを作る方法、検索結果がなければ条件を調整する方法、リクエストが失敗したなら復帰方法が必要です。三つを「何もありません」でまとめると、利用者に原因の診断を押し付けます。

アプリケーションが知っていることから始めます。リクエスト中なら進行を示し、失敗なら本当に空のコレクションと分けます。関連する検索が正常に完了した後だけ、ゼロ件画面を表示します。

以下のパターンでは、ファイル領域、検索、ダッシュボード、共有ワークスペースについて、文言、回復操作、引き継ぎに必要な状態ロジックを扱います。これらはナビゲーションバーの設計（英語）や確認ダイアログのパターン（英語）と組み合わせて使えます。

利用者の次の仕事から始める

アイコンや一文を選ぶ前に、利用者が完了しようとしていた仕事を特定します。「ファイルがない」は、チームがまだ作成していない、フィルターがすべてを隠している、インポート中、アクセス権がない、という異なる状態を表します。説明と操作も分けます。

状態と次の操作を、短い文で説明します。

「このプロジェクトにはまだファイルがありません。プロジェクトを編集できるメンバーが最初のファイルを作成できます。」

この文は見えている条件と推奨操作を分け、確認すべき仮定も明らかにします。「mobile」だけを検索したなら、「ワークスペースが空です」ではなく「この検索に一致する項目がありません」と説明します。

コンポーネントを作る前に、小さな状態レコードを作成します。

このレコードは引き継ぎ資料になります。製品が支えられない主張を、見た目だけでデザインに埋め込むことを防ぎます。

一つの汎用的な空白ではなく四つのパターンを使う

初回利用の状態

コレクションが本当に新しい初回利用では、目的を一文で説明し、価値を生む最小の操作を示します。プロジェクトボードなら「ここで決定と担当者を追跡できます」と書き、「ボードを作成」を置きます。長いチュートリアルを先に見せず、テンプレートは補助の選択肢にします。

検索結果なしの状態

コレクションにデータはあるが現在の検索やフィルターに一致しない場合は、検索語を表示したまま条件を正確に説明します。「フィルターを解除」「すべてのプロジェクトを検索」のような、元に戻せる操作を示します。項目の作成が現在の検索目的に実際に関係する場合を除き、「作成」ボタンは表示しません。既存の請求書を探している人へ重複作成を促してはいけません。

完了または意図的な空状態

完了した、または意図的に空の状態もあります。未処理のレビュー依頼がない受信箱なら、行動を促さず静かに確認します。「このプロジェクトに未処理のレビュー依頼はありません」のように範囲と期間を示し、別の操作は低い強調のリンクにします。

ブロックまたはエラーの状態

インターフェースが期待するコンテンツを取得できない、または現在の利用者に閲覧権限がない場合もあります。取得失敗には「再試行」、確認済みの権限制限には製品が対応する場合に「アクセスを申請」を示します。検索語と入力済みのデータは保持します。リソースの存在を明かせないときは、名前や内容を確認する表現を避け、承認済みの中立的な文言を使います。

これらは視覚的・意味的に別の状態です。スピナー、検索結果なしのイラスト、アクセス制限の鍵は同じシェルを共有できますが、文言とボタン階層は共有しません。

明確な回復操作を一つ置く

主操作は、その文脈で理解できる動詞にします。「プロジェクトを作成」「フィルターを解除」「再試行」「アクセスを申請」「ファイルをインポート」のように書き、別フローを開くならラベルで説明します。現在地と入力を操作後も保持します。

安全な代替には「すべてのプロジェクトを見る」「権限の仕組みを読む」「管理者へ連絡する」などを使います。五つの経路に同じ強さを与えると、空状態が意思決定画面になります。

ボタン名は翻訳後やスクリーンリーダーでも具体的である必要があります。「実行」のようなラベルは周囲のイラストを見られないと意味を持ちません。余白と文字の設計は製品で採用しているUI原則（英語）にそろえ、装飾パネルに収めるためだけに本文の文字を小さくしないでください。

フィルターと検索の文脈を保つ

検索とフィルターの空状態は最も作業を失いやすい場所です。適用中のチップや検索語をメッセージの上に表示し、リセット操作を明確にします。日付範囲が有効なら、隠れたコントロールだけに頼らず人が読める形で繰り返します。

フィルターが複数あるときは、回復操作が何を変えるかを正確に示します。Archivedを外せば結果が出ると分かるなら「Archivedフィルターを外す」と書き、原因が分からなければ個別解除と全解除を選ばせます。どの変更で結果が戻るか確認できない場合は、回復を約束しないようにします。保存済みビュー名も残し、「このビューに該当結果がない」と「ワークスペース全体に項目がない」を区別します。

表では本体が空でも列見出しを保持します。ダッシュボードでは期間と指標名を表示し、値がゼロ、利用不能、未収集のどれかを説明します。空のグラフとゼロ値のグラフは同じではありません。

権限状態は別の会話として扱う

権限による空状態には慎重な文言が必要です。アクセスがないだけなのに「プロジェクトがありません」と書かず、「このビューのプロジェクトにアクセスできません」と境界を示し、製品が対応している場合にのみアクセス申請へ進めます。所有者名やポリシーの説明は、正確かつ権限上許された情報を表示できるときに限ります。

ファイル領域や協働ツールでも同じ原則を使います。共有フォルダーはメンバーによって空にもデータありにも見えるため、ページ構造を変えず役割別操作を示します。アップロード領域では制約と回復経路（英語）を実際の条件に合わせます。

実際のコンテンツに耐えるコンポーネントにする

空状態を英語二行、単一の幅だけで設計しないでください。長い翻訳、任意の説明がない場合、無効な操作、狭いモバイル幅でも確認します。高さの低い画面でも、イラストによって主要な操作がスクロールしないと見えない位置へ押し出されないようにします。

部分状態も扱います。一部のカードは表示できるが一件の取得だけ失敗する、初ページは空だがバックグラウンドでインポート中、という場合はページ全体を空パネルに置き換えず、影響範囲の近くにインラインの状態表示を置きます。取得できたコンテンツは残し、何がまだ処理中なのかを伝えます。

チームダッシュボード（英語）では、空の指標がゼロ、該当なし、保留、利用不能のどれかをデータ契約で決めます。カードを完成して見せるために、欠測値を安心できるゼロへ変換しません。

同じPixsoファイルに、ファイルがない新規プロジェクト、検索結果なし、アクセスできないファイルの三つを作ります。レイアウトはそろえながら原因と操作を変え、狭い幅で比較し、別の役割の人に何が起きて次に何をするかを説明してもらいます。これにより、汎用的すぎる文言や誤解を招くボタンを開発へ引き継ぐ前に見つけられます。

空状態をPixsoで作成・比較する →

デザインから開発への引き継ぎで状態を注記する

状態名、トリガー、表示文、操作、分析イベント、操作後の戻り先を記録します。単純な表で十分なことが多いです。

検索結果を画面内で更新するときは、検索コントロールからフォーカスを移さず、支援技術へ結果メッセージを伝えます。「invoiceに一致する結果はありません」のような短いステータスを使い、結果パネル全体をライブ領域にして同じ通知を繰り返さないようにします。フォーカスを移すのは、ダイアログを開くなど操作の文脈が実際に変わる場合です。この挙動も文言や操作名と一緒に記録します。

現実的なシナリオで文言を検証する

新規、再訪、保存済みフィルター、アクセス制限、低速接続の利用者で同じコンポーネントを試します。何が起きたと思うか、次に何をするかを尋ね、異なる状態が同じ見た目になるならデータと文言で差を明示します。

特に、次のような見落としやすいケースを確認します。

1. 再試行が成功しても古いエラーが残る。
2. 検索語にエスケープまたは切り詰めが必要な文字が含まれる。
3. 翻訳後の操作ラベルが三行になり、ボタン幅が変わる。
4. 空状態を開いている間に利用者が権限を失う。
5. インポート中のためコレクションが空に見える。
6. 読み取り専用メンバーには操作が使えない。

これらのケースを同じデザインファイルに記録し、最終コンポーネントを実装メモへリンクします。孤立したスクリーンショットより、状態と判断がつながったワークフロー（英語）の方が保守しやすくなります。

三つの失敗ケースでコンポーネントを試す

低速接続、リクエスト失敗、本当に一致しないフィルターで同じ検索を実行します。各条件を正しく識別し、回復中も検索語を保持します。読み取り専用メンバーでは、関連オブジェクトを作成できる場合にだけ作成ボタンを表示します。

参考資料

• W3C：ステータスメッセージ（英語）
• W3C：Web Content Accessibility Guidelines 2.2（英語）
• MDN：Accessible name（英語）