情報の多い一覧画面を整理するとき、文字を小さくしたり、余白を削ったりするだけでは限界があります。先に見直したいのは、どの情報を最初から見せ、どの情報を選択後に表示するかです。

結論は、最初の比較に必要な項目を残し、詳細や補助説明は目的に合わせて分けること。ただし、料金や参加条件など、判断に欠かせない情報まで閉じないようにします。

この記事では、2026年10月22日に公開されたFigmaのLufthansa Systems事例を入口に、架空の講座一覧を整理する方法を紹介します。活用事例の紹介にとどまらず、手元のデザインに使える表示条件の表と確認手順までまとめます。

情報確認日:2026年10月23日。 公式事例の紹介と、その応用としての制作提案を区別しています。講座一覧は架空の例で、実際のアプリ操作、利用者テスト、成果測定は行っていません。

情報が多いUIでは、最初に「比較に必要な項目」を決める

画面の密度は、文字の大きさや余白だけでは決まりません。候補ごとに必要な情報が違う場所へ散っていれば、見た目が簡潔でも比較には手間がかかります。

まず、「この一覧で何を決めるのか」を一つの行動にします。講座一覧なら「参加できる日時と予算の講座を探す」。商品一覧なら「用途と価格が合う候補を比べる」。この判断に必要な項目を、同じ位置に並べます。

次に、その判断にはまだ使わない情報を分けます。講師の詳しい経歴、制作の背景、追加の用語説明などは、候補を選んだ後や必要なときに読める形が考えられます。

ここでいう段階的開示は、必要に応じて情報を順に見せる設計です。情報を削除することや、すべてをアコーディオンへ入れることではありません。詳細ページ、選択時のパネル、補助説明の開閉など、内容に応じて方法を選びます。

同じ講座カードを比較。左は全情報を展開。右は日時・会場・料金・初心者向けの条件を一覧に残し、内容と講師経歴を後から読める入口に分けている。
同じ情報でも、最初に表示する範囲を分けられる。架空の講座一覧を使ったオリジナル概念図。優劣の実測を示すものではありません。

今週の事例:Figma Makeで地図の情報密度を確かめる

Figmaの10月22日付記事では、Lufthansa SystemsがFigma Makeで動的な地図の試作を作り、どの拡大率から交通情報を見せるかを検討した事例が紹介されています。機体を選んだ際の詳細表示も扱っています。Figma公式の事例紹介

参考になるのは、画面に置く項目の数だけでなく、拡大する・選ぶという操作と、表示する情報を対応させている点です。広く全体を見るときと、一つの対象を調べるときでは、必要な情報が変わります。

この事例から一般のWeb制作へ応用するなら、「最初は何を比べたいのか」「候補を選んだ後は何を知りたいのか」を分けて試すことができます。航空業務の設計をそのまま転用するのではなく、利用者と目的に合わせて整理し直す必要があります。

今週の公開記事と、以前からある機能を混同しない

情報 日付・位置づけ この記事での扱い
Lufthansa Systemsの活用事例 2026年10月22日掲載 今週公開された事例。Makeの新機能リリースではない
Make kits・Make attachments 2026年4月2日発表 文脈や資料を渡す既存機能の説明。今週初めて使えるようになったとは書かない
Details/Disclosureの設計・実装ガイド 既存の公開ガイド 表示を分ける際の判断材料。今週のトレンド発表ではない

Makeへの資料添付などは、4月2日のFigma公式発表で説明されています。今回の主題は新しいツールを導入することではなく、現在の画面で表示する条件を決めることです。

表示条件を3段階に分ける

架空の「週末ワークショップ一覧」で考えます。利用者は、日程と予算を見て参加候補を探している想定です。以下は汎用の正解ではなく、この目的に合わせた初期案です。

段階 ここで答える疑問 表示する情報の例
最初の一覧 参加候補になるか 講座名、制作するものの短い要約、日時、会場/オンライン、料金、受付状況、参加に必要な条件
候補を選んだ後 内容は自分に合うか 当日の進行、工程や完成例の詳細、詳しい会場案内
必要な人が開く補足 個別の疑問を解消できるか 講師の詳しい経歴、用語説明、補助資料

「料金」は、見た目を軽くするためだけに詳細の奥へ移しません。「初心者向け」の有無や対象年齢が参加の判断を左右するなら、それも一覧に残します。

会場の設備や利用上の条件が、その人の参加可否に関わる場合も同じです。一部の人だけに必要だからといって重要性が低いわけではありません。対象となる利用者と確認し、一覧での表示や分かりやすい入口を用意します。

講座情報を3段階に仮分類。最初の比較は日時・料金・場所・参加条件。選択後は当日の進行・詳しい案内。必要なときの補足は講師経歴・用語の説明。
表示の優先順位は、制作側が説明したい順ではなく、利用者が判断する順に仮置きする。

「情報・表示条件・残すもの」を表にする

整理した内容を、そのまま制作担当へ渡せる形にします。

情報 表示する条件 見出し・入口 画面が変わっても残したいもの
日時・料金・受付状況 一覧を表示した時点 各カード内の共通位置 項目の順序と単位
当日の進行 講座を選択したとき 「講座の内容を見る」 選択中の講座名
講師の詳しい経歴 補足を開いたとき 「講師の経歴を読む」 どの講座の補足か
一覧の絞り込み 詳細から一覧へ戻るとき 「一覧へ戻る」 日程・形式などの選択条件

「詳細を表示」とだけ書くより、何をしたら何が見えるかが明確になります。複数の項目を同時に変更する場合も、情報ごとの表示条件を追いやすくなります。

折りたたんでよい情報と、残すべき情報の境界

GOV.UK Design SystemのDetailsガイドは、一部の利用者が必要とする情報を必要時に見せる使い方を示し、多くの利用者に必要な情報を隠す用途には使わないよう案内しています。また、開く前に内容を予測できる、短く具体的な見出しを勧めています。GOV.UKのDetailsガイド

制作中に迷ったら、次の順番で確認します。

  1. この項目が見えなくても候補を選べるか。 選べないなら、一覧に残すか、容易に比較できる表示にする。
  2. ほぼ全員が開く必要があるか。 そうなら、閉じている意味を見直す。
  3. 一部の人には不可欠な条件か。 人数の少なさだけで奥へ移さず、発見できる入口と表示方法を確認する。
  4. 開く前に、中身が分かるか。 「もっと見る」だけに頼らず、「講師の経歴」「持ち物」など内容を示す。
  5. 閉じたままでも、次にできることが分かるか。 必要な行動まで隠していないかを見る。
最初の判断に必要かを分岐で考える図。必要な料金・日時・参加条件は一覧に残す。今は不要な講師経歴などの補足には、中身が分かる言葉で開く入口を付ける。
見た目を軽くすることと、必要な条件を隠すことを混同しない。

デザインを試すときは「行く・読む・戻る」を一組にする

詳細へ進めるだけでは、比較の作業を確認できません。一覧へ戻って、別の候補を選ぶところまで一組で考えます。

1.同じ内容で二つのラフを作る

一つは説明をすべて展開した版、もう一つは比較項目を残して詳細を分けた版です。講座名、料金、日程、件数はそろえます。表示条件以外を同時に変えすぎないためです。

これは利用者テストを行う前の制作比較です。見た目だけで、使いやすさや成果が改善したと結論づけないようにします。

2.内容が長い場合と、件数が増える場合を作る

短い見出しだけで成立していても、実際の文言ではカードの高さが変わることがあります。長い講座名、複数の開催日、長い会場名など、公開可能な架空データを用意します。

件数が増えた場合も、必要な情報を繰り返し開かないと比較できない設計になっていないかを見ます。件数や文字数に普遍的な正解を置かず、想定するデータに合わせて試します。

3.詳細から戻ったときの状態を確認する

選択した日付や開催形式、一覧内の位置がどうなるかを決めます。「戻る」ときに条件がすべて消えるなら、その理由があるのか、単に未設計なのかを分けます。

土日・会場開催で絞った講座一覧から、紙の小箱づくりの詳細へ移動。一覧へ戻った後も同じ絞り込みを残し、週末の写真散歩など別候補と比較する。未実施の確認案。
表示を分けるときは、候補を比べていた文脈も保つ。図は仕様を考えるための案で、自動的な状態保持を保証するものではありません。

4.スマートフォンとキーボードでも入口を探す

パソコンのマウス操作だけで確認すると、補足の入口がスマートフォンで目立たなくなったり、キーボードで操作できなかったりする問題を見落とします。

W3CのDisclosureパターンでは、開閉を行う要素をボタンとして扱い、開閉状態を伝え、フォーカス中のEnter/Spaceで切り替える設計を示しています。W3CのDisclosureパターン

実装では、この意味と状態が支援技術へ伝わるかも確認します。見た目だけに矢印を付けても、開閉の意味が伝わるとは限りません。なお、この項目を確認しただけでアクセシビリティ全体への適合を保証できるわけではありません。

確認課題は「すっきり見える?」より具体的にする

ラフを見せるときは、感想に加えて、やってほしいことを伝えます。たとえば次の三つです。

確認する行動 記録すること 問題があった場合の見直し先
同じ予算内の講座を二つ探す 料金の場所、何度詳細を開いたか、迷った言葉 一覧に残す項目と表示位置
気になる講師の経歴を読む 入口を見つけられたか、見出しから内容を予測できたか 補足の名前と入口
詳細から戻り、別の日程を選ぶ 何が保持され、何を選び直したか 戻り方と絞り込みの状態

この段階では、成功率や時間の短縮を仮の数値で埋めません。観察した事実と、まだ確認していない点を分けて残します。少人数での気づきが、そのまま全利用者に当てはまるとも限りません。

未記入の確認シート。予算内の講座を2つ探して料金の比べやすさを観察する。講師経歴を読んで補足の発見を観察する。一覧へ戻って別日程を選び、条件の残り方を観察する。全項目は未実施。
記入前の確認シート。図の「未実施」はテスト結果ではありません。

Figma Makeを使う場合の範囲と費用

今回の情報整理は、紙、表、普段のデザインツールだけでも始められます。表示条件を決めるために、新しいAI生成機能を使う必要はありません。

動く試作が必要なら、表示の切り替えと一覧への復帰だけを対象にする案が考えられます。架空データを使い、実際の申込みや決済、メール送信は接続しない状態で確認します。

Figma Makeで生成する場合、AIクレジットの消費は、モデル、指示の複雑さ、渡す文脈などで変わります。固定の消費量や無制限利用を前提にせず、利用中のプラン・残量・管理設定を確認してください。FigmaのAIクレジットガイド

本記事では、生成の実行や課金の検証を行っていません。機能の操作手順や費用の詳細よりも、試作に渡す表示条件を先に決めることを目的にしています。

よくある質問

段階的開示は、すべてアコーディオンにすること?

違います。候補を選んだ後の詳細ページ、選択中の対象の説明、必要な補助説明の開閉なども考えられます。情報の役割に合わせて選び、毎回開かないと比較できない構成を避けます。

スマートフォンなら、情報をもっと隠すべき?

画面の狭さだけでは決められません。料金や対象条件のように選択へ必要な情報は、スマートフォンでも必要です。配置、文言、情報の順序を見直し、それでも分ける場合は入口を見つけられるかを確認します。

AIが作ったUIなら、表示条件も自動で最適になる?

自動で適切になるとは限りません。どの人が何を判断するのか、どの項目を最初に見せるのかを指定し、生成後も確認します。この記事の三段階は、その判断を書き出すための初期案です。

今週、Figma Makeに新しい地図機能が出たの?

この記事で取り上げた10月22日付情報は、Lufthansa Systemsの活用事例です。地図専用の新機能が全ユーザーへ提供されたという発表としては扱っていません。

まとめ:情報の置き場所と、表示する条件を一緒に決める

情報が多い画面を整えるなら、最初に比較するための項目を残し、選択後の詳細と補助説明を分けてみましょう。大事な条件を隠していないか、戻ったときに比較を続けられるかも確認します。

まずはカード一つで十分です。各項目に「最初」「選択後」「補足」と書き、表示する条件を一行ずつ添える。その表があると、何を画面へ残し、どこを次の確認で見直すかが具体的になります。

関連:Figma Specs・Code Layersの新機能と、意図を共有する制作の流れ


本文図解5点は、架空の講座一覧を使うオリジナル概念図です。実在サービスの公式UI、実案件、実測結果を示すものではありません。