比較とマトリックスシステム は何をしますか?
目的
比較とマトリックスシステムは、詳細な発見および評価インターフェースを設計するための方法論を提供します。pricing-table-ui-systemがハイレベルなプラン階層を扱い、data-table-ui-systemが大規模データセットを管理するのに対し、このシステムは少数の特定アイテム(通常2~5個)の属性密集型比較に焦点を当てています。これにより、ユーザーは多数の次元にわたって複雑な製品やサービスを評価する際に、位置を見失ったり、データに圧倒されたり、レスポンシブでないレイアウトに悩まされることなく、評価を進められます。
ユースケース
- Eコマース製品比較: 電子機器、家電、車両の技術仕様比較。
- SaaS機能マトリックス: ハイレベルな価格カードを超えた、プラットフォーム機能の詳細な内訳。
- サービス比較: 異なる保険プラン、旅行パッケージ、教育コースの評価。
- 内部ツール: 異なるシステムバージョンや設定の横並び監査。
使用すべきでない場合
- ハイレベルな価格比較: シンプルな3段階サブスクリプション概要には、
pricing-table-ui-systemを使用してください。 - 大規模データセットの探索: ユーザーが何百ものアイテムを並べ替えたりフィルタリングしたりする必要がある場合は、
data-table-ui-systemを使用してください。 - 単一アイテムの詳細: 個別の製品ページには、
article-layout-systemまたはcard-ui-systemを使用してください。 - 線形進行: 段階的なフローには、
step-progress-systemを使用してください。
入力
- 比較セット: 評価のために選択された2~5個のアイテム。
- 属性分類体系: 比較されるすべての機能、仕様、データポイントのカテゴリ化されたリスト。
- データタイプ: UIタイプ(例:ブール値/チェックマーク、数値、評価、テキスト説明)への属性のマッピング。
- 選択のコンテキスト: これは永続的なページですか、それとも製品一覧ページからトリガーされる一時的なオーバーレイですか?
出力
- マトリックス構造仕様: 行ヘッダー(属性)、列ヘッダー(アイテム)、データセルの定義。
- カテゴリ化フレームワーク: 属性を論理的なセクションにグループ化し、折りたたみ可能なヘッダーを付けるためのルール。
- スティッキーナビゲーションプラン: 縦方向および横方向のスクロール中にコンテキストを維持するための動作ルール。
- レスポンシブ遷移マップ: マトリックスをモバイル向けに適応させる戦略(例:アイテムスワッピング vs 縦積み)。
ワークフロー
1. グリッドフレームワークの構造化
マトリックスの主軸を定義します。
- 列: 比較されるアイテムを表します。
- 行: 属性または機能を表します。
- 先頭列: 左端の最初の列には属性ラベル/ヘッダーが含まれます。
2. 属性のカテゴリ化とグループ化
「比較疲れ」を防ぐため、行を論理的なクラスターに整理します。
- セクション: 関連する属性をグループ化します(例:「パフォーマンス」「接続性」「保証」)。
- 折りたたみ可能性: ユーザーが特定の基準に集中できるように、セクションの折りたたみ/展開を許可します。
- 視覚的な区別: 微妙な背景色の変更や境界線を使用してセクションを分離します。
3. データ可視化の標準化
異なるデータタイプに一貫した視覚言語を適用します。
- ブール値: 包含には高コントラストのチェックマーク(✓)、除外にはダッシュ(—)または空の状態を使用します。
- 評価: 一貫したアイコンスケールを使用します(例:5つ星)。
- ニュアンスのあるテキスト: 説明には小さく読みやすいフォントサイズを使用し、セル内で行の長さが管理されるようにします。
- ハイライト: あるアイテムが他よりも明らかに優れているセルを視覚的に区別します(中立性を保つために注意して使用)。
4. スティッキーコンテキストの実装(道案内)
ユーザーが自分が見ているものを決して見失わないようにします。
- スティッキー列ヘッダー: ユーザーが行をスクロールダウンしても、アイテム名と写真がビューポートの上部に表示され続けるようにします。
- スティッキー行ヘッダー: デスクトップ上の広いマトリックスの場合、ユーザーが横にスクロールしても属性ラベルが左側に表示され続けるようにします。
5. モバイル適応の計画
マトリックスは本質的に横長です。縦画面に適応させます。
- 「セレクター」パターン: 属性リストと1~2個のアイテムを同時に表示し、ドロップダウンまたはスワイプ操作で表示するアイテムを切り替えます。
- 「縦型カード」パターン: マトリックスを一連のカードに変換し、各カードに属性ラベルを繰り返し表示します(非常に単純な比較にのみ推奨)。
判断ルール
- 5つのルール: 横方向の圧迫感を防ぐため、デスクトップ上の横並びマトリックス内のアイテム数を最大5つに制限します。
- 属性の関連性: セット内の少なくとも2つのアイテム間で異なる属性のみを含めます。すべてのアイテムが同じ値を持つ場合、その情報は共有の「グローバル機能」セクションに移動することを検討します。
- ヘッダーの目立ちやすさ: アイテムヘッダー(列1、2など)には製品の小さな画像を含めて、瞬時の視覚認識を提供します。
- 行のホバー状態: 行全体に明確なホバー背景を使用して、列間の目の追跡を容易にします。
制約事項
- アクセシビリティ: 行ヘッダーは
scope="row"およびscope="col"を使用してセルと適切に関連付ける必要があります。チェックマークとアイコンには高いコントラストを確保します。スティッキーな列/行ヘッダーは、その下にあるセルやコントロールのキーボードフォーカスインジケーターを隠してはなりません(WCAG 2.2 SC 2.4.11)。モバイル上のアイテムスイッチャーまたはドロップダウンコントロールは、24x24pxの最小ターゲットサイズを満たす必要があります(SC 2.5.8)。 - レスポンシブ性: 横スクロールは意図的(例:コンテナ内)であり、グローバルページレイアウトを壊してはなりません。
- 視覚的重み: 「先頭列」(属性)は、データ列と区別するためにわずかに異なる視覚的処理(例:薄いグレーの背景または太字テキスト)を施す必要があります。
よくある失敗パターン
- 「見出し喪失」問題: 長いマトリックスをスクロールダウンして、どのアイテムがどれかを忘れてしまう。
- 属性過多: カテゴリ化せずに50行以上を表示し、特定の情報を見つけられなくする。
- モバイル圧縮: 4列をモバイル画面に押し込み、テキストを読めなくする。
- 曖昧なシンボル: 「はい/いいえ」にユーザーがすぐに理解できないカスタムアイコンを使用する。
- 不整合な配置: 同じ列内で中央揃えのアイコンと左揃えのテキストが混在する。
検証基準
- アイテムヘッダーは、縦スクロール中にビューポートの上部に固定されたままである。
- 属性は論理的な折りたたみ可能なセクションにグループ化されている。
- データタイプ(ブール値、評価、テキスト)は一貫した視覚言語を使用している。
- 「先頭列」はデータ列と視覚的に区別されている。
- モバイルビューはアイテム比較のための明確なメカニズム(例:アイテム切り替え)を提供する。
- 行のホバー状態が実装され、横方向の追跡を補助している。
- すべてのアイコンとテキストがWCAG AA(4.5:1)のコントラスト要件を満たしている。
- スティッキーヘッダーがセルまたはコントロール上のフォーカスインジケーターを隠していない(WCAG 2.2 SC 2.4.11)。
- モバイルのアイテムスイッチャーコントロールが24x24pxの最小ターゲットサイズを満たしている(WCAG 2.2 SC 2.5.8)。