Google Stitch で検索UIを設計した——「探す体験」を作ることの奥深さに気づいた

2026.04.16

「検索って、ただ入力欄と結果リストを置けばいいだけじゃないの？」

Google Stitch で検索UIを設計し始めたとき、私はそう思っていた。ところが実際に作り始めると、どこを切っても「判断が必要な分岐」が出てきた。検索バーはどこに置くか。プレースホルダーテキストは何と書くか。ゼロ件ヒット時の画面はどうするか。オートコンプリートの候補はどう出すか——。

「探す体験」は、一見シンプルに見えて、ユーザーの思考のあらゆる段階に対応しなければならない最も複雑なUIの一つだった。この記事では、Stitchで検索UIを設計する過程で突き当たったこと、気づいたこと、失敗したことを書く。

結論から言うと、検索UIの設計において最も重要なのは「検索結果の状態管理」だ。入力前・入力中・結果あり・結果なし・エラー、という5つの状態を一貫したUXで繋ぐことができるか——そこに検索UI設計の本質がある。Stitchはその各状態のビジュアル設計を素早く試せる点で非常に優れたツールだった。

検索UIとは何か——状態の集合体として理解する

検索UIとは、ユーザーが情報を探す一連の体験を支援するUIコンポーネントの総称です。「検索バー（インプットフィールド）」だけを指す場合もあるが、本来は検索バー・オートコンプリート・検索結果ページ・ゼロ件ヒット画面・検索履歴などを含む一連の体験設計を指す。

実際に使ってみてわかったのは、検索UIは「状態の集合体」だということだ。一つの検索体験の中に、少なくとも以下の5つの状態が存在する。

状態1：入力前（検索バーが空の状態）
状態2：入力中（文字を打っている途中）
状態3：結果あり（1件以上の検索結果が表示されている状態）
状態4：結果なし（0件ヒット）
状態5：エラー（通信失敗・タイムアウトなど）

Stitchでこれらを設計する際、最初は「状態3（結果あり）」の画面だけを作って満足していた。しかし実際のサービスでは、状態4のゼロ件ヒット画面がユーザー体験に最も大きな影響を与えることが多い。「何もない画面」こそが、サービスへの信頼と離脱率を左右する。

Stitch で5つの状態を設計した手順

5つの状態をStitchで設計する際、私は以下の順番で進めた。

まず状態3（結果あり）から作る。これが最も情報量が多く、レイアウトの基盤になるからだ。プロンプトには「ECサービスの商品検索結果ページ。カード型レイアウト、フィルター/ソートは上部固定、1行あたり2カラム」と具体的に指定した。

次に状態4（ゼロ件ヒット）。「検索結果が0件だった場合の画面。ユーザーをがっかりさせず、次のアクションに繋げるUIに」というプロンプトで生成した。出てきた画面には「キーワードを変えて試す」「よく検索されているキーワード」「カテゴリから探す」の3つの回避策が含まれており、これは私が最初に想定していなかった要素だった。

状態1（入力前）では「最近の検索履歴と、よく検索されるキーワードのサジェストを表示するプレースホルダー状態」というプロンプトを使った。検索バーだけを置くのではなく「ユーザーの入力を助ける情報」を加えることで、入力前の状態が単なる空白ではなくなる。

プレースホルダーテキストの設計で詰まったこと

検索バーのプレースホルダーテキスト（入力欄に表示されるグレーのサンプルテキスト）の設計で、意外と時間がかかった。

「Search…」や「キーワードを入力」という定番の表現は機能的だが、サービスの個性が出ない。一方で「今日の夕ごはん、何にしよう？」のようなカジュアルな表現は、ユーザーの状況と合わない場面では違和感を生む。

Stitchで複数のバリエーションを生成して比較したところ、サービスの「検索対象物」を明示した表現が最も機能した。例えばECサービスなら「商品名・ブランド名・カテゴリで検索」、レシピサービスなら「食材名・料理名で検索」——「何を検索するか」を示すことで、ユーザーの入力ハードルが下がることが視覚的に確認できた。

ゼロ件ヒット画面が検索体験の肝だった

検索UIを設計していて最も気づきが多かったのは、ゼロ件ヒット画面だった。

多くのサービスで「該当する結果は見つかりませんでした」というテキストだけを表示するゼロ件画面を見ることがある。しかしこれは、ユーザーに「行き止まり」を体験させているに等しい。

Stitchでゼロ件画面を設計する際に意識したのは、「ユーザーがここで立ち止まらないようにする」ことだ。具体的には以下の3つの要素を盛り込んだ。

スペルミスや言い換えの提案（「もしかして〇〇ですか？」）
関連カテゴリへの誘導（「こちらのカテゴリも見てみませんか」）
人気キーワード・注目コンテンツの表示（「今週よく検索されているキーワード」）

Stitchでこれらを組み込んだゼロ件画面を生成したとき、「検索が失敗したのに、むしろこの画面の方が探索の入口になっている」という感覚があった。ゼロ件ヒットは「失敗状態」ではなく「別の発見を促す状態」として設計できる——これは検索UIを設計してみなければ気づかなかった視点だった。

フィルター・ソートとの組み合わせで迷ったこと

フィルターはモーダルか、サイドバーか、インラインか

検索結果画面に絞り込み機能を加える際、フィルターUIをどの形にするかで迷った。主な選択肢は3つだ。

モーダル形式は、フィルターアイコンをタップするとフィルター設定画面がオーバーレイで出現する方式。多くのモバイルアプリで採用されており、フィルターの選択肢が多い場合に向いている。Stitchでの生成結果も自然にまとまりやすかった。

サイドバー形式は、画面左右にフィルターパネルが固定で表示される方式。デスクトップのECサイトでよく見るレイアウトで、フィルターの選択状態が常に見えている安心感がある。Stitchでこれを生成すると、モバイルでは画面が狭くなりすぎる問題が視覚的によくわかった。

インライン形式は、検索結果の上部にフィルタータグやチップスが横並びに表示される方式。シンプルで視認性が高く、選択肢が少ない場合に有効だ。Stitchでの生成では「絞り込みのオプションが増えすぎると横スクロールが発生する」という問題を実際に確認でき、使用する状況の判断に役立った。

ソートの表示と「デフォルト値」の重要性

ソート機能（並び順）の設計では、「デフォルト値が何かをユーザーに明示する」ことが重要だと気づいた。

多くのサービスでは、検索結果はデフォルトで「関連度順」や「おすすめ順」で表示される。しかしユーザーから見ると「この順番はどういう基準で並んでいるのか」が不明なことが多い。

Stitchでソートドロップダウンを設計する際、「現在のソート条件を常にラベルで表示する」という設計を採用した。「関連度順で表示中」というラベルがあるだけで、ユーザーの「なぜこの順番？」という疑問が解消される。Stitchでのビジュアル確認によって、このラベルの有無が結果画面の「信頼感」に大きく影響することを実感した。

失敗したこと・気をつけるべきこと

1. 検索バーの位置で迷いすぎた

検索バーをヘッダー固定にするか、ページ内に置くか、FABボタン（フローティングアクションボタン）にするかで長時間悩んだ。Stitchで3パターン生成して比較したが、答えは「サービスの使用頻度による」というシンプルなものだった。毎回使う機能なら固定ヘッダー、たまに使う機能ならページ内に置く——この判断基準さえ決めれば、選択は早かった。

2. オートコンプリートの候補数を決めずに生成した

オートコンプリート（入力中に候補を表示する機能）を設計する際、「候補を何件表示するか」を決めずにStitchでUIを作ってしまった。生成された画面は5件表示になっていたが、スマートフォンでの視認性を考えると3〜4件が適切なことが多い。プロンプトに「候補は最大4件、現在入力中の文字列はハイライト表示」と具体的に指定すべきだった。

3. デスクトップとモバイルを別々に設計しなかった

最初はモバイルUIのみで検索画面を設計し、後からデスクトップ版を考えたとき、レイアウトの大幅な再設計が必要になった。検索UIは特にデスクトップとモバイルでインタラクションが異なる（マウスホバーでのサジェスト表示など）ため、最初から両方を並行して設計すべきだった。

4. 検索履歴の削除UIを忘れていた

検索履歴を表示する設計をしたが、「履歴を個別に削除する」「全件削除する」というUIを最初に含めていなかった。ユーザーのプライバシーと操作性の観点から、履歴表示がある場合は必ず削除機能とセットで設計する必要がある。Stitchでの追加生成で後から加えたが、最初から盛り込むべき要素だった。

5. 「検索中（ローディング）」状態を設計していなかった

検索ボタンを押してから結果が表示されるまでの「検索中」状態を最初に設計に含めていなかった。APIの応答に時間がかかる場面でユーザーが「止まっているのか処理中なのか」わからなくなる問題は、実装後に気づくことが多い。検索UIを設計する際は、ローディング状態を必ず5つの状態の一つとして含めること。

よくある質問（FAQ）

Q1. 検索バーはヘッダーに固定すべきですか？

「検索がそのサービスのコアアクションか」によります。ECサイト・レシピサービス・ニュースアプリのように「探すこと」が主要な行動のサービスは、ヘッダー固定が有効です。一方でコンテンツ閲覧がメインで検索が補助的なサービスでは、ページ内の適切な位置に置く方がUIが煩雑になりません。Stitchで両方生成して比較するのが最速の判断方法です。

Q2. ゼロ件ヒット画面に何を表示すればいいですか？

最低限「スペルを変えて再検索を促すメッセージ」と「別の探し方への誘導」の2点が必要です。理想的には「スペルミス候補の提示」「関連カテゴリへのリンク」「人気検索キーワード」を含めると、ユーザーが行き止まりにならずに済みます。「何もなかった」という結果は「別の発見への入口」として設計できます。

Q3. Stitch で検索UIを設計するときの効果的なプロンプトは？

「サービスの種類と検索対象物」「想定ユーザーの行動」「状態（入力前/入力中/結果あり/結果なし）の指定」の3点をセットで書くと精度が上がります。例：「フードデリバリーアプリの商品検索。30代女性が料理名・食材名で検索する想定。結果0件のとき、近くのお店へ誘導するCTAを含めた画面を作って」のように記述します。

Q4. オートコンプリートは必ず実装すべきですか？

必須ではありませんが、検索が頻繁に行われるサービスでは入力補助として有効です。ただし、候補の生成ロジック（過去の検索履歴なのか、人気キーワードなのか、リアルタイムAPIなのか）によって実装コストが大きく異なります。UIとして設計する際は、候補の出所と更新タイミングを明確にしてからデザインすると、後でエンジニアとの認識ズレが起きにくいです。

Q5. 検索フィルターはどの形式が使いやすいですか？

モバイルではモーダル形式、デスクトップではサイドバー形式が一般的です。フィルターの選択肢が5項目以内ならインライン（タグ/チップス）でも対応できます。重要なのは「現在どのフィルターが適用中か」を常に視覚的に明示すること。フィルターが適用されているのに見た目が変わらないと、ユーザーは絞り込みが機能しているか判断できません。

Q6. 検索結果の並び順（ソート）のデフォルトは何にすべきですか？

「ユーザーが最も目的を達成しやすい順番」がデフォルトです。多くのケースでは「関連度順」か「新着順」ですが、サービスの性質によって異なります。ECなら関連度順、ニュースなら新着順、レビューサービスなら評価順がユーザーの期待値に近いことが多いです。重要なのはデフォルト値をラベルで明示することで、ユーザーが「なぜこの順番で表示されているか」を理解できる状態にすることです。

Q7. 検索結果ページにおすすめ・関連コンテンツを混在させてもいいですか？

混在自体は問題ありませんが、「検索結果」と「おすすめ」を視覚的に明確に区別することが必要です。ラベル（「〇〇の検索結果」「あなたへのおすすめ」）でセクションを分けないと、ユーザーが「これは私の検索に関係ある情報か」の判断ができなくなります。Stitchでこの区別が明確な画面を生成することで、情報の混在がどれほど混乱を生むかを視覚的に確認できます。

Q8. 音声検索UIはStitchで設計できますか？

マイクボタンの配置や「音声入力中」のフィードバック画面（波形アニメーション等）の静止画デザインは設計できます。ただし実際の音声認識インタラクションはアニメーションが伴うため、静止画のStitchで完結する設計ではなく、プロトタイプツール（ProtoPieやFigmaのプロトタイプ機能）での補完が必要です。音声検索UIをStitchで設計する場合は「マイクボタンのON/OFF状態」と「認識結果の表示方法」を個別の画面として設計するのが実用的です。