サービスの無記名カードと検索の画面を置いた作業机

NOTES

複数事業のサイトで メニューと検索の役割を分ける

複数事業のWebサイトで、目的別メニュー、サービス名一覧、サイト内検索をどう使い分けるか。意図・情報タイプ・別名の表から結果表示と更新を考えます。

チップス

設備の点検、修理、更新を扱う会社のサイトで、訪問者が「機械が止まった」と入力する。サイト内検索には事例や古いお知らせが並ぶのに、今相談できる修理サービスの詳細が見つからない。一方、メニューを開くと社内の事業部名が並び、どれが修理の担当か分からない。検索窓を追加しても、言葉と行き先がそろっていなければ、利用者は再び探し直します。

複数事業を扱う会社のWeb担当者が、メニューで見せる主な選択肢、検索で拾う言葉、別名からつなぐページを判断するための編集例です。事業の正式名称や受付できる範囲は会社の担当者が決めます。ここではサイト内で「どこに何があるか」を見分ける画面と更新方法を扱い、検索結果の順位や問い合わせ増加を保証するものではありません。

メニューと検索は、持っている手掛かりが違う

みやあじよの事業・サービスの案内を整理する制作は、初めての人には目的別、名称を知る人にはサービス名の入口を用意し、一覧・詳細・相談先をつなぐ方針です。公開済みの複数事業を依頼目的から選ぶ記事は、顧客の目的、対応事業、詳細ページ、窓口を対応表にする構成を扱います。本稿ではその次に、メニューの項目だけで案内できるか、検索を設けるなら何を探せるようにするかを決めます。

初めて来た人は、正式なサービス名を知らないことがあります。「点検したい」「不具合を直したい」といった目的が見えているなら、少数の分かる入口をメニューやトップページに出せます。既存の取引先は、見積書に書かれた名称や型番を覚えているかもしれません。その場合、名称一覧やサイト内検索が役立ちます。どちらの人も同じ詳細ページへ到達できますが、持っている言葉が違います。

W3C WAIのメニューのチュートリアルは、メニューの構造を反映したマークアップと分かるラベル、マウス・キーボードでの操作を重視します。検索についての補足的な設計パターンは、メニューの分類を理解しにくい人にも検索が別の道になると説明しています。これは検索窓を全サイトに必須とする基準ではありません。会社のページ数、情報の種類、更新できる体制を見て、両方の役割を決めます。

トップページに事業名をすべて並べると、専門名を知る人には便利でも、初めての人には違いが伝わらないことがあります。反対に目的のカードだけにすると、正式名称を探す取引先が見失うことがあります。主な目的を先頭に、正式なサービス一覧を別の分かる位置に置き、検索を使うなら何を対象にするかを示します。「検索」で事例、ニュース、商品資料まで一緒に出るのか、サービスだけを探すのかを曖昧にしません。

意図・情報の種類・別名で入口を決める

次の表は、架空の設備関連会社を想定した編集用の判断表です。実在する事業や検索履歴、対応範囲を示しません。実際の問い合わせ、営業で聞く言葉、サイトのページ一覧から候補を集め、担当部門が対応先を確かめて使います。

表は左右にスクロールできます。

架空の設備関連会社を想定したメニュー・検索・別名の編集用判断表
訪問者が持つ手掛かり 探す情報の種類 メニューでの入口 検索・別名で拾うこと
「不具合を直したい」 現在頼める修理サービス 依頼目的「修理」 「故障」「停止」等を確認済みの詳細へ
正式な事業名を知る サービスの対応範囲 サービス名の一覧 旧称や略称を現行ページへ
過去の導入事例を探す 事例と条件 事例の一覧 サービスと事例を結果で区別
「休日の連絡先」を探す 受付条件・連絡方法 利用中の方向け案内 営業時間や緊急対応の実際へ
部門を決められない 相談先と初回に伝えること 「どれか分からない」相談 該当なし時も窓口へ戻す

表の検索語は運用を考えるための仮の候補です。検索履歴から得た実際の言葉と、担当者が予想した言葉を分けて記録します。「故障」と検索した人を修理へ案内するとしても、対象設備や受付時間を会社が確認しなければ、受けられない仕事まで期待させます。別名は同義語の辞書ではなく、その言葉で来る人にどのページを読ませるべきかの判断です。

目的メニュー、サービス一覧、検索から確認済み詳細へ進む図
目的が分かる人、正式名称を知る人、言葉を入力する人が同じ現行詳細へ進む独自図。

図は、訪問者が「目的が分かる」「正式名称を知る」「言葉だけ思い出す」の三つの状態から、目的メニュー、サービス一覧、サイト内検索へ進み、同じ確認済みの詳細ページに着く構成です。検索結果に直接問い合わせボタンだけを置くのではなく、対象、条件、進め方を読めるページを経由します。適切な詳細がまだないなら、検索の設定だけで穴を隠さず、説明を追加するか受付担当が確認できる相談へつなぎます。

メニューに置く項目は、会社の組織図と一対一にする必要はありません。訪問者が最初に選びやすい主な目的を優先し、詳しいサービス名は一覧で見せる方法があります。メニューを短くするために必要な事業を消すのではなく、どの階層で読めるか決めます。検索に頼らせる前に、主要なサービスや連絡先がマウス、キーボード、スマートフォンからメニューで見つかるか確認します。

検索結果に「何のページか」を表示する

サイト内検索を設けるなら、ヒットしたページ名だけを縦に並べないようにします。「サービス」「事例」「よくある質問」「お知らせ」「資料」など、情報の種類を分かる言葉で示します。同じ「設備更新」という語を含んでも、現在のサービス詳細と三年前の施工事例では、次にできる行動が異なります。公開日や更新日も必要に応じて表示し、古いニュースを現在の受付条件として読ませません。

結果の見出しには、対象者や用途、扱う範囲が短く分かる説明を添えます。サイトに「点検サービス」ページがあっても、本文に「保守」「定期確認」という言葉が使われていなければ、普段の言い方ではヒットしないかもしれません。検索設定で別名を登録する方法と、公開ページの説明に自然な言葉を足す方法を比較します。内部の索引だけを増やし、到着したページに探した語との関係がない状態は避けます。

旧称と新称がある場合、検索結果で二つの別サービスのように出さない工夫も必要です。名称を変えた時期、古い資料での呼び方、現行の提供範囲を部門へ確認します。旧称で探した人には現行ページを示し、変更によってサービス内容も変わったなら、その差を説明します。略称が複数の事業で使われる場合は、勝手に一つへ転送せず、候補を区別して選べる一覧へ案内します。

検索結果がゼロの時は「該当なし」だけで止めません。表記を変える候補、主要な目的の入口、担当を選べない相談先を示します。ただし存在しないサービスへ無理に案内したり、関連性の低い記事を一致結果として見せたりしません。よく検索されるのに結果がない語が分かったら、受付記録と合わせて、言い換えを追加するか、詳細ページが不足しているかを確認します。検索ログに個人情報や機密の語が含まれる可能性は、保存・閲覧・利用方法を会社の方針で決めます。

検索を足す前に、メニューだけで足りるか試す

まず現在のサービス一覧、詳細、事例、FAQ、連絡先を棚卸しします。少数のページで、主要な情報がトップページから数歩で見つかるなら、メニュー名やページの説明を直すだけで十分な場合があります。W3C WAIの検索に関する補足資料も、小さなサイトでは検索の重要度が低い場合に触れています。検索機能を先に発注する前に、何を探せずに困っているかを観察します。

画面で確かめる際は、事業名を知らない新規顧客と、正式名称を知る既存顧客を想定します。それぞれメニューから到着できるか、語を入力した場合は適切な詳細が上位に現れるかを確認します。検索を実装しない場合でも、名称一覧、目的別入口、サイトマップ、関連ページへのリンクを整えられます。検索を実装する場合は結果の分類、別名、更新、該当なし時の案内を運用項目として見積もります。

「検索窓があれば利用者が自力で探せる」と考え、分かりにくいメニューを放置しないことが大切です。検索語を思い付かない人もいます。逆にメニューが整っていても、長い製品名や文書名を知っている人は入力して探したい場合があります。両方の経路の到着先を一致させ、結果画面で古い情報と現行サービスを見分けられるようにします。検索が別サイトやPDFを対象に含めるかも明記します。

スマートフォンではメニューが閉じていることが多いため、主な目的の入口と検索窓の見え方を個別に確かめます。小さな虫眼鏡アイコンだけで検索できると伝わるか、入力欄のラベルがあるか、結果から戻って語を直せるかを試します。キーボードでは開閉、フォーカス、結果への移動を確認します。メニュー内に検索欄を押し込んで、開かないとどちらも使えない構成になっていないか見直します。

白紙の分類カードとサイト構成図を並べる担当者の手元

写真は、目的のカードと検索用の言葉を並べて考える作業の補助画像です。実在の会社のサービス一覧や検索結果を示していません。

別名と更新担当を一緒に管理する

新しいサービスが加わったら、メニュー、サービス一覧、検索対象、別名、関連事例、問い合わせ先を確認します。事業名だけ変更して旧称で検索できなくなったり、終了したサービスが結果上位に残ったりしないようにします。更新表には「公開する名称」「利用者が使う別名」「現行の詳細」「結果に出す情報の種類」「確認部門」を持たせます。検索語を営業の思い込みだけで増やさず、実際の問い合わせから確かめた候補かどうかを分けます。

同じ言葉が複数事業に関わる場合は、ページを一つに統合する前に役割を確認します。たとえば「保守」が設備の定期点検とソフトウェアの運用支援を指すなら、検索結果で対象を明示し、メニューも専門領域を区別します。一つの受付で両方聞く場合でも、担当者へどう引き継ぐか決めます。Webの分類だけで提供範囲や契約内容を新たに定義しません。

過去事例は消さずに残す判断もありますが、現在提供していないサービスへのリンクやボタンを点検します。事例から現行サービスへ進めるなら、当時の条件と今の受付範囲が同じかを確認します。検索結果の要約が古い内容を切り出していないかも見ます。ページ公開日や事例の実施時期と、今相談できる条件を区別すれば、検索で見つけた情報を誤用しにくくなります。

公開後は、実際に使われた検索語、該当なしの語、検索後に開かれたページを、取得できる範囲で見ます。ログだけで利用者の意思を断定しません。問い合わせで言い直された言葉や、営業が案内し直したページと突き合わせ、まずメニュー名を直すか、ページの説明を足すか、検索の別名を調整するかを選びます。個人を特定できる入力は集計目的で無条件に保存せず、取扱いを確認します。

検索結果を公開前に試す語には、正式名称だけでなく、略称、旧称、困りごとの言い方、資料名を混ぜます。担当者が期待する到着先を先に記録し、実際の結果と比べます。見つからない理由が分類か原稿か検索設定かを分けて直します。

みやあじよへ事業・サービスの案内整理を相談する際は、現在のメニュー、ページ一覧、検索の有無、問い合わせで聞く言葉を持ち寄れます。意図・情報の種類・別名の表から、メニューの名称を直す範囲と検索が必要な範囲を具体的に決められます。

メニューと検索から同じ詳細へ

事業・サービスの案内整理では、目的別の入口、サービス一覧、検索の対象と更新方法を相談できます。

参考にした公開情報