UIデザインでカードとリストを使い分ける方法

個々の項目を見分けながら探したいときにはカードを選びます。同じ属性を順に確認する、すでに知っている項目を見つける、決まった順序で作業するときにはリストを選びます。複数のレコードにまたがって多くの値を比較するなら、テーブルのほうが実態に合うかもしれません。

UIでカードとリストを選ぶ際は、ここから考えると役立ちます。画像の多いプロダクトは必ずカード、業務アプリは必ず行、と決まっているわけではありません。同じコレクションでも複数の作業に使われます。今の画面がどの作業をしやすくするべきかによって、適切なレイアウトは変わります。

Webサイトのプロジェクトが集まるライブラリを考えてみましょう。デザインの方向性を探すデザイナーなら、サムネイルで目的に合うプロジェクトを見分けられるかもしれません。期限を過ぎたレビューを探すプロジェクトマネージャーには、担当者、ステータス、期限が必要です。同じデータを見ていても、答えたい問いが違います。カードの角丸を変えても、この違いは解消しません。

何を探しているのかを明らかにする

コンポーネントではなく、行動から考えましょう。「プロジェクトを見る」では、分からないことが多すぎます。「宿泊業のクライアントに合うビジュアルのプロジェクトを探す」と「今日がレビュー期限の項目を探す」なら、情報の優先順位が変わり、レイアウトを評価する基準も得られます。

前者では、特徴を見分けられるプレビューが役立ちます。タイトルを大きくするだけでは、写真中心なのか、抑制の利いたタイポグラフィなのか、色鮮やかなイラストなのかは分からないかもしれません。後者では、日付とステータスを毎回同じ位置で確認できることが重要です。装飾的なサムネイルは、判断を助けずに場所を取るだけになる可能性があります。

最初に使われそうな手がかりを書き出します。画像、名前、カテゴリ、担当者、日付などが考えられます。次に、候補が合っているかを確認する二つ目の手がかりを特定します。どちらも項目を開かずに見えるべきです。候補を識別するだけで一つずつ開く必要があるなら、一覧画面の役割が足りていません。

Nielsen Norman Groupのカードに関する解説では、異なる種類の内容をまとめられるカードの特徴と、リストの予測しやすい読み取り順序が区別されています。カードは場所を取り、順位も伝わりにくくなると指摘されています。どちらかが常に優れていると考えるのではなく、検討するべきトレードオフとして扱いましょう。Nielsen Norman GroupによるUIカードの解説。

Pinterestと視線追跡の例が示す、それぞれの負担

NN/Gのカードに関する記事に掲載されたPinterestの画面では、画像、タイトル、補足情報が、高さの異なるコンテナにまとまっています。画像が識別の手がかりとなり、項目ごとの情報量も異なるコレクションに合う形式です。以下は、その当時の画面を記録したスクリーンショットです。

同じ記事には、カード形式の画面から興味のある記事を探した参加者の視線追跡も掲載されています。視線の軌跡を見ると、候補間を何度も行き来しています。NN/Gはこの動きを、明確な順位の順序がなく、比較する情報の位置も揃っていないレイアウトと結びつけています。

この二つの例では、求められる作業が違います。気に入る画像を選ぶなら、探し回ること自体が作業の一部です。担当者が直近の期限超過レコードを探すなら、カードごとに日付の位置を探す時間は余計な負担です。どちらも「閲覧」と呼んでしまうと、レイアウトを決めるべき違いが見えなくなります。

見た目を評価する前に、情報を試してみましょう。提案したグリッドのサムネイルを隠します。主な作業ができなくなるなら、画像は必要な判断材料を担っているのでしょう。日付やステータスが目立つようになって作業が簡単になるなら、画像は作業の邪魔をしているかもしれません。

項目を開く前に、何が見えている必要があるかを決める

案を比べるときは、同じレコード、フィルター、操作を使います。一人には期限を過ぎた項目を探してもらい、別の人にはビジュアルの方向性を見分けてもらいましょう。先に見せるレイアウトを入れ替えます。誤った選択、不要な詳細ページへの移動、戻ったときに見ていた位置を見失うことを記録します。きれいな画面のほうが好きという声は、見た目への有用なフィードバックですが、どちらがタスクを支えるかへの答えにはなりません。

入れ物を選ぶ前に、内容を読む

