たかがカード、されどカード。AI時代に考える「体験の中核」を担うUI設計 #PERSOL CAREER Advent Calendar2025

はじめに
UIコンポーネントの「カード」とは？
- 体験設計におけるカードの重要性
カード設計が難しい！3つのポイント
対応すべきコンテンツ種別が1つだけとは限らない
- 詳細ページが鍵を握っている
「3つのポイント」に対する打開策
AIにカードの設計は可能か？
AI時代における人/デザイナーの介在価値
おわりに

はじめに

もうすぐクリスマス！こんにちは、UI/UXデザイナーの松森です。

ついこの間2025年になったと思いきや、気づけばもう年の瀬です。

今年はどんなことをしていたっけな？と振り返ると、いろいろと頭を駆け巡るわけですが、今年は大きく2つのプロダクトに関わりました。

1つは写真を管理するサイト。もう1つは記事や動画などを閲覧できる、いわゆるメディアサイト。

この2つのプロダクトのUI/UX設計に携わらせていただいて、改めて痛感したことがあります。

それは、UIコンポーネントにおける「カード」の重要性と難しさです。

「え、カード？基本中の基本じゃない？」と思われるかもしれませんが、この記事では、AIがUIを生成する時代だからこそ際立つ「カードを作る上での勘所」について、今年の実践を通してまとめていこうと思います。

UIコンポーネントの「カード」とは？

まず前提として、UIコンポーネントの「カード」とは何か。デジタル庁のデザインシステムでは下記のように定義されています。

カードは、単一の主題に関するコンテンツをまとめて表示するコンテナとなるコンポーネントです。さまざまなタイプとサイズの要素やコンポーネント、アクション等を柔軟に格納できます。

デジタル庁デザインシステム - カード

ただ、今回僕が取り上げたい「カード」は、もう少し踏み込んだ定義になります。

正確に言うと「コレクションページにおいて、メインオブジェクトを扱う、体験の中核を担うコンポーネント」です。（リストアイテムなども機能的には近いですが、今回は代表格として「カード」に限定して話を進めます）

体験設計におけるカードの重要性

「コレクションページにおいて、メインオブジェクトを扱う……」少し専門的な言い回し（OOUI的な表現）になってしまったので、噛み砕くと以下のような利用シーンを想定しています。

メディアサイトの記事一覧ページで、「どの記事を読もうかな？」と選んでいるシーン
写真管理サイトの写真一覧ページで、「どの写真を見ようかな？」と選んでいるシーン

「コレクションページ」は「一覧ページ」を指し、「メインオブジェクト」は「記事」や「写真」そのものを指します。

こういった一覧ページでのユーザーの目的は「自分が求めているコンテンツを探し出し、見つけること」。そして、このページでのカードは、ユーザー体験における「What（何を）」の選択を一手に引き受けています。

そのため、カードを設計する際は、必然的に以下のような問いと向き合うことになります。

ユーザーは、目的のコンテンツを探す上で、どういった情報が掲載されていれば選定できるか？
ユーザーは、目的のコンテンツを見つけてから、次にどんなアクションを行いたいか？

カード設計が難しい！3つのポイント

カードのデザインが難しい理由は「あちらを立てればこちらが立たず」というトレードオフのバランス調整が極めてシビアだからです。僕は主に、以下3つの要素で感じています。

1. 情報の網羅性 vs 視認性

前提として「カードは詳細ページのサマリー」です。情報の全容を載せてしまっては一覧性が損なわれるため、情報を抜粋し、端的に「選ぶために必要な情報」だけに絞らなければなりません。この「何を削るか」の判断が非常に難しい！

2. アクションの利便性 vs 複雑性

「お気に入り」や「カートに入れる」など、カードから直接アクションが行えると体験は向上します。しかし、欲張って機能を詰め込むとカード自体が操作パネルのように複雑化し、本来の「選ぶ」という目的を阻害します。「この一覧で即座に行えるべきアクションは何か？」の厳選が必要です。

3. サイズの制約 vs 情報量

カード1枚のサイズを大きくすれば情報量は増やせますが、画面内の一覧性は下がります。逆に小さくすれば一覧性は上がりますが、情報は削ぎ落とされます。

「表示する情報」「行えるアクション」「サイズ的制約」

これら3つの要件が複雑に絡み合うため、カードは基本的なコンポーネントでありながら、設計難易度の高いコンポーネントになりやすいです。

対応すべきコンテンツ種別が1つだけとは限らない

カードが扱うコンテンツ種別は1つとは限りません。複数の種別（記事、動画、商品など）を扱いながらも、それらを一定のルールに則ったレイアウトで統一して見せることが、UX的に最善であるケースも多いです。なぜなら、コンテンツ種別ごとにカードのレイアウトがコロコロ変わると、ユーザーはその都度情報の見方を学習しなければならないからです。

つまり、異なるコンテンツ種別であっても共通の情報項目を見つけ出し、一定のレイアウトでカードを構成することが求められます。

詳細ページが鍵を握っている

各コンテンツで保有している情報の最大値は詳細ページが受け止めることになるため、詳細ページのレイアウトがドラスティックに変化するのは致し方ないことです。

そして「カードは詳細ページのサマリー」である以上、カードの設計にも大きく影響を及ぼすのも・・・致し方ない。

複数種別のコンテンツを取り扱う場合は、まず詳細ページの情報設計に着目し、共通項目と固有項目を整理した上で以下のようなフローで進めていくと手戻りが少ないはずです。

詳細ページ（情報の全量） → カード（情報の抜粋） → 一覧ページ（情報の集合）

まとめると、各コンテンツ種別で以下のような影響が考えられ、これらの影響は先程触れた「カード設計における3つの難所」に降り掛かってくることになります。

詳細ページで保有する情報内容　→　カードで表示する情報
詳細ページで行えるアクションとその優先度　→　カードで行えるアクション
一覧ページで選定する上での理想的な体験　→　カードのサイズ的制約

「3つのポイント」に対する打開策

【体験設計】カードのHoverを駆使する

デスクトップに特化したプロダクトに限定されてしまいますが、Hoverを駆使するというアイデアもあります。カード全体に対するHoverとDefault状態で、ユーザーニーズを分解、整理して、カードの情報を出し分ける方法です。

Default状態： アクションのスペースを切り捨てて情報表示に振り切る。
Hover状態： ユーザーがカード上にカーソルを乗せている時点で、コンテンツ選定を既に行い次のアクションを行おうとしていると仮定して、カードから直接行えるアクションを表示する。

このような処理を施し、情報の網羅性とアクションの利便性を担保することもできます。懸念点としては、アクセシビリティ観点でお手本的な手法ではなく、Hover挙動が複雑になるので、ユーザーに受け入れてもらえるかちゃんとユーザビリティテストを実施することをおすすめします。

【体験設計】詳細ページの閲覧体験を工夫する

こちらもデスクトップに特化したプロダクトだからできる方法ではありますが、詳細ページの閲覧を極力サクッと見れるような体験にして、なるべく詳細ページで情報閲覧とアクションを行ってもらうアプローチです。

スプリットビュー： GitHubのProjectやZenhubのように、画面を二分割し一覧ページと詳細ページを同時に表示してしまう形式。
モーダルウィンドウ： 現在の画面の上に重ねて表示され、特定の操作（確認、入力など）を完了させるまで背景の操作を一時的にブロックする小さなウィンドウが出る形式。

「どっしりと詳細ページを読みたいのか」「サクサクと詳細ページで情報を編集したいのか」「そもそも一覧と詳細での行き来にどこまでニーズがあるのか」などのユーザーニーズによって、最適解は変わります。

そして先程述べた通り、詳細ページの情報設計がカード設計にも大きく影響を及ぼすので、各コンテンツ種別での「共通の項目と固有の項目を整理」をしっかり整理し、学習コストの低いプロダクトを目指しましょう。

【運用/管理】一難去ってまた一難。Figmaでの運用

様々なコンテンツ種別、それに応じた情報とアクションに対応しつつ、一定のレイアウトで整理仕切らなければならないカードはFigma上でもバリアブルが複雑になりがちです。

サービスのメインオブジェクトを司るコンポーネントですから、追加機能なんて話も頻繁に降り掛かってきても不思議じゃないです。

個人的にFigmaの理想系は以下と考えています。

見たり触ったりすれば、プロダクトの大枠の仕様が理解できること。
Figmaの内容が属人化しておらず、第三者が触ってもスッと画面が作れること。

この理想を追い求めて、複雑化したカードをFigmaで表現しきることを試みましたが、結果として膨大な分岐を持つ「メンテナンス不能なコンポーネント」が出来上がりそうになり、方針を切り替えました。

どこまでをFigmaで担保し、どこまでを運用で担うのか？

大枠は以下のような線引きで捉えています。

情報の受け皿となるフレーム＝システムとしてあるべき状態をFigmaで表現
「その受け皿にどのような情報を載せるか」は運用ルールとして、別でドキュメント化

具体的にいうと、コンテンツ種別独自の挙動はFigmaでのバリアブルでは扱わず、カードとしてコンテンツ全種別共通の挙動はバリアブルで表すようにしました。

逆にいうと、ラベルの文言変更等で済むような範囲でしかコンテンツ独自の変更点はないように設計しました。

ここで重要なのが、こういったFigmaでは表現しきれない仕様みたいなものは積極的にドキュメント化し、人もAIも理解できる状態を目指すことかなと思います。

AIにカードの設計は可能か？

昨今、AIによるUI生成やデザインシステムの普及により、標準的なコンポーネントを並べるだけの業務であれば、AIに任せられるようになってきました。

しかし、今回触れたような「カード」の設計は、AIにはまだ荷が重い領域ではないかと感じています。なぜなら、カードの中身には「サービスの独自の文脈」と「ユーザーの意思決定条件」など膨大な背景情報やコンテキストをすべてプロンプトで説明せねばならず、現時点では実用的とは言えません。

しかし、カードはユーザー体験の品質を大きく左右し影響範囲は甚大でありながら、これまで述べてきた通り、一筋縄ではいかない複雑な設計バランスが求められます。

じゃあカードのような重要なコンポーネントは今後もずっと人間が設計していくべきか？と言われるとそうではないと思っています。この記事のように要件や勘所を言語化し整理することで、AIがそれを参考にカードコンポーネントを生成できる糸口になる可能性があるかも？と期待してたりしています。

AI時代における人/デザイナーの介在価値

AIの登場以来、各業界で「人の介在価値」が問われていますが、UIデザインの特にこのような中核部分においては、実は膨大なコンテキストを含んだ上でデザイナーがアウトプットを行っています。この膨大なコンテキストを整理し、言語化してAIにお願いするよりかは、現状まだ人の手で作ったほうが早いんじゃないかなと思います。

ですが、今正解だと思っているUIに至るまでに、大量の分岐点があったことも否定できません。人間より何百倍早く作業をこなせるAIがいれば、これらの可能性をすべて試し、最適解を探ることも今後はできるようになるかもしれません。

AIが人の道具である以上、根源的な何かのキッカケとなる「動機」を作り出せるのは人にしかできないことです。

人が「やりたい！」と思えばAIがそれを拡張し実現してくれることが確約された世界に突入した以上、悲観的になっていたら損かもしれないですね。

デザイナーは理想を追い求めてることがある種ミッションでもある職業です。たくさんわがままを言って、AIを困らせましょう。