一覧を表にするかカードにするかは、見た目の好みだけでは決まりません。同じ項目を横断して比較するのか、一つずつ概要を読んで選ぶのかを、実際の作業から確かめます。
管理画面や情報一覧を設計する人に向け、架空の社内研修サービスで考えます。ここでの選択は設計案です。カードや表のほうが常に速いと主張するものではありません。
一覧で答えたい問いを書き出す
同じ研修でも、担当者と参加者で探し方が違います。担当者は「定員に対して申込が少ない研修」を見つけたいかもしれません。参加者は「自分の業務に役立つ内容か」を判断したいかもしれません。
| 一覧で行う作業 | 最初に試す形式 | 残したい情報 |
|---|---|---|
| 定員と申込数を複数研修で比較する | 表 | 研修名、開催日、定員、申込数 |
| 内容の違いを読み、受講候補を探す | カードまたは説明付きリスト | 研修名、概要、対象者、開催日 |
| 名前が分かる研修を開く | 簡潔なリスト | 研修名、識別に必要な補足 |
| 同じ条件の研修をまとめて処理する | 選択操作付きの表 | 対象の識別情報、処理に必要な状態 |
表は数値だけのものではありません。共通項目を揃えて確認する用途にも使えます。逆に、情報が2項目しかない一覧を、余白の多いカードへ広げる必要があるかは検討できます。
共通項目を比べる表
Carbonは、データの整理・表示、行の選択、一括操作などをデータテーブルの用途として扱っています。Data table
この作例の運営一覧では、研修名・開催日・定員・申込数・受付状態を列にします。長い研修説明は詳細へ移し、一覧で必要な比較を優先します。申込数が空欄なら「0人」なのか「未取得」なのかも決めます。異なる意味を同じダッシュだけで表さない案にします。
列を増やす前には、その列を見て何を判断するかを担当者に確かめます。「あれば便利」な項目を全部並べると、確認したい列が遠く離れることがあります。重要列を残し、補助情報を詳細へ移す試作を比較します。
概要を読んで選ぶカード
USWDSはカードを、記事など関連する内容の集合に使うと説明し、表の行の代用にはしない方針を示しています。各カードから詳細へ進めることや、同じ画像・内容を繰り返さないことも勧めています。Card
参加者向けの作例では、「何を学べるか」を2文程度で書き、対象者と開催日を添えます。すべてのカードに同じ装飾写真を載せるより、研修の違いを判断できる説明へ場所を使う案です。
カード全体を押せるようにする場合も、内部にある「お気に入り」など別操作との関係を決めます。この例では、まず研修名を詳細へのリンクにし、お気に入りを独立したボタンにします。どこを押すと何が起きるか、キーボードでも同じ操作へ到達できるかを確かめます。
狭い画面で、自動的にカードへ変えない
表を縦積みへ変えると、一つの研修の情報はまとまりますが、申込数を研修間で比較するには上下に探す作業が生まれます。小さい画面だからカード、とは決めず、比較という目的が残っているかを見ます。
この例では、運営一覧は横スクロールできる表を候補にし、研修名と数値の対応が追えるか試します。参加者向けはカードを1列にします。同じデータでも、二つの利用場面に同じ見せ方を強制しない案です。横スクロールが見つからない、文字を拡大すると操作が隠れる、といった問題が出れば、表示列の削減などを再検討します。
形式を比べる短いレビュー
実際のデータに近い長い名前、未設定値、多い件数を入れます。そのうえで「申込数が最も少ない研修を探す」「対象者の条件から一つ選ぶ」「名前が分かる研修を開く」という課題を試します。
迷った場所と理由を記録し、表とカードを比較します。少人数のレビューから全利用者の速度向上率を推定する必要はありません。項目間の比較で迷ったのか、説明が不足したのかを分ければ、次に直す部分が明確になります。読み上げ時には、表の見出しとセルの関係、カードの見出し順、リンク名で移動先を区別できるかも確認します。
並び順を加える場合は一覧の並び替え、条件を絞る場合は検索の絞り込みと解除へ進めます。