実際のレコードを少し取り出します。扱いにくい例も含めましょう。このプロジェクトライブラリなら、短いタイトル、長いタイトル、サムネイルの欠落、アーカイブ済み、担当者なし、といった項目です。同じ形の仮の四角形を敷き詰めた画面より、実際の内容のほうが、適切なレイアウトを教えてくれます。

内容のばらつきが大きいコレクションでは、それぞれを一つのまとまりとして要約できるカードが適しているかもしれません。すべての項目が同じフィールドを繰り返すコレクションなら、リストを選ぶ理由が強くなります。どちらも、それだけで結論は出ませんが、デザインが何を受け止める必要があるかは分かります。

画像がない状態には、とくに注意します。大半のレコードに意味のある画像がないなら、カードグリッドは同じ代替画像が並ぶギャラリーになりがちです。見た目で識別するレイアウトを見せているのに、中身は文字から探すための情報です。装飾で変化を作るより、文字中心のリストや、必要なときだけ小さく表示するサムネイルを検討しましょう。

逆に、ビジュアルのポートフォリオをファイル名だけのリストにすると、必要な情報を失うかもしれません。「Project 14」「Project 15」は正しい名前でも、見分ける手がかりとしては弱いものです。画面内に収まる行数を増やすより、役立つプレビューを加えるほうが重要な場合があります。

具体例：一つのライブラリ、二つの初期表示

架空の六つのプロジェクトを考えます。Cedar Lodge、Harbor Rooms、Studio North、Maple Clinic、Archive House、Lumen Shopです。すべてにサムネイル、担当者、レビューのステータス、レビュー期限があります。表示を変えても、これらの情報自体は変わりません。

ビジュアルを探す画面なら、サムネイルを大きく見せ、そのすぐ下にプロジェクト名を置きます。短いカテゴリと控えめなステータスラベルを加えます。連絡先の判断に役立つなら、担当者は目立ちすぎない形で見せてもよいでしょう。データが存在するというだけで、プロジェクトのメタデータをすべて詰め込む必要はありません。

レビュー管理なら、コンパクトな行から始めます。先頭にプロジェクト名と、必要なら小さなサムネイルを置き、ステータスとレビュー期限は一定の位置に並べます。レビューを開くなどの具体的な操作を見せてもよいでしょう。この場面では、デザインの雰囲気を語る装飾的な説明の優先度は低くなります。

二つの表示で、まったく同じフィールドを見せる必要はありません。ただし、同じ対象を一貫して表す必要はあります。片方の表示では「Ready for review」、もう片方では「Pending」となっていれば、表示の切り替えでプロジェクトの状態まで変わったのかと疑われるかもしれません。

初期表示は、その画面の主な目的に合わせます。発見を促すページはカードから始められます。レビュー待ちの作業一覧は行から始められます。切り替えを用意しても、適切な初期表示を選ぶ責任はなくなりません。多くの人は最初に出てきた表示をそのまま使います。

それぞれの表示を、目的に合うものにする

カード：内部の読む順序を明確にする

カードにも読む順序が必要です。どの要素で項目を識別し、どの要素で説明し、どこから行動するのかを決めます。サムネイル、タイトル、バッジ、作成者、タグ一覧、ボタンが同じくらい注目を求めると、役立つ要約ではなく、小さなダッシュボードになってしまいます。

プロジェクトライブラリの探索用表示では、サムネイルとタイトルで項目を識別します。カテゴリは内容の理解を助けます。ステータスと担当者は補足情報です。すべてのフィールドに違う色を付けなくても、大きさ、太さ、近さ、表現を抑えることによって、この順序を示せます。

比較する情報は、比較しやすい位置に置きます。カードが探索を目的にしていても、複数の候補について同じ詳細を確認する人はいます。ステータスは同じ領域に置き、ラベルの形式も揃えましょう。重要なメタデータの位置が予測できなくなるくらいなら、説明文を少し短くするほうがよいこともあります。

画像には、その面積に見合う役割を持たせます。レイアウトが分からないほど小さなスクリーンショットは、画像がない場合より有用とは限りません。識別の決め手になる部分を切り出し、適切なら縦横比を揃えます。ばらばらな切り抜きが混在し、プロジェクトそのものよりグリッドのほうが騒がしく見える状態は避けましょう。

画像がない場合も、想定する状態に含めます。タイトルとカテゴリで項目を識別できる、控えめな代替表示を使います。画像のない項目がコレクションの中で最も目立つような代替表示にしないでください。

カードには境界も必要ですが、すべてに太い枠線や深い影が必要とは限りません。目的は、情報がどの項目に属するかを示すことです。装飾を増やす前に、間隔と控えめな面の処理で実現してみましょう。一枚ではよく見える処理も二十枚並ぶとくどくなるので、コレクション全体で確認します。

リスト：安定して情報を追えるようにする

行ごとに構造を変えると、リストの利点は簡単に失われます。識別に使う内容は一定の位置に置き、補足フィールドの順序を決めます。下へ読み進めるたびに、行の読み方を覚え直す必要があってはいけません。

レビュー待ちの一覧なら、先頭はプロジェクト名にします。ステータスと期限は繰り返し見つけやすい位置に置きます。期限順に並べるなら、その期限も見せます。非表示のフィールドで並べ替えると、読者は見えない規則を探すことになります。

密度は、読むことと操作することについての判断です。画面に最も多くのレコードを詰め込む競争ではありません。名前を区別でき、操作要素も無理なく使えるだけの余裕が必要です。密度を上げて担当者とステータスが一本の灰色の線のように見えるなら、表示件数が増えても役に立たないかもしれません。

二行目は、役割を持たせて使います。短い説明や、ワークスペース名などの識別に役立つ情報を載せられます。タイトルを別の言葉で繰り返すのは避けましょう。「Cedar Lodge website」の下に「Website project for Cedar Lodge」とあっても、長くなるわりに識別には役立ちません。

リストにも画像を入れられます。意味のある小さなサムネイルなら、予測しやすい行構造を保ちながらレコードの認識を助けられます。問うべきは、画像を入れてよいかではなく、画像が項目の大部分を占める必要があるかです。

行に複数の整列したフィールドが増え、それらを利用者が積極的に比較するなら、すでにテーブルを設計しているのかもしれません。それは失敗ではありません。テーブルなら、関係を見出しで明示し、比較をより直接的に支援できます。リストと呼んでも、列同士の関係が消えるわけではありません。

全面をクリック可能にする前に、クリックの意味を決める

カードでは、項目を開く、メニューを出す、お気に入りに入れる、カテゴリのリンクを開く、といった操作が可能です。操作を増やすほど、表面の振る舞いは複雑になります。画像、タイトル、余白、補助的な操作要素を選ぶと何が起きるのか、説明できる必要があります。

主な移動先は一つ、明確に定めます。タイトルはプロジェクトを開き、サムネイルは画像ビューアーを開くなら、その違いに理由があり、操作の手がかりとして分かる必要があります。そうでなければ、見た目ではつながった要素が、無関係なリンクのように動作します。名前と背景で別の画面へ移動する行でも、同じ問題が起こります。

W3Cのデザインシステムには、個別のリンクを持つカードと、表面全体をリンクにするカードの両方が記載され、見出しレベルを周囲のページに合わせる必要も示されています。カードという見た目に、ただ一つの必須の操作モデルがあるわけではないことを思い出させてくれます。W3Cのカードコンポーネントのパターン。

プロジェクトの例なら、リンクになったタイトルと独立したメニューから始めると分かりやすいでしょう。実装で主なクリック領域を広げる場合は、メニューを独立して操作でき、必要なら文字も選択できるかを確認します。リンクを入れ子にしたり、すべての短い文章を別々のキーボードの停止先にしたりしないでください。

選択と、項目を開くことは別です。 複数のプロジェクトを選んで操作する人には、目に見える選択状態と、それを解除する明確な方法が必要です。明示的なモード変更もなく、ある表示では最初のクリックが選択、別の表示では項目を開く操作になるようにしてはいけません。表示の切り替えは見せ方を変えるもので、基本的な振る舞いを黙って変えるものではありません。

ポインター操作とともに、キーボードでの期待する動作も書き出します。フォーカスはどこへ進むのか。どの要素で項目が開くのか。補助メニューにはどう到達するのか。スクリーンショットには答えられないので、見た目の階層が明確なら操作の構造も明確なはず、と考えず、操作レビューに含めます。

両方に役割がある場合だけ、表示切り替えを用意する

同じ利用者が、見た目で識別する作業と、情報を順に確認する作業を実際に行き来するなら、カードとリストの切り替えには価値があります。一方がもう片方の劣化版にすぎないなら、得るものは多くありません。二つの表示に対応すると、気を配る内容の状態や操作の詳細も二倍になります。

切り替えを用意するなら、フィルター、並べ替え、対象のコレクションを維持します。 レビュー待ちのプロジェクトだけに絞った人が、リスト表示に変えた途端に全プロジェクトへ戻されてはいけません。変えるのは結果の表し方であって、今の条件に合う結果そのものではありません。

意味のある場合は、選択状態も保ち、制限があれば明確にします。一括操作がリスト表示にしかないなら、何も言わず選択を捨てるのではなく、その旨を説明します。できれば、どちらでも一貫して操作できないか検討しましょう。

ラベルと、選択中と分かる状態を持つ操作要素を使います。グリッドと行のアイコンは役立ちますが、形だけですべてのレイアウトを説明できるわけではありません。「カード」「リスト」のような短いラベルがあると、選択肢が分かりやすくなります。狭い画面で二つのレイアウトが似る場合には、とくに効果的です。

再訪する人のことも考えます。実装したプロダクトで表示の好みを記憶するのは便利かもしれませんが、作業が変わる場面まで上書きするべきではありません。レビュー待ちの作業一覧と、一般公開の参考作品ギャラリーが、一つの全体設定を共有する必要はないでしょう。保存が成り行きの動作にならないよう、適用する範囲を決めます。

狭い画面でも、作業を成り立たせる

スマートフォンでは、グリッドが一列になることがよくあります。ただ、それだけで使いやすいリストになるわけではありません。カードの画像が画面の大半を占め、作業に必要な情報がずっと下にあるかもしれません。レイアウトが変わったら、情報の優先順位も確認します。

探索用の表示なら、大きなプレビューが引き続き適しているかもしれません。レビュー待ちの一覧なら、読みやすい日付付きのコンパクトな要約のほうが役立つでしょう。デスクトップで右端の列に置いていたという理由だけで、判断の決め手になる情報を隠してはいけません。

補助フィールドは、順序を決めて折り返すか二行目へ移します。場所を節約するためだけに、ステータスを説明のない色付きの点に変えてはいけません。展開しないと見えない場所に移す必要があるなら、すべての項目を開かなくても主な作業ができるかを判断します。

長い名前は、問題を明らかにしやすいものです。最初の言葉が共通で、末尾近くが異なる、現実的な二つのプロジェクト名を使ってみましょう。省略されてどちらも同じ文字列になったら、狭い画面ではレコードを識別する力が失われています。文字を小さくする前に、折り返し、利用できる幅、見せる識別情報を調整します。

操作領域は別途確認します。幅の広い行では使いやすいメニューボタンも、タイトルやチェックボックスに押されて窮屈になるかもしれません。小さな操作要素が三つあるカードは、幅が減るととくに扱いづらくなります。作業が簡単になるなら、任意の操作を表面から外しつつ、そこへたどり着く明確な道筋を残します。

実際に探すタスクで、リスト表示とグリッド表示を比べる

どちらのレイアウトが好みかだけを聞いてはいけません。答えを観察できるタスクを渡しましょう。プロジェクトライブラリなら、ビジュアル探索では抑制の利いた宿泊施設向けの方向性のプロジェクトを探してもらえます。既知の項目を探すタスクならArchive Houseを指定します。管理目的の確認なら、特定の担当者に割り当てられた、最も期限の早いレビューを探してもらいます。

両方のレイアウトで、同等の内容を使います。 片方だけサムネイルがよい、文章が短い、フィルターが便利なら、レイアウト以外も比較しています。そうした改善にも価値はありますが、カードやリストが本質的に優れている根拠と取り違えてはいけません。

どこで迷うかを観察します。表示されていないステータスを知るために何度も項目を開くなら、内容の問題です。詳細から戻ったときに位置を見失うなら、ナビゲーションの問題です。グリッドの二行目が見落とされるなら、視覚的な順序の問題かもしれません。それぞれ、必要な変更は異なります。

自分が好むデザインに不利なタスクも含めましょう。カードが好みなら、同じフィールドを何度も確認する作業を試します。リストが好みなら、似た名前の項目から見た目で識別する作業を試します。最初のモックアップへの賛成を集めるのではなく、その選択の負担を明らかにし、受け入れられるかを判断するためです。

OpenDesignでは、HTMLのレイアウト案を作成してレビューし、ビューポートのプリセットで見た目の変化を確かめ、特定のカードや行にコメントを付けられます。修正の基準がぶれないよう、レコードと要件をデザインの文脈に残しましょう。検索、保存した設定、選択状態の維持は、実装した操作の流れの中でテストします。