UIXHERO

Density Patterns(密度パターン)

UIの情報密度をユーザーや用途に合わせて切り替える設計パターン。Compact・Default・Comfortable の3段階・テーブル行・リスト・カードへの適用・ユーザー設定との連動を解説する。

2026年3月3日
更新: 2026年9月3日
22
by Dengen Yosho(DGYS)

の情報密度(要素の間隔・サイズ・詰め込み具合)をユーザーの用途・デバイス・好みに合わせて切り替える設計パターン。Compact(高密度)・Default(標準)・Comfortable(低密度) の3段階を提供することで、パワーユーザーは一覧性を優先し、一般ユーザーはを優先できる。

この記事を読むと、密度の3段階の使い分け・テーブル・リスト・カードへの密度適用・ユーザー設定との連動・間隔とフォントサイズのトークン設計が自分でできるようになります。


1. UI例(Preview / Live)


2. 定義(Definition)

UIの情報密度(行間・パディング・フォントサイズ・コンポーネントサイズ)をユーザーの用途・デバイス・好みに応じて段階的に切り替える設計パターン。

3段階の密度

密度特徴典型的な行パディング
Compactパワーユーザー・データ分析高一覧性・情報量最大py-1(4px)
Default汎用・一般業務バランス重視py-2.5(10px)
Comfortable一般ユーザー・モバイル可読性・タップしやすさ優先py-4(16px)

3. 使い分け(When to use / When NOT to use)

3.1 When to use

  • データ量の多いテーブル・リスト:パワーユーザーが1画面に多くの情報を見たい場面でCompactを提供
  • ユーザー設定画面:「表示密度」「コンパクトモード」オプションとして提供
  • デバイス別の自動切り替え:デスクトップはDefault、モバイルはComfortableを自動適用

3.2 When NOT to use

  • 1〜5件程度の短いリスト:密度切り替えの恩恵が少なく複雑性が増すだけ
  • フォーム画面:密度切り替えが入力体験を損なう可能性がある

4. 設計判断の核(Decision Principles)

Density Patternsの核は「密度トークンの一元管理」——個別のコンポーネントにpx値をハードコードすると、密度切り替え時に全箇所を変更する必要が生じる。密度を変数(CSSカスタムプロパティやJSオブジェクト)で管理することで、1箇所の変更が全体に伝播する。

判断の優先順位:① 密度トークンの設計(変数化)→ ② 適用範囲の決定(全体/部分)→ ③ ユーザー設定との連動 → ④ アクセシビリティ(タップターゲット最小サイズ)

  • 密度をCSS変数またはJSオブジェクトで管理する--spacing-row-compact: 4px--spacing-row-default: 10px--spacing-row-comfortable: 16px のようにトークン化する。Tailwindの場合は密度をキーとするオブジェクトで全クラスを管理する
  • Compactでもタップターゲット最低44pxを確保する:行の見た目の高さがCompactで小さくなっても、クリック/タップ可能な領域は最低44×44pxを確保する。min-height: 44px をCSSで設定する
  • 密度設定をlocalStorageに保存する:ユーザーが設定した密度はページ遷移後・再読み込み後も維持されることを期待する。localStorage.setItem('ui-density', density) で永続化する
  • Compact時はセカンダリ情報を省略できる:Compactではメール・説明文などのサブテキストを非表示にしてスペースを節約する。ただし主要情報(名前・ステータス)は常に表示する

5. 状態設計(States)

密度段階行高さアバターサイズフォントサイズサブテキスト
Compact最小小(20px)xs (12px)非表示可
Default中間中(28px)sm (14px)表示
Comfortable最大大(36px)sm (14px)表示

6. バリエーション設計(Variants)

適用対象CompactDefaultComfortable
テーブル行py-1 px-2py-2.5 px-3py-4 px-4
リストアイテムp-2p-3p-5
カードp-2p-4p-6
アバターw-5 h-5w-7 h-7w-9 h-9

7. パターン集(Good / Bad / How to fix)

7.0 よく崩れる設計パターン(3つ)

  • 密度の値がコンポーネントにハードコードされているclassName="py-2.5" が各コンポーネントに直書きされており、Compact切り替え時に全ファイルを修正が必要になる
  • Compact時にタップターゲットが小さくなりすぎる:行の高さが py-1(約24px)になり、モバイルでタップしにくくなる
  • 密度設定がセッションをまたいでリセットされる:ページ遷移のたびに密度がDefaultに戻る

7.1 Bad(典型3つ)

  • テーブル行に className="py-2.5 px-3" とハードコードし、Compact用に全コンポーネントを別実装する
  • Compact時に行高さが16pxになりクリック領域が小さすぎてミスクリックが頻発する
  • 密度設定を useState のみで管理し、リロードするたびにDefaultに戻る

