空状態UI設計例：体験を止めない空画面パターンと実装アイデア

空状態UIは「何も表示するものがないときの飾り」ではなく、ユーザーの体験を途切れさせないための重要な接続部です。情報が存在しない、検索にヒットしない、まだ作成していない、権限がない、読み込みに失敗した、といった状況は、ユーザーの操作の流れから見ると「次に何をすればよいかが不明になりやすい地点」です。ここで画面が静かに空白のままだと、ユーザーは「壊れているのか」「自分の操作が間違っているのか」「そもそも何をすればいいのか」を判断できず、離脱や誤操作が増えます。空状態UIの価値は、説明ではなく「次の一手が確実に打てる状態」を作ることにあります。

実務で空状態が難しいのは、プロダクトの成長とともに空状態の種類が増え、画面ごとに説明やCTAがバラバラになりやすい点です。たとえばテーブル、カード一覧、ダッシュボード、検索結果、設定画面などで空状態が連鎖すると、トーンが揺れたり、同じ状況でも違う言い回しになったり、押しても意味のないCTAが置かれたりします。結果として「空状態はいつも信用できない」という印象が蓄積し、ユーザーは空状態を読まずに戻るようになります。そこで本稿では、空状態UIを「状況の分類」「構成要素」「代表パターン」「CTAと文言」「実装と運用」の順で体系化し、増えても破綻しない設計の枠組みに落とし込みます。

1. 空状態UI（Empty State）とは？

空状態UI 設計を安定させるには、まず「空とは何か」を定義しておく必要があります。空状態は一見すると同じ“何もない画面”に見えますが、原因が違えばユーザーの心理状態も、必要な行動も変わります。初回で何もないのと、検索でゼロ件なのと、権限がなく見えないのと、エラーで取れないのは、同じ「空」ではありません。ここを混同すると、最適な誘導ができず、無関係なCTAや誤った説明が置かれ、体験の破綻に繋がります。

1.1 「空状態」と「エラー」「ローディング」の境界

空状態UIは、データが存在しない、または現在の条件では表示できるものがない、という「正常系」の一種として扱うのが基本です。一方で、データがあるはずなのに取得に失敗している場合はエラーであり、取得中で結果が未確定ならローディングです。ここを曖昧にすると、ユーザーは「待てば出るのか」「条件を変えるべきか」「再試行すべきか」を判断できません。UIとしては、空状態は「次の行動で作れる・見つけられる」ことを前提にし、エラーは「再試行・代替手段・原因の説明」を前提にし、ローディングは「待つ価値があること」と「待ち時間の扱い」を前提にします。

実務上は「空に見えるが実は失敗している」ケースが最も危険です。たとえば検索APIがタイムアウトしても、UIが空状態だけを出すと、ユーザーは条件が悪いと思って検索語を変え続けます。逆に本当にゼロ件なのにエラー表現を出すと、ユーザーは不安を感じて離脱します。空状態UI 設計では、画面を出し分ける条件（データ未取得／取得成功ゼロ／取得失敗／取得中）を状態として明示し、コピーとCTAを状態に紐づけるのが安定します。

1.2 空状態UIがUXに与える影響

空状態は、ユーザーが「自分は正しい場所にいるのか」を確認するタイミングでもあります。情報がある画面では、ユーザーは情報そのものを読めばよいのですが、空状態では情報がないため、UIが状況説明の主役になります。つまり空状態は、UIの説明責任が最も高い瞬間です。ここで説明が弱いと「プロダクトが壊れている」印象が残りやすく、逆に説明と行動が分かりやすいと「親切なプロダクト」へ印象が傾きます。

また空状態は、ユーザーの次の行動を誘導できる数少ないチャンスでもあります。初回なら「最初の作成」、検索ゼロなら「条件の緩和」、削除後なら「次の作業」、権限なら「アクセス申請」、エラーなら「再試行や問い合わせ」へ繋げられます。空状態UI 設計は、単に空を埋める作業ではなく、プロダクトのオンボーディング、探索、復帰の導線を短距離で作る作業です。

1.3 空状態の代表的な分類

空状態を設計しやすくするために、原因ベースで分類しておくと運用が安定します。分類は「画面の種類」ではなく「ユーザーに必要な次の一手」で切ると、コピーとCTAが決まりやすくなります。

この分類に沿って空状態UIを揃えると、画面が増えても「何を言うべきか」「何を押させるべきか」が迷いにくくなり、空状態が体験の断絶点になりにくくなります。

2. 空状態UI設計の基本構造

空状態UI 設計は、要素を足し算するほど良くなるわけではありません。むしろ要素が多いほど、ユーザーは「読む」「理解する」負担が増え、次の行動に移りにくくなります。空状態で最も価値があるのは、短い理解と短い行動です。そのために、要素の役割と優先順位を固定し、必要な情報だけを適切な強さで提示します。

2.1 空状態UIの構成要素と役割

空状態の基本は「状況の宣言」「理由の補足」「次の行動」「補助導線」で構成すると、ほとんどのケースを破綻なく扱えます。視覚要素は説明の代替ではなく、理解の速度を上げる補助として位置づけると、イラスト依存の事故が減ります。

この構造の狙いは、空状態を「止まり」ではなく「分岐」に変えることです。空は情報がない状態ですが、行動は作れます。空状態UI 設計では、情報の不足を行動の提示で補い、ユーザーの手が止まらない状態を作ります。

2.2 タイトルと説明文の組み合わせ

空状態のコピーは、基本的に流し読みされます。だからこそ「タイトルだけ読めば状況が分かる」「説明だけ読めば次の行動が分かる」という二段構えにすると強くなります。タイトルは状況の宣言で、説明は理由と次の一手の橋渡しです。たとえば「結果が見つかりません」だけだと、ユーザーは次に何をすればよいか分かりませんが、「検索条件を少し広げると見つかりやすくなります」の一文があるだけで、迷いは減ります。

説明文は長く書くほど親切に見えますが、空状態で長文は読まれにくいので、情報の密度を上げた短文が有効です。実務では「原因は何か」「次の操作は何か」「安全に戻れるか」を最小の文字数で伝えることが重要になります。特にエラー寄りの空状態では、原因を推測で断定しないことも大切です。「ネットワークの問題かもしれません」のように可能性として示し、再試行や代替導線を提示すると、過剰な不安を煽らずに復帰を促せます。

2.3 CTA（行動ボタン）の設計

空状態UIの主要CTAは「押した瞬間に状況が変わる」ことが前提です。押しても何も起きない、別ページに飛ぶだけで結局空のまま、権限がなくて戻される、といった体験は空状態の信頼を破壊します。CTAは機能ではなく約束なので、約束が守れない場合はCTAを置くより、次の行動を別の形で提示したほうが良いこともあります。たとえば権限不足の場合、作成CTAを置くと必ず失敗するので、申請や切替など“成功可能な行動”に寄せます。

また、主要CTAと補助CTAが競合すると、ユーザーが迷います。空状態UI 設計では、主要CTAは一つに絞り、補助導線はテキストリンク程度の強さに抑えると、次の一手が明確になります。複数の行動が必要なケースは、空状態で一気に提示するのではなく、主要CTAの先で分岐させるほうが、短距離で前進できます。

3. 空状態UI 設計パターン集

空状態UIはパターンに落とすと運用が一気に楽になります。画面ごとにゼロから文言とCTAを考えるのではなく、状況分類に応じて「このときはこう言う」「この行動を出す」という定石を作ると、トーンが揺れず、設計レビューも速くなります。ここでは、よく遭遇するパターンを、コピーと導線の型として整理します。

3.1 初回空（First-Use）空状態UI設計

初回空は、ユーザーが「何も作っていない」だけでなく、「この画面で何ができるかをまだ理解していない」状態でもあります。つまり初回空は、空状態であると同時にオンボーディングの入口です。ここで重要なのは、空である理由の説明より、最初の成功体験を短距離で作ることです。たとえば「プロジェクトがありません」と言うだけではなく、「最初のプロジェクトを作ると、ここに一覧が表示されます」という未来形を入れると、ユーザーは画面の意味を理解しやすくなります。

初回空のCTAは「作成」「開始」「インポート」のように、ユーザーが前進を感じやすい動詞に寄せると効果的です。加えて、難易度が高い作成が必要な場合は、サンプルデータの投入やテンプレート作成を用意すると、最初の摩擦が下がります。初回空は不安が少ない代わりに迷いが大きいので、説明は「何ができる画面か」を中心に、行動は「最短の一歩」を中心に設計すると、離脱が減ります。

3.2 検索結果0件（Empty Search）空状態UI設計

検索ゼロは、ユーザーが目的を持って探した結果としての空なので、初回空より心理的に強い失敗感が出ます。ここで単に「結果が見つかりません」とだけ出すと、ユーザーは自分の検索語が悪いのか、データがないのか、壊れているのかを判断できず、探索を諦めやすくなります。検索ゼロでは「何が原因でゼロになりやすいか」を軽く示し、「どうすれば結果が増えるか」を次の行動として提示することが重要です。

実務で強いのは、条件緩和の提案を具体化することです。たとえば「フィルターを外す」だけでなく「価格帯を広げる」「期間を広げる」「表記揺れを提案する」など、ユーザーが迷わず実行できる提案に落とすと、再検索が起きやすくなります。また、候補提示は万能ではないので、候補が出せない場合でも「検索のコツ」や「人気カテゴリを見る」といった代替導線を用意しておくと、探索が途切れにくくなります。

3.3 フィルター0件（条件空）空状態UI設計

フィルターによるゼロ件は、ユーザーが自分で条件を狭めた結果であることが多いため、「ゼロ件でも正常」という安心を与えることが大切です。検索ゼロは入力の失敗に見えやすいのに対し、フィルターゼロは設定の行き過ぎに見えやすいので、「条件が厳しすぎるかもしれません」といった軽い示唆が効きます。ここで重要なのは、ユーザーが今どの条件を適用しているかが見えることです。条件が見えないと、何を戻せばよいか分からず、空状態が長引きます。

CTAは「フィルターをリセット」「条件を1つ外す」など、復帰が短距離で成立するものに寄せます。さらに、UI上で「適用中の条件」をタグ表示し、ワンクリックで外せるようにすると、空状態からの復帰が劇的に速くなります。条件空は設計次第で、ユーザーが試行錯誤しやすい体験にも、迷子になる体験にもなるので、復帰の短さを最優先にします。

3.4 クリア後（完了/全削除）空状態UI設計

ユーザーが意図的に削除した後や、タスクを全て完了した後の空は、失敗ではなく達成の可能性があります。この場合、ネガティブな表現は不要で、達成感を軽く示しつつ次の行動を提示すると、体験が前向きになります。たとえば「すべて完了しました」や「今は項目がありません」といった“状況の確認”を先に置くと、ユーザーは安心できます。達成空は、ユーザーの状態が「次に進める」ことが多いので、次の行動は必須ではありませんが、あると再訪時の迷いを減らせます。

注意点は、削除が意図的ではないケースが混ざることです。たとえば一括削除が誤操作で起きる可能性があるなら、空状態の前にUndoや復元導線を用意するほうが優先です。空状態UI 設計は、空になった後に見せる画面ですが、空になる前の設計（Undo、確認）とセットで考えると事故が減ります。

3.5 権限不足（Permission）空状態UI設計

権限不足の空は、ユーザーにとって最も誤解が起きやすい空です。何もないのではなく「見えない」ので、理由が分からないと「データが消えた」と誤認されます。権限空では、空であることより「なぜ見えないか」を明確にすることが最優先です。ここで曖昧な文言にすると、ユーザーは問い合わせに流れ、運用コストが増えます。権限空は、コピーで運用を助ける領域でもあります。

CTAは「アクセス申請」「アカウント切替」「管理者に連絡」など、ユーザーが成功できる行動に限定します。作成や閲覧のCTAを置くと必ず失敗するので、空状態が“詰み”になります。権限空は心理的にストレスが高いので、説明は丁寧に、行動は短距離に設計すると、離脱や問い合わせを減らせます。

4. 空状態UIの実装アイデア

空状態UIはデザインだけでなく、実装の状態管理が整っていないと破綻します。原因が違う空（初回、検索ゼロ、フィルターゼロ、権限、エラー、ローディング）を、UIが同じ見た目で出してしまうと、ユーザーは状況を誤解します。つまり空状態UI 設計は、状態設計と一体です。

ここでは、空状態を状態として扱い、再利用できるコンポーネントに落とし込む実装の型を示します。

4.1 空状態UIの状態モデル（最低限のステート設計）

空状態を安定させるには、表示分岐を「データの有無」だけで決めないことが重要です。取得中なのか、成功してゼロなのか、失敗してゼロに見えているのか、権限がないのかを区別します。UIはこの区別に従ってコピーとCTAを変えることで、誤解を減らします。

// 空状態を「原因」で分類する最小モデル（TypeScript例） export type EmptyStateKind =  | "first_use"     // 初回（未作成）  | "empty_search"  // 検索0件  | "empty_filter"  // フィルター0件  | "cleared"       // 完了/削除後  | "permission"    // 権限不足  | "error"         // 取得失敗  | "loading";      // 取得中 export type EmptyStateSpec = {  kind: EmptyStateKind;  title: string;  description?: string;  primaryCta?: { label: string; action: () => void };  secondaryCta?: { label: string; action: () => void };  helpLink?: { label: string; href: string }; };

このモデルの狙いは、空状態のコピーとCTAを「画面ごとの思いつき」にしないことです。状態が増えても「kindを足す」「specを足す」で対応できると、トーンと挙動が揃い、空状態がプロダクト全体で一貫します。

4.2 再利用できる空状態UIコンポーネント（React例）

空状態は画面ごとに作り込みたくなりますが、見た目と構造を共通化し、文言とCTAだけを差し替える設計にすると運用が強くなります。以下は最小の例で、タイトルと説明、主要CTA、補助CTAを同じ構造で出します。

type Props = { spec: EmptyStateSpec }; export function EmptyState({ spec }: Props) {  return (    <section aria-label="空状態" style={{ textAlign: "center", padding: 24 }}>      <h2 style={{ margin: 0 }}>{spec.title}</h2>      {spec.description ? (        <p style={{ marginTop: 8, marginBottom: 16 }}>{spec.description}</p>      ) : (        <div style={{ height: 16 }} />      )}      <div style={{ display: "flex", justifyContent: "center", gap: 12, flexWrap: "wrap" }}>        {spec.primaryCta ? (          <button onClick={spec.primaryCta.action}>{spec.primaryCta.label}</button>        ) : null}        {spec.secondaryCta ? (          <button onClick={spec.secondaryCta.action}>{spec.secondaryCta.label}</button>        ) : null}      </div>      {spec.helpLink ? (        <p style={{ marginTop: 16 }}>          <a href={spec.helpLink.href}>{spec.helpLink.label}</a>        </p>      ) : null}    </section>  ); }

実務ではこの上に、画面種別に応じたサイズ調整（テーブル内はコンパクト、全画面は広め）、アイコンの差し替え、モバイルでのボタン幅などを重ねます。ただし構造を揃えておくと、どの画面でも「空状態の読み方」が同じになり、学習コストが下がります。

5. 空状態UI設計で避けるべき失敗とチェック観点

空状態UIは軽視されやすい一方で、失敗すると体験が一気に悪化します。空状態はユーザーが迷いやすい局面なので、少しのズレが離脱や問い合わせに直結します。

ここでは、よくある失敗を「症状」と「対策」に落として、レビューで使える観点として整理します。

5.1 よくある失敗パターン

空状態UI 設計のレビューでは、「このコピーは状況を宣言できているか」「理由が誤解を生まないか」「主要CTAは必ず前進するか」「補助導線は競合していないか」を見ます。空状態は短時間で読まれる前提なので、文章を磨くより構造を揃えることのほうが効果が出やすいです。

5.2 空状態UIのチェックリスト（実務向け）

まとめ

空状態UI設計は、単なる「何もない画面」の装飾ではなく、ユーザーの行動を止めないための導線設計です。初回空、条件空、完了空、権限空、エラー空、ローディングなど、空には原因ごとの種類があり、それぞれユーザーの心理と必要な次の一手が異なります。だからこそ、状態を原因ベースで分類し、タイトル・説明・主要CTA・補助導線といった構成要素を揃えたうえで、状況に合うコピーと成功可能性の高いCTAを提示することが重要です。空状態は「情報がない」場面ではなく、「次の行動を定義する」場面であり、設計次第で離脱ポイントにも転換点にもなります。

運用が進むほど空状態は増え続けるため、画面単位で個別対応するのではなく、状態モデルとして整理し、コンポーネント化して共通化するほうが強くなります。UI構造は統一し、差し替えるのは文言と行動だけにすることで、一貫性と改善効率を両立できます。空状態UIが常に理由を説明し、具体的な一歩を示し、実際に前進できる体験を提供できているか。その品質が安定するほど、ユーザーは迷わず前に進み、プロダクト全体の体験はより滑らかになります。