複雑なアプリケーションにおけるエンプティステートをデザインする：3つのガイドライン
エンプティステートは、デザイナーがシステムの状態を伝え、システムの学習しやすさを高め、重要なタスクのための直接的な経路を提供する機会だ。この記事では、コンテンツが入っていないコンテナのためにエンプティステートのダイアログをデザインする際の指針を示す。
ユーザーは、アプリケーションで、コンテナや画面、パネルのためのコンテンツがまだ存在しないか、表示できないという空の状態＝エンプティステートに遭遇することがある。
特に、ユーザーによる設定がまだ完全に終わっていない複雑なアプリケーションでは、オンボーディングや初期の利用時に、エンプティステートが発生することがよくある。アプリケーションでユーザーがエンプティステートに遭遇する典型的なシナリオには以下のようなものがある：
- ユーザーが「お気に入り」に項目をまだ登録していない場合や、そのアプリでファイルを一度も開けたことがない場合、お気に入りや最近表示した項目の一覧を表示するためのコンテナが空になる。
- アプリケーションがアラートをサポートしているにもかかわらず、ユーザーがまだアラートを1つも設定していない場合、そうしたアラートが最終的に表示されるはずの場所に空のペインやダイアログが表示される。
- アプリケーションがさまざまなワークスペースやダッシュボードで構成されているにもかかわらず、ユーザーがそうしたエリアにコンテンツをまだ追加していない場合、そのページや画面が空になる。
- 結果が何も見つからなかった場合の検索結果一覧や、コマンドで空白行が出力された場合など。
空のスペースのデフォルトの表示とは、単に空のままにしておくことだ。つまり、このスペースの設定が行われたり、パーソナライズされたりするまで、ユーザーには何もコンテンツが表示されない。しかし、このアプローチは、開発時間の節約にはなるが（あるいは、他の機能をまず優先する必要がある製品の初期のベータデザインでの意図的な決定なのかもしれないが）、結果的には混乱を招き、ユーザーの自信を失わせる。さらに、アプリケーションのユーザビリティや学習しやすさ、重要な機能の発見しやすさを向上させるたくさんの機会を逃すことにもなる。
一方、（後から思いついたのではなく）意図的にデザインされたエンプティステートは、以下の目的のために利用することができる：
- システムの状態をユーザーに伝える。
- 利用されていない機能を発見しやすくし、アプリケーションの学習しやすさを向上させる。
- 重要なタスクを開始するための直接的な経路を提供する。
エンプティステートを利用して、システムの状態を伝えよう
何も表示されていない空間があると、システムがどのように機能しているのか、さらにそもそも機能しているのかどうかが紛らわしい。検索フィルターをかけたり、検索問い合わせを行ったり、特定のコンテンツを表示させようとしたのに、インタフェースに空のパネルや画面が表示されると、「リクエストした処理は終わったのだろうか」、「まだコンテンツの読み込み中なのだろうか」、「エラーが起きたのだろうか」、「検索フィルターやパラメータの設定を間違えたのだろうか」といった無数の質問をユーザーが抱えたままになりかねないからだ。
例として、ログの詳細を表示するための以下のダイアログについて考えてみよう。ユーザーがログの存在しない日付範囲を指定して適用すると、ダイアログ内の表には、論理的に考えて、ログの詳細情報が表示されることはない。しかし、システムからのフィードバックが何もないと、表示できる詳細情報が本当にないのか、それとも、エラーが発生したのか、あるいは、システムがまだこのリクエストを処理中なのかがユーザーにはわからない。そのため、ユーザーは、次に進んでもよいという十分な確信が得られるまで、何度も検索キーワードを更新して時間を無駄にする可能性がある。
プロセスの完了時にコンテンツエリア内に簡潔なシステムメッセージ（たとえば、「選択した日付の範囲には表示できる記録がありません」（There are no records to display for the selected date range.））を表示するのは、システム状態の視認性を向上させることによって、表示された結果に対してユーザーが自信を持てるようにするシンプルかつ効果的な方法である。
さらに悪いことに、特に情報密度が高く、処理に時間がかかるアプリケーションで同じくらいよく見られるのが、誤解を招くようなシステムステータスメッセージをデフォルトで表示しているものだ。こうしたシステムでは、表示する項目がない、と宣言しておきながら、処理が完了したところで、最終的にコンテンツを置き換えるのである。
たとえば、以下の従業員管理ソフトウェアでは、コンテンツを読み込むと、空の状態のコンテナが出て、そこに「記録がありません」（No records）というシステムステータスメッセージが表示される。この情報は、実際に記録がない場合には非常に有用である。しかしながら、数秒待つと、このシステムは、不正確なシステムステータスメッセージをリクエストされた項目に置き換えるのである。
エンプティステートに対する不正確なシステムステータスメッセージは特に有害である。最善のケースでは、ユーザーは処理が終わるまでじっと待ってから関連するコンテンツを発見しはするが、アプリケーションに対してひどい不信感と嫌悪感を抱くだろう。一方、最悪の場合、猪突猛進なユーザー（すなわち、ほとんどのユーザー）は、関連するコンテンツを決して見ることはないし、作業は完了できなくなる。
エンプティステートを利用して、学習のきっかけを提供しよう
ユーザーがタスクを開始すると表示される状況に応じた学習のきっかけは、彼らがシステムを探索する際に、アプリケーションやシステムの利用方法をリアルタイムで理解する役に立つ。このアプローチのほうが一般的には最初の利用時に表示される強制的なチュートリアルよりもうまくいくことが多い。状況に応じたヘルプは、即、生かせることが多いので、ユーザーの記憶に残りやすいためだ。実際、長ったらしいオンボーディングコンテンツと実際のインタフェースとの関連づけをする時間などユーザーにはほとんどないのである。
エンプティステートは、ユーザーのタスクに関連する、状況に応じたヘルプを提供する機会でもある。こうしたヘルプメッセージは、プル型表示とも呼ばれる。この表示に対応しているUI要素にユーザーがインタラクトしたときのみ表示され、押しつけがましかったり、邪魔になるやり方で「プッシュ」してこないからである。
たとえば、あるエンタープライズリソースプランニング（ERP）アプリケーションの以下の「アラート」パネルについて考えてみよう。「アラート」パネルにアラートが表示されている場合、ユーザーがどのようにそうしたコンテンツに取り組むかはわかりきっている。（以下のパネルは、おそらくアラート要素のモックアップを作ってテストしたときの状態と思われる）。しかしながら、「アラート」パネルが空の場合は、先ほど説明した問題が生じる。すなわち、エラーが発生しているのか、それとも、アラートを表示させるために必要なパラメータを正確に作成できていないのかがユーザーにはわからないのである。（先ほどの例のように、ここでもアラートがないことを示す簡潔なシステムステータスメッセージがあるといいだろう）。
さらに、「アラート」パネルに何も出さずに完全に空にしてしまうのは、ユーザーにアラート機能について教える機会を逃すことでもある。アラートとはどういうもので、使い始めるにどうしたらいいのかという情報を簡潔なダイアログで提供できるはずだからだ。
これに対し、データ監視アプリケーションのDataDogは、状況に応じたヘルプコンテンツを空の状態の中に表示している。たとえば、ユーザーがお気に入りのリストを作成するための項目にまだ何も星マークを付けていないと、コンテンツエリアになる予定の場所に、「お気に入りに星を付けて、ここに表示しましょう」（Star your favorites to list them here.）というメッセージが表示される。
同様に、Microsoft Power BIでは、最近表示した項目がまだ何もない場合、そこにコンテンツが追加される仕組みを説明する簡潔なシステムメッセージが空の状態の画面に表示される。
（画面中央の1行目「最近開いたコンテンツはここで見つけましょう」、2行目「Power BIのコンテンツを開いた後は、『Recents』に戻ってくるとそのコンテンツをすぐにまた見つけられます」）
エンプティステートを利用して、重要なタスクのための直接的な経路を提供しよう
システムステータスをユーザーに警告したり、プル型表示でシステムの学習しやすさを向上させたりする以外にも、エンプティステートを利用して、重要なタスクを開始したり、進行中のワークフローに関する手順を完了したりする直接的な経路を提供することが可能だ。
たとえば、あるアプリケーション開発ソフトウェアでは、タスク中に表示できる記録がない場合、そうした空の状態の中に、「記録がありません。ワークスペースの詳細を表示するには、リクエストを送信してください」（No Records; Send a request to view details in the workspace）というシステムステータスメッセージが表示される。このメッセージでは、記録を表示するには「何を」するとよいかという状況に沿った情報がしっかり提供されている（「ワークスペースで詳細を表示するには、リクエストを送信してください」とある)。その一方、このタスクを「どのように」実行するのか、あるいは、システムのどこに行けば必要な機能を見つけられるのかについての指示はない。
簡潔かつ明確な指示を提供するほうがいいだろう。または、もっといいのは、空のエリア内に、データを追加するタスクを完了させるための手順への直接リンクを張ることだ。(この事例では、「リクエストを送信してください」（Send a request）というテキストに、メッセージセンターへの直接リンクを張ったり、そこからメッセージのダイアログを起動できるようにするといいだろう)。
たとえば、以下のアプリケーションは、空の状態のパネル内で直接リンクを提供している。その結果、この「作成」（Create）というボタンによって、ユーザーはアラートを作成可能だ。また、アラートが役立つ理由とその利用方法を知るためにさらに情報が必要なユーザーは、「さらに詳しく」（Learn more）というリンク項目によって、関連するドキュメンテーションに直接アクセスすることもできる。
（右カラムの1行目「このビューにはアラートがありません」、2行目「アラートを作成すると、あなたのデータがその条件を満たしたときにメールでお知らせします。さらに詳しく」、3行目「グラフの数値軸を選択してから、『作成』をクリックしてください」、「作成」ボタン）
エンプティステートをこのようなデザインにすると、複雑なアプリケーション機能を使いはじめたばかりのユーザーにとっても有益であると考えられる。たとえば、クラウドベースのログ管理アプリケーションのLogglyでは、ユーザーが自分のアカウントにまだログデータを追加していない場合、空の状態の画面に、外部ログソースを追加するか、デモデータをアプリケーションに入力してこのアプリを安全に探索するか、というこの機能を使い始めるための2つの直接的な経路が表示される。
結論
アプリケーションのデザインをするときに、エンプティステートのデザインを後回しにしないようにしよう。意図的にデザインされたエンプティステートは、ユーザーに自信を持たせ、システムの学習しやすさを向上させ、重要なタスクを開始するのに役立つはずだ。
要点をまとめると：
- 完全に空の状態をデフォルトにしないようにしよう。そうすると、システムがまだ情報を読み込み中なのか、それともエラーが発生しているのか、ユーザーは混乱する。
- 画面やページ、パネルにコンテンツがまだ存在しない場合は、そのエンプティステートを利用して、ヘルプになる手がかりを提供しよう。そのエリアには、どのようなものが表示されるはずで、そこにコンテンツを入力するにはどうしたらいいのかをユーザーに伝えよう。
- 空の状態への入力に関わる重要なタスクを開始するための直接的な経路（すなわち、リンク）を提供しよう。
- プロセスが実行されているときは、進行状況インジケータを利用して、システム状態の視認性を高めよう。
- プロセスの完了後に表示できる関連データがない場合は、空のスペースを利用して、表示可能なコンテンツがないことを簡潔に伝えるシステムステータスメッセージをそのスペースに表示しよう。
