検索結果カードのデザイン：なぜ一致したのかを伝える

同じ単語を含む3件の検索結果が、それぞれ別の問いに答えることがあります。「エクスポート」で検索する人が求めているのは、ブラウザーでの操作手順かもしれませんし、APIのエンドポイントや、最新リリースで機能が変わったかどうかの確認かもしれません。一致したタイトルを並べるだけでは、どれが役立つかまで分かるとは限りません。

検索結果カードの設計では、クリックする前にその選択ができるようにします。各結果に、分かりやすい文書の種類、判断に役立つリンク先の情報、なぜ関連するのかが伝わるだけの一致箇所の文脈を添えます。目的は検索エンジンの順位に装飾を施すことではなく、順位付きで並んだ結果に実際に何が書かれているかを、読者が判断できるようにすることです。

3件の検索結果を、具体的な一つの用件で比べる

架空のレポート作成サービスを考えます。サポート担当者は、絞り込み済みのレポートをブラウザーからCSVファイルとしてダウンロードしたいと思っています。ドキュメントを「エクスポート」で検索すると、次の3件が見つかりました。以下のタイトルと本文の抜粋を、一組のコンテンツ例として使います。レイアウトを比べるときも、この内容は変えません。

この用件では、まずチュートリアルを開くのが適切です。APIリファレンスはプログラムから実行する処理を説明し、リリースノートは変更点を伝えますが、操作全体を教えるものではありません。エクスポートのリクエストが何を返すかを知りたい開発者なら、同じ一覧から別の文書を選びます。どれか一つが常に「優れている」わけではありません。

ここで扱うのは、検索結果が存在する場面です。フィルターの操作を変えることや、結果が0件だった理由を説明することは、別の段階の課題です。そちらでつまずいているなら、フィルターUIの設計ガイド（英語）やエンプティステートのパターンを参照してください。この例では候補となる文書はすでにあり、読者はその違いを見分ける必要があります。

タイトルのそばに、文書の種類とリンク先の位置づけを示す

「チュートリアル」「APIリファレンス」「リリースノート」のように、どのような読み方をする文書かが分かる短い種類ラベルを使います。アイコンで補強してもよいですが、一般的なページの記号だけでは違いを伝えられません。チュートリアルが先頭にあるという理由だけで「おすすめ」を付けるのも避けます。カード上で根拠を説明していない評価を、示すことになるからです。

パスは、別の種類の文脈を補います。「API v2 › レポート › エクスポート」なら、特定バージョンのAPIに属するエンドポイントだと分かります。「ガイド › レポート › エクスポート」なら、利用者向けの操作手順の中に位置づけられます。サイト内の全結果に長いホスト名を繰り返しても、場所を取るだけで、これらのリンク先の違いは伝わりません。実際に複数サイトの結果が混在し、出所が選択に影響する場合に、ドメインを表示します。

リンク先を開く主なリンクには、タイトルを使います。同じ「開く」というリンクばかり並ぶと、リンクを順に移動して読む人に、避けられるはずの曖昧さを生みます。W3Cのリンクの目的に関する解説（英語）では、リンクテキスト、またはプログラムで判断できる文脈から目的が分かることを認めています。見た目が近いだけでは、その関係にはなりません。実装では検索結果ごとに意味のあるまとまりを持たせ、リンク先ページのタイトルも、一覧で伝えた内容と一致させます。

この例では、パスは説明用のテキストであり、3個の追加リンクではありません。主な選択を、文書を開くことに絞るためです。製品にカテゴリからたどる機能もあるなら、小さなパスの各要素を説明なく別のクリック先にするのではなく、補助的な操作として明示的に設計します。

意味を変えずに、なぜ一致したかを見せる

文書の説明文と、検索語に応じた抜粋は、役割が異なります。説明文は文書全体を要約し、抜粋はその中の関連する一節を示します。チュートリアルの「レポートを開き」という文が役立つのは、ブラウザーで行う操作だと分かるからです。すでに内容が伝わるタイトルの下で、「レポートのエクスポートをすべて学べます」と繰り返しても、判断材料はほとんど増えません。

Algoliaのハイライトとスニペットのガイド（英語）では、一致した語を強調し、その周辺の語も返す仕組みを説明しています。これらの仕組みで、検索語がどこに現れるかは示せます。しかし、その文書が利用者の問いに答えること、最新であること、妥当な理由で別の結果より上位にあることまで証明できるわけではありません。

抜粋を短くするときは、条件や制限を伝える文を守ります。APIの結果では、「ジョブIDであり、CSVファイルではありません」を残す必要があります。そうしないと、担当者が直接ダウンロードする手順だと誤解するかもしれません。リリースノートでは、「エクスポートのスケジュール実行は追加されていません」を残します。否定まで読めない位置で切ったり、「エクスポートのスケジュール実行」だけを抜き出したりすると、判断に必要な情報が変わってしまいます。

固定の文字数で切って三点リーダーを付けるのではなく、収まる長さの一文か、意味がつながる一節を選びます。安全上の条件や制限がそれでも収まらなければ、行を増やすか、より短く、原意を保った抜粋を選びます。インデックスに使える抜粋がない場合は、実際の文書の説明文を使い、要約として示します。引用を捏造したり、検索語が一致した箇所だと偽ったりしてはいけません。

文が読みやすい範囲で、控えめに強調します。検索語がタイトルとスニペットの両方にあるからといって、カード全体に色を付ける必要はありません。MDNは、mark要素を文脈上の関連性があるテキストとして説明（英語）し、多くのスクリーンリーダーはデフォルト設定でその強調を読み上げないとしています。表示した一節は、色の印がなくても意味が通じる必要があります。欠かせない違いは、言葉で伝えます。

表示する各項目に、必要な役割を持たせる

役立つカードは、文書の小さなダッシュボードではありません。各項目が読者のどの判断を助けるか、狭いレイアウトでもどの部分を残すかを決めます。以下はレポートの例に対するルールです。ダウンロード可能なファイルのカタログなら、別の情報が必要になります。

複数の項目で、同じ情報を繰り返さないようにします。APIのパスにはすでに「v2」があり、別のバージョンバッジも必ず必要というわけではありません。逆に、すべての行を同じ高さにするためだけに、重要な違いを削らないでください。リリースノートのバージョンは、チュートリアルの更新日よりも選択に大きく影響することがあります。

表示するカードには、空のメタデータ欄を残さないようにします。内容の確認日がないなら、任意の取り込み時刻を「更新日」として表示するより、その項目を省くほうが誠実です。分類がないことも、データの設計・管理側で直すべき問題であり、装飾用アイコンから文書の種類を推測する理由にはなりません。

カードの枠だけでなく、判断材料を組み直す

狭い画面では、まずタイトルと種類を置き、違いが伝わるパスと、意味がつながる抜粋を残します。3件のエクスポート文書を見分ける語を取り除く前に、繰り返しの装飾を減らします。種類、日付、著者、パス、バージョンを灰色の1行に詰め込むと、幅に収まっていても読み解きにくくなります。

長いタイトルは折り返せるようにし、実際の文言で試します。2行のスニペットはレイアウトの出発点にはなりますが、どの言語でも、どんな条件文でも2行に収まるという保証ではありません。リリースノートでは、3枚のカードの高さをぴったりそろえることよりも、スケジュール実行が追加されていないという否定の説明が重要です。

Algoliaが公開したドキュメント検索のリデザイン事例（英語）には、具体的な比較があります。デスクトップでは結果一覧とプレビューを組み合わせ、モバイル・タブレットではプレビューの代わりに短い説明を使っています。また、コンテンツの種類によるグループ分けも説明しています。これらはその実装での選択であり、すべての検索画面にプレビューや同じ分類が必要だという根拠ではありません。

3件だけなら、各結果に種類ラベルを添えれば十分かもしれません。セクションを分けると、整理の効果より見出しばかりが増えることもあります。件数が多く、グループ分けが役立つなら、ラベルと移動順を明確にします。任意のプレビューは詳しい情報を補うものであり、結果の正体を知る唯一の場所にしてはいけません。ホバーしなくても、役立つ結果を選んで開けるようにします。

選ぶ時点で、表示内容を信頼できるようにする

カードのタイトル、抜粋、パス、バージョンは、同じリンク先を説明する必要があります。現在のタイトルに古い版の抜粋を組み合わせると、もっともらしくても誤解を招く結果になります。この例のAPI結果に「API v2」とあるなら、開いたときに説明なく別バージョンの文書へ移してはいけません。移動・差し替え・旧版となった文書をどう示すかを、インデックスとコンテンツの担当者と決めます。

検索インデックスにまだ残っているという理由で、閲覧が制限されたタイトルや一致箇所を開示してはいけません。OWASPは、リクエストごとの権限確認を推奨しています（英語）。検索に当てはめるなら、どのメタデータを開示できるかを定義し、文書を開くときだけでなく、検索結果を返す時点でもそのルールを適用するということです。一覧の読み込み後に権限が変わる場合もあります。結果を開く際も現在の権限に従い、保護された抜粋を見せずに、適切な回復の案内を表示します。

主な操作は、文書の役割に沿ったものにします。「レポートをCSV形式でエクスポート」を開いたら、ダウンロードを開始するのではなく、手順を開くべきです。「今すぐエクスポート」という直接操作は、文書を開くこととは異なり、実際の処理を伴う製品上の操作です。そのため、独自の権限確認と状態処理が必要です。検索語を入力しただけで、その操作の実行権限が与えられるわけではありません。

カードを仕上げる前に、Pixsoで同じ内容を比べる

Pixsoのデザインファイルで、タイトル、種類、パス、抜粋を別々のテキストレイヤーにした検索結果カードのコンポーネントを作ります。3個のインスタンスに、上の例と同じ内容を入れます。最初のタイトルだけのフレーム、情報を追加した結果一覧のフレーム、狭い画面用のフレームを残します。同じ文書を比べれば、追加した文脈が何に役立つかを見やすくなります。案ごとにタイトルを変えると、何による違いかが分からなくなります。

狭い画面のフレームでは、余白だけでなく、内容の扱いも決めます。チュートリアルのタイトルを折り返し、APIのレスポンスに関する制限と、リリースノートのスケジュール実行についての文を残します。条件付きで表示する項目や省略のルールは、コンポーネントのそばに注記します。どの語を消してよいかを、実装担当者の推測に任せないためです。

プロトタイプで結果のタイトルを対応する文書フレームにつなぎ、検索語を保持したまま戻れる導線を用意します。これはリンク先を選ぶ判断のモデルであり、動作する検索インデックスではありません。キャンバス上のレポートアプリはレビューする設計対象であり、Pixso自体の検索動作について述べているわけではありません。

同僚に、絞り込み済みのレポートをブラウザーからCSVとしてダウンロードするための文書を選んでもらいます。次に、APIが何を返すかを調べるタスク、リリース2.8でスケジュール実行が追加されたかを確認するタスクを試します。それぞれの選択で、どの項目を根拠にしたかを聞きます。たとえば「日付が新しく見える文書が必ず最適だ」と思い込むなど、間違った理由で正しいカードをクリックした場合も、設計上の問題が見つかっています。

最後に、同じ経路をキーボード操作と大きな文字サイズでも確認します。リンク先を見分け、制限の説明を最後まで読み、検索語を入力し直さずに戻れるでしょうか。うまくいかなかった項目や抜粋を修正します。成功とは、行がカラフルになることやクリック数が増えることではなく、これらの文書から根拠をもって選べることです。

Pixsoで、判断材料が伝わる検索結果ページをデザインする →