空状態のUI設計：コンテンツがないときに次の一歩を示す

1. 空になっている理由を診断する

空状態は装飾の機会ではなく、プロダクトの状態を伝えるものとして扱いましょう。画面が現れる直前に何が起きたか、システムが何を把握しているか、利用者が状況を変えられるかを確認します。NN/gは空状態を、状況を伝え、学習を支え、主要なタスクへの道筋を示す機会と説明しています。こうした機会を生かすには、まず状態を正しく特定する必要があります。

特に、リクエストの実行中に「項目がありません」と表示してはいけません。結果が分かるまで、読み込み表示やスケルトンを維持します。リクエストが失敗した場合は、失敗と復旧方法を説明します。成功しても項目が0件なら、一致するコンテンツがないと伝えます。この区別により、一時的な遅延やシステムの問題を実際の結果と取り違えずに済みます。

2. 原因に合った文言を書く

見出しで状態を示し、補足文でその意味や進み方を説明します。見出しはひと目で読める長さにします。実際の疑問に答える場合にのみ一文を加えましょう。Appleのライティングガイドは、空白画面で明確な次の一歩を示すこと、操作を表すラベル、問題の直し方を説明する直接的なエラーメッセージを勧めています。意味を曖昧にする気の利いた表現、「ここには何もありません」のような漠然とした見出し、利用者を責める文言は避けます。

例えば、初回利用時の仮想的な保存済み項目画面なら、「保存したガイドはここに表示されます」に続けて「後で見返せるようにガイドを保存しましょう」と示し、「ガイドを見る」ボタンを置けます。完了したチェックリストなら、「すべて完了しました」と伝え、「完了したタスクを見る」を提示できます。前者は機能に項目を追加する方法を教え、後者は成功した結果を確認するもので、表す現実が異なります。

検索が正常に終わって一致するものがなければ、仮想的な文言として「『orchid』に一致するプロジェクトはありません」と示し、「より広い言葉で検索するか、フィルターを解除してください」と提案できます。検索語を残し、可能ならフィルターの変更を元に戻せるようにします。ネットワーク障害なら、「プロジェクトを読み込めませんでした」と「再試行」を表示します。システムがまだ確認できていないのに、プロジェクトが存在しないと言い切らないでください。

• メッセージだけでも文脈が分かるよう、対象の項目や条件を明示する。
• ボタンには「プロジェクトを作成」「フィルターを解除」「再試行」など、動詞を使う。
• 指示は対象のコンテンツの近くに置き、色や画像だけでなくテキストも使う。
• 解決に必要な場合を除き、「おっと」、責める表現、技術的なコードは避ける。

3. 次の一歩を有用にし、機械的に設置しない

利用者が状況を変えられる、またはタスクを続けられる場合に操作を示します。初回利用には作成・追加、結果なしには条件の解除、エラーには再試行が有効なことが多いでしょう。空になった受信箱や完了した運動記録には、操作がまったく不要かもしれません。パネルを操作可能に見せるためだけに、どの状態にもボタンを押し込まないでください。

復旧方法は問題の大きさに合わせます。更新に失敗した程度なら、通常は画面内の説明と再試行で十分で、操作を遮る警告は不要です。Appleは、情報の重要度に応じたフィードバックを示し、警告は重大で対処可能な状況に限ることを勧めています。検索では、利用者の入力を残し、黙って検索語を変更するのではなく、適切な調整方法を提示します。Material Designも、本当に役立つ場合の代替案として、初期コンテンツ、短い説明コンテンツ、明確に表示された最も近い結果を提案しています。

イラストは、文脈、親しみやすさ、認識のしやすさを加える場合にのみ使います。メッセージより目立たせたり、飾りの画像を操作可能だと誤解させたりしてはいけません。小さなフィルター結果なら単純なアイコンで十分かもしれません。初回利用のワークスペースには、今後入るコンテンツの小さな例が役立つことがあります。初期コンテンツを入れるなら、それと分かり、削除しやすくしてください。

• 原因に直接対応する主要操作を一つ選ぶ。
• 予想される追加の疑問に答える場合にのみ、二次的なヘルプ経路を加える。
• 空になったことが良い知らせなら、控えめな完了メッセージを使う。
• キーボードやスクリーンリーダーの利用者にも操作が理解できるようにする。

4. イラストだけでなく状態全体を確認する

実際の配置領域で状態を確認しましょう。全画面の初回利用ビュー、小さなサイドバー、絞り込み済みの表では、必要な余白と情報の階層が異なります。メッセージは説明対象の近くに置きます。文字が大きくなったり折り返されたりしても読めること、色の識別に頼らず主要操作を見つけられることを確かめましょう。読み込み中から空へ、読み込み中からエラーへ、再試行から成功へ、フィルター変更から結果の再表示へという遷移もテストします。

ライブラリを使った実践的なレビューは、きっかけと想定される復旧方法から始まります。各パターンについて、状態、見出し、任意の説明、主要操作、二次的な経路、選択後に起こることを記録します。スクリーンショットで有用な構造と視覚的な階層を比較したら、プロダクトの動作を文脈の中で確認します。静止画だけではエラーから復旧できるか、結果が本当に空かは分かりません。ScreenKitsのUIライブラリを視覚的な事例として閲覧し、すべてのカテゴリから関連するパターンを探しましょう。

• コンテンツがないのか、読み込み中なのか、エラーで利用できないのかを利用者が見分けられるか。
• メッセージは現在の検索語、フィルター、アカウント、完了したタスクを反映しているか。
• 操作は有用な入力を残し、目に見える結果につながるか。
• 小さい表示領域、長い翻訳文、支援技術でも状態が機能するか。
• エラーから復旧したり、結果のない検索を調整したりできるか。