7.2 Good(対になる3つ)

  • const cfg = densityConfig[density] のようにオブジェクトで密度クラスを一元管理し、<td className={cfg.rowPy}> で適用する
  • Compact行に style={{ minHeight: '44px' }} を追加してを確保する
  • useEffect(() => { localStorage.setItem('ui-density', density); }, [density]) で密度設定を永続化する

7.3 How to fix(手順)

  1. 密度トークンをオブジェクト(またはCSS変数)として定義する
  2. 全コンポーネントのpaddingをトークン参照に置き換える
  3. localStorage での永続化を実装する
  4. Compact時の min-height: 44px を追加する

8. ルール(Must / Better)

Must(守らないと壊れる)

Better(品質が跳ねる)


9. アクセシビリティ要件(必須)

  • Compact時のインタラクティブ要素(ボタン・リンク・チェックボックス)は min-height: 44px; min-width: 44px を維持する
  • prefers-reduced-motion と同様に、prefers-density メディアクエリ(草案段階)の概念を意識して、OSのアクセシビリティ設定に応じたデフォルト密度を提供する

10. 実装メモ(Implementation Notes)

  • TailwindCSS の場合、密度ごとのクラスマップオブジェクトをコンポーネント外で定義し、density stateのキーで参照する実装が最もシンプル
  • shadcn/ui の Table コンポーネントは data-[slot=table-row] などのセレクタで行の密度をCSSで制御できる
  • デザイントークンとして CSS カスタムプロパティを使う場合::root[data-density="compact"] { --row-py: 4px; }:root[data-density="default"] { --row-py: 10px; } のように data- 属性で切り替える

11. 関連リンク


12. まとめ

Density Patternsの設計で最重要なのは「密度トークンの一元管理」です。個別コンポーネントにpx値をハードコードすると、密度切り替え機能の実装コストが指数的に増加します。密度をオブジェクトまたはCSS変数で定義し、コンポーネントはそれを参照するだけの構造にしてください。Compact時のタップターゲット44pxと密度設定の永続化は、実装漏れが多い箇所なので必ず確認してください。

更新のお知らせ

サイトに載せていない実例や、新しい記事のお知らせはこちらで出しています。

読んだ内容を、自分の画面に当てるとき

UIXHEROは、記事を書くほかに、画面の検品・判定、デザインシステムの構築、実装と改善の伴走を受けています。何を頼めばいいか決まっていない段階の相談も、同じ窓口で受けます。

UIXHEROに頼めることを見る

※ 記事の内容についての質問や、書いてほしいテーマの要望も同じ窓口で受けています

記事をシェア

メールでお知らせを受け取る

最終更新: 2026年9月3日

この記事を書いた人

Dengen Yosho(DGYS)

Dengen Yosho(DGYS)

UI/UXデザイナー兼デザインエンジニア デザイン歴25年以上 情報設計〜UIデザイン〜React/TypeScriptによる実装までを一気通貫で担当 大手企業のDXプロジェクトや決済アプリ領域で、デザインリードとして改善と構築を経験 現在はフリーランスとして、プロダクトのUI/UX改善とデザインシステム構築を支援 長年の実務の中で感じてきたのは、 「良いUI」はセンスではなく、再現可能な判断の積み重ねであるということ UIXHEROは、 心理学や行動科学の知見を、現場で使える設計言語に翻訳するための場所 関心領域は「ユーザーの行動が変わるUI」 人の認知・注意・意思決定の構造を理解し、 “なぜそのUIが機能するのか”を言語化することを目指している

あわせて読みたい

この記事に関連する記事をご紹介します

Bar Chart(棒グラフ)

カテゴリごとの量を棒の長さで比べるチャート。ゼロ基線の扱い、並び順、縦横の選び方、しきい値の見せ方という設計判断と、色だけに頼らないアクセシビリティ要件を解説する。

2026年8月27日
18

Donut Chart(ドーナツチャート)

中央をくり抜いた円で構成比を示すチャート。中央に置く値の選び方、円グラフとの使い分け、リングの太さ、凡例の作りという設計判断と、色だけに頼らないアクセシビリティ要件を解説する。

2026年8月27日
17

Gauge Chart(ゲージチャート)

1つの値を範囲の中に置いて示す半円のチャート。範囲の両端に意味があるかという条件、しきい値の帯の設計、色だけで良否を伝えない書き方という設計判断とアクセシビリティ要件を解説する。

2026年8月27日
16

もっと深く知りたいですか?

ここに掲載されていないトピックについても、リクエストがあれば解説記事を追加します。 わかりにくい点や、具体的な事例について知りたいことがあれば教えてください。

リクエストを送る