検索バーのデザイン：入力・候補・検索結果をつなぐUX

使いやすい検索バーは、何を検索できるのかを伝え、自分の言葉で検索でき、次に何が起きるかを予測できるものです。虫眼鏡のアイコンを表示するだけでは足りません。一覧を検索するのか、すでに分かっている項目を直接開くのかについて、入力欄、候補、検索の実行、戻る操作が一貫している必要があります。

まず、検索対象と利用者の目的を決めます。プロジェクトのライブラリでは、名前を覚えている人もいれば、クライアント名やレビューで使った表現だけを覚えている人もいます。検索は、ナビゲーション設計で整理した分類や移動経路を補うものです。理解できない分類の代わりを検索に任せるべきではありません。ここでは、入力した言葉を失わずに「Spring launch」というプロジェクトを見つける検索を設計します。

入力する前に検索範囲を伝える

周囲の画面から対象が明らかなら、「検索」だけでも伝わります。しかし、同じヘッダーからプロジェクト、メンバー、ファイル、ヘルプ記事を検索できる場合には不十分です。消えないラベル、近くの見出し、または明示的な選択欄で検索範囲を示します。プレースホルダーは入力例に使えますが、文字を入力すると消えるため、説明をすべて任せることはできません。

このライブラリでは、ラベルを「プロジェクトを検索」とします。プレースホルダーに「プロジェクト名またはクライアント名」と示すと、覚えている情報のうち何が使えるかを伝えられます。名前しか検索対象にしていないのに、コメントも検索できるような案内はしません。アーカイブ済みのプロジェクトを除外するなら、結果の近くに説明するか、「アーカイブ済みを含める」というフィルターを用意します。何も伝えずに除外すると、正しく検索しても壊れているように感じられます。

製品全体の検索と、その画面内だけの検索には関連する見た目を使いつつ、違いを示します。請求書の表の上に置く欄なら「請求書を検索」とし、ワークスペース全体の検索では複数の種類を対象にする、といった区別です。全体検索から請求書を開いたときも、検索結果から移動したのか、現在の表を絞り込んだのかが分かるようにします。同じ見た目の操作が、ページごとに違うルールで動くように見えないことが大切です。

入力・クリア・検索実行の役割を分ける

入力欄は、「検索」という短い文字だけでなく、実際の検索語を確認できる幅にします。短い名前と、「Spring launch — client review」のような長い語句で試します。長い文字列は欄の中でスクロールできても、検索ボタンを動かしたり、クリア操作を隠したりしないようにします。フォーカスを視認でき、支援技術向けの名前が安定していて、プレースホルダーだけに頼らず読みやすさが保たれることも必要です。

このライブラリでは、候補を選択していない状態でEnterを押すと、入力された語句全体を検索します。検索ボタンも同じ操作を行います。クリアは文字を消して候補を閉じますが、別のページへは移動しません。見た目を仕上げる前に、こうした挙動を決めておきます。「検索」と書かれたボタンが、突然一件目のプロジェクトを開くようでは困ります。

未入力で検索を実行した場合の動作も決めます。検索が必要だというエラーを出すより、ライブラリを通常の閲覧状態に保つほうが分かりやすいことがあります。検索語がなければ本当に使えない画面なら、何を入力すべきか説明します。何も検索していないのに、検索して失敗したかのような空の結果画面を作らないようにします。

検索語の候補と、直接開く項目を区別する

候補には、入力を補うものと、検索結果を経由せず既知の項目を開くものがあります。どちらも便利ですが、その行を選ぶと何が起きるかが分からなければいけません。この例では、「spring」と入力すると、「検索候補」に「spring launch」、その下の「プロジェクト」に実際のプロジェクト「Spring launch」を表示します。前者は検索を実行し、後者はプロジェクトを直接開きます。

一致する単語だけでは、二つの行の違いを伝えられません。たとえば「プロジェクト · Studio team」のように、種類と識別に必要な少しの情報を加えます。結果が届いても、その情報を安定して表示します。二行目を押そうとした瞬間に一覧の順序が変わり、別の項目を選んでしまうことがないようにします。

長すぎる候補一覧は、候補がない場合より使いにくいこともあります。決められた行数を埋めることより、少数でも関連性のある候補を優先します。別のサービスから取得できるというだけで、プロジェクト専用の検索にヘルプ記事を混ぜないようにします。候補の信頼性が十分でなく、手間を減らせないなら、明確な入力欄と検索の実行ボタンから始めるほうが適切です。

キーボード操作と通信の遅れを考慮する

文字を編集しながら候補を選ぶ欄については、W3Cのコンボボックスパターン（英語）がキーボードとアクセシビリティの動作を説明しています。下矢印キーで候補へ移り、Enterで選択中の候補を確定し、Escapeでポップアップを閉じます。通常の文字編集もできるようにします。支援技術向けの名前は入力欄を説明するものであり、検索語そのものではありません。

そのうえで、この画面でどの動作を採用するかを決めます。ここでは、候補が表示されただけで一行目を自動選択しません。ハイライトは、利用者がその行へ移動したことを示します。どの行も選ばれていなければ、Enterで入力した語句を検索します。プロトタイプでこの区別を共有し、実装したコンポーネントではキーボードと支援技術でも確認します。

次に、「spring」の候補を取得している間に、入力が「summer」へ変わる場面を考えます。先のリクエストの応答が後から届いても、新しい語句の結果として表示してはいけません。この要件をデザインのそばに記します。短い待ち時間なら入力を続けられる状態にし、長く感じられる場合は候補領域の中で控えめに読み込みを示します。候補を裏側で取得するためだけに、画面全体をスピナーへ置き換える必要はありません。

候補の取得に失敗しても、通常の検索が動いているなら実行できるようにします。「候補を表示できません。Enterキーで検索できます」と伝えれば、先へ進む方法が分かります。検索全体が使えない場合は、入力を残して再試行を用意します。読み込み中、取得の失敗、候補が本当にない状態は、最初に選べる行がないという点では同じでも、意味は異なります。

モバイルでも検索に必要な領域を確保する

狭い画面では、小さな検索アイコンから専用の検索画面を開く方法があります。アイコンには支援技術向けの名前を付け、開いた画面には見える入力欄、明確な閉じ方、キーボードを表示する空間を用意します。利用者が検索を開いたときにフォーカスを入力欄へ移し、ライブラリを訪れるたびに自動で移さないようにします。検索するか決める前にキーボードが開くと、閲覧したい内容を隠してしまいます。

検索範囲と操作の意味は、デスクトップと揃えます。ラベルを置く余地が少ないからといって、プロジェクトを開く候補を検索語へ変えてはいけません。違いを消す前に、補助情報を短くします。「Demo」だけでなく、実際にあり得る長いプロジェクト名で確かめましょう。

プロジェクトを開いて戻った場合は、実行済みの検索語と、結果一覧の必要な位置を復元します。まだ実行していないモバイル検索を取り消した場合は、開く前のライブラリの状態へ戻します。この二つは別の意図です。どちらにも対応すると、検索が戻れない寄り道になりにくくなります。

Pixsoで入力から結果までをつなぐ

Pixsoで、通常のプロジェクトライブラリ、「spring」の候補を表示した同じライブラリ、「spring launch」で検索した結果という三つの画面を作成します。フレーム間で入力欄とラベルを揃えます。候補から直接移動する動作を確認する必要がある場合だけ、プロジェクトを開いた四つ目の画面を加えます。Pixsoのプロトタイプ機能を使えば、これらの画面遷移をつなぎ、チームで経路を検討できます。

レビューでは「検索を使ってください」と操作を指定せず、「春の公開に向けたクライアントレビューのプロジェクトを探してください」と課題を伝えます。検索範囲が理解されるか、候補を選んだ結果を予測できるか、プロジェクトから戻ったときに位置を保てるかを見ます。続いて、有用な候補がない検索語と、モバイルでの長いプロジェクト名を試します。コンポーネントがすっきり見えるかという質問とは、違う問題が見つかります。

引き継ぎは簡潔にまとめます。Enterの動作、候補の選択表示、クリアで変わる内容、戻ったときに復元する状態を示しましょう。よい検索は、ポップアップの行数が多いものではなく、利用者が意図を失わずに検索語を調整し続けられるものです。

Pixsoで検索の流れを設計・確認する →