空状態設計

空の状態とは、表示するコンテンツがない場合にインターフェースが表示する状態です。例えば、データのない新規アカウント、検索結果が返されない検索、一致するフィルターの組み合わせがない、受信トレイがクリアされた、または最初のエントリを待っているリストなどが挙げられます。空の状態は、ほとんどの製品において最も軽視されがちな画面の一つです。なぜなら、デザイナーが想定するケースではなく、デザインレビューに使用されるモックアップにもほとんど含まれていないからです。

こうした軽視は大きな損失につながります。なぜなら、最も重要な局面で、ユーザーにとって不都合な状態（空の状態）が生じるからです。新製品のユーザーは皆、空の状態からスタートします。そこで目にする情報によって、製品の目的を理解し、最初の行動を起こせるかどうかが決まります。一般的なメッセージが表示されただけの空白の画面では何も得られません。一方、適切に設計された初回使用画面は、そこに何が必要で、なぜそれが重要なのかを説明し、明確な開始方法を示します。オンボーディングの効果は、後から追加されるツアーやチュートリアルよりも、むしろこうした画面によって大きく左右されるのです。

検索結果に一致する項目がない場合も、2番目に価値の高いケースです。「検索結果が見つかりませんでした」とだけ表示されると行き止まりとなり、訪問者は再度検索するか、サイトを離れるしか選択肢がありません。一方、検索内容の説明、スペル修正の提案、最も制限の厳しいフィルターの緩和、関連用語の提案、よく使われる代替語の表示、ヘルプへの案内など、より分かりやすい画面表示が行われます。ビジネスにおいては、検索結果がゼロの訪問者は明確な意図を持ちながらも先に進む道筋が見えない状態であり、サイト上で最も価値の高い、回復可能な失敗例の一つと言えます。

空の状態は、システムの問題を明らかにするエラーやエッジケースの接点としても機能します。リクエストの失敗によって空になったリストは、実際に何も存在しないために空になったリストと全く同じように見えてはなりません。なぜなら、正しい処理が全く異なるからです。空の状態、読み込み中の状態、失敗の状態を区別し、それぞれを明確に伝えることで、正常に動作している製品が故障している、あるいは故障している製品が単に新しいものだとユーザーが誤解することを防ぎます。

適切に設計するには、実装段階でケースを発見するのではなく、設計段階で明示的に列挙する必要があります。各リスト、テーブル、検索、ダッシュボードについて、次の点を検討する必要があります。何も表示されていない場合、1つのアイテムが表示されている場合、標準的な数が表示されている場合、極端な数が表示されている場合、読み込み中、そしてエラー発生後、それぞれどのような表示になるのか。これらの質問に体系的に答えることで迅速に回答を得ることができ、開発者がスプリントの最後に空のバリアントを場当たり的に作成するというよくある事態を防ぐことができます。

空の状態は、単なる説明ではなく、教える機会でもあり、まさにその点でこそ真価を発揮します。初めて使用する状態において、実際のサンプルコンテンツを明確に示し、入力済みのビューがどのようなものかを例示することで、製品の目的をどんな説明よりも早く伝え、新規ユーザーに目標​​を与えます。削除後や完了後の状態にも同じアプローチが当てはまります。スペースの用途を示すことで、ユーザーが何かがうまくいかなかったと誤解するのを防ぎます。ただし、制約は誠実さです。実際のコンテンツと区別がつかないサンプルコンテンツは混乱を招き、金銭や記録を扱う製品では重大なエラーを引き起こす可能性があります。

空の状態はインターフェース設計と製品理解の境界に位置するため、通常は独立した画面としてではなく、フローの一部として扱われます。 製品設計 それらは、人口の多い州と並んで標準的な慣行として指定され、 UX監査 ほぼすべての製品には、設計段階で意図されなかった空の状態が少なくとも1つ存在し、それがユーザーが初めて製品に触れた際に、一部のユーザーを密かにブロックしてしまうため、これらの情報は信頼できる調査源となる。