← エピソード一覧に戻る Episode 184 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 探す時間が長い会社は、前に進みにくい
タカシ
今日は SaaS デザインの検索UXです。McKinsey は、知識労働者が仕事時間の約五分の一、つまり週一日分を情報探索に使っていたと紹介しています。検索が弱い会社は、それだけで毎週かなりの時間を落としているんですね。
ミカ
週一日ですか。それは大きいですね。しかも SaaS だと、探す相手がヘルプ記事だけじゃなくて、案件、チケット、設定、チャット履歴まで広がるから、検索の出来がそのまま仕事の速さに出そうです。
タカシ
その通りです。機能が増えた SaaS では、メニューだけで全部に辿り着くのは無理があります。だから検索は補助機能ではなく、必要な情報や操作へ最短で飛ぶための第二のナビゲーションなんです。
ミカ
なるほど。つまり『検索窓がある』では足りなくて、『目的地にちゃんと着けるか』まで設計しないといけないわけですね。今日はその差がどこで生まれるのかを知りたいです。
Chapter 2 原則 ― 候補を増やすより、迷いを減らす
タカシ
まず大事なのは、検索UXはインデックスの量ではなく、探索コストの設計だということです。Baymard Institute は、オートコンプリートを持つサイトは多いのに、実装の細部まで適切なのは一九パーセントしかないと整理しています。
ミカ
ああ、ありますね。候補が山ほど出てきて、速くなるどころか読む仕事が増えるやつ。検索なのに、逆にこちらが選別係みたいになる瞬間です。
タカシ
まさにそれです。Baymard は候補がデスクトップで十件を超えると選択麻痺が起きやすいとも述べています。SaaS のグローバル検索でも、数を盛るより、対象種別や検索範囲を見せたほうが意思決定は速くなります。
ミカ
つまり、良い検索は『いっぱい出す検索』じゃなくて、『次に押すべきものがすぐ分かる検索』なんですね。候補の量より、候補の意味が見えることが大事だと。
Chapter 3 実務 ― SlackとNotionに学ぶ絞り込みと信頼性
タカシ
実務例として分かりやすいのが Slack です。公式ヘルプでも、`in:` `from:` `has:` `before:` `is:thread` などの modifier を組み合わせて範囲を狭められますし、結果は Messages、Files、People、Channels など種別で切り替えられます。
ミカ
一発で全部当てるというより、『広く探して、途中で絞る』前提なんですね。業務の現場って、最初から完全な検索文を打てる人ばかりじゃないから、その考え方はかなり現実的です。
タカシ
Notion も面白いです。通常検索では引用符で exact phrase を探せて、source や author で filter できます。さらに Enterprise Search では Slack や Jira まで横断し、回答には citation が付き、検索対象を特定アプリだけに絞ることもできます。
ミカ
それは安心感がありますね。検索で一番つらいのって、答えが出ても『本当にこれで合ってるのかな』と不安になることなので、引用元と検索範囲が見えるだけでかなり信頼しやすくなりそうです。
Chapter 4 設計 ― 初心者向けの入口と上級者向けの深さを分ける
タカシ
検索UXで難しいのは、初心者と熟練者の両方を支えることです。Jira Cloud は quick や basic search で入りやすくしつつ、JQL ではそれだけでは表せない条件まで指定できます。入口は簡単、奥は深い、という構造ですね。
ミカ
分かります。最初から構文を覚えろだと離脱するし、逆に簡易検索しかないと運用担当者が毎日同じ絞り込みを繰り返す。どちらかに寄せすぎると、結局みんな遅くなるんですね。
タカシ
Linear もそこが上手いです。workspace 全体検索、現在の view 内検索、recent issues、ID 直指定を分けています。しかも結果は relevance、last updated、last created で並べ替えられ、最大五百件まで返ると明示しています。
ミカ
つまり『どこを探しているのか』を最初から混ぜないわけですね。全部同じ検索窓に見えても、実際の仕事では、今の一覧から探したい時と、会社全体から探したい時は別の行動ですもんね。
Chapter 5 まとめ ― 検索は発見機能ではなく、業務導線である
ミカ
今日の失敗パターンをまとめると、何を検索しているか分からない、候補を出しすぎる、初心者と熟練者を同じ操作に押し込む、権限や共有状態を曖昧にする、そしてゼロ件の後に次の一手がない、このあたりですね。
タカシ
ええ。まずは自社プロダクトの検索を、全体検索、画面内検索、ID検索に分けて棚卸しすることです。そのうえで、候補数、スコープ表示、フィルタ、高度検索への導線、ゼロ件時の救済策を順に点検すると改善しやすいです。
ミカ
検索改善って、つい relevancy のアルゴリズム勝負に見えますけど、実際は見せ方や逃げ道の設計もかなり大きいんですね。デザイン、PM、CS が一緒に見たほうが良さそうです。
タカシ
その通りです。見つからない機能は、顧客にとっては存在しないのと同じです。皆さんの SaaS でも、最重要画面を一つ選び、『迷わず見つかるか』『見つからない時に次の行動が示されるか』を、ぜひ今日確認してみてください。