𝗗𝗼𝗻'𝘁 𝗨𝘀𝗲 𝗢𝗻𝗲 𝗚𝗲𝗻𝗲𝗿𝗶𝗰 𝗘𝗺𝗽𝘁𝘆 𝗦𝘁𝗮𝘁𝗲 𝗙𝗼𝗿 𝗬𝗼𝘂𝗿 𝗗𝗮𝘁𝗮 𝗧𝗮𝗯𝗹𝗲𝘀
ほとんどのデータテーブルは、「データがありません」というたった一つのメッセージを表示してリリースされます。
デザインレビューでは問題なさそうに見えますが、本番環境ではサポートチケット（問い合わせ）を量産することになります。
テーブルが空であることは、3つの異なる状況を意味します。それぞれのケースに対して、特定のデザイン、特定のテキスト、そして特定の操作が必要です。
個別に設計すべき3つのケースは以下の通りです：
初回利用時（まだデータが存在しない場合） ユーザーは新規です。このテーブルが何をするものなのか、どうやって始めればいいのかを知りたがっています。 • ゴール：ユーザーをオンボーディングする。 • テキスト：テーブルの目的を説明する。 • アクション：最初のアイテムを作成するか、データをインポートするためのボタンを提供する。 • 回避すべきこと：「データがありません」のような、行き止まりを感じさせるメッセージ。
フィルタリングによる空（データは存在するが、フィルタによって隠れている場合） ユーザーが適用したフィルタの結果、該当するデータがゼロになった状態です。ユーザーはツールが壊れていると勘違いすることがよくあります。 • ゴール：ユーザーがデータを見つけられるよう支援する。 • テキスト：どのフィルタが有効になっているかを明示する。 • アクション：すべてのフィルタをクリアするか、編集するためのボタンを提供する。 • 回避すべきこと：有効なフィルタを無視した汎用的なメッセージ。
ロード失敗（リクエストが失敗した場合） サーバーがエラーを返したか、ネットワークが切断されました。 • ゴール：ユーザーの復旧を支援する。 • テキスト：ロードに失敗したことを説明し、タイムスタンプやエラーコードを表示する。 • アクション：再試行（リトライ）ボタンを提供する。 • 回避すべきこと：実際には技術的なエラーであるのに、ユーザーに「データがありません」と伝えること。
なぜチームはこれに失敗するのか：
- プロセスの後半になってから空の状態（Empty State）を設計している。
- デモデータだけでテストしているため、空の状態を一度も目にすることがない。
- 空の状態をエッジケース（例外的なケース）として扱っている。
実際には、空の状態は非常にレバレッジの効く瞬間です。優れた空の状態は、ユーザーを数分で「ゼロ」から「価値」へと導きます。一方、悪い状態はユーザーを混乱させ、フラストレーションを与えます。
テーブルコンポーネントは、これらの条件を個別に処理できるように構築してください。今設計しておくコストはわずかですが、後々の膨大なサポート時間を節約することにつながります。