パソコンでは「サービス内容」「導入までの流れ」と見えるナビゲーションが、スマートフォンでは「事業」「流れ」の短い項目に変わる。画面には収まっていても、初めて来た人はどちらに料金や相談条件があるのか判断できないかもしれません。狭い幅に合わせて言葉を省略した結果、目的のページを選べないなら、メニューの見た目だけを直しても迷いは残ります。
この記事は表示や操作の改修を依頼するWeb担当者が、利用用件・選んだ項目・迷い・ラベル修正案を一枚の確認票にする方法です。架空の例を用いて、現在のメニュー名を利用者の行動から見直します。実際のサイトでどの語が分かりやすいかは、読者、掲載ページ、事業内容によって変わります。特定の短い語を正解として配るのではなく、主要な用件で試して決めます。
メニューが開くことと、選べることは別
みやあじよのマルチデバイス対応は、文字、ボタン、メニュー、フォームを実際の幅と操作で確かめ、情報の優先順位から構成を整える支援です。本稿はそのうちメニューの言葉に絞ります。公開済みのスマホ表示不具合の記事は、はみ出しや重なりを再現して直す手順を扱います。ここでは表示崩れがないメニューでも、略語や社内用語によって行き先を選べない場面を調べます。
最初に、項目名だけを会議室で多数決しないようにします。利用者が何をしようとしてサイトを開くかを三〜五個ほど挙げ、現在のページ構成に照らします。例えば、費用の目安を調べたい、申し込み前の条件を確認したい、近い事例を見たい、問い合わせる前に担当範囲を知りたい、といった用件です。実際に多い用件は担当者への問い合わせやサイト内検索語、既存の相談記録から確かめ、仮説だけで読者像を固定しません。
メニューラベルは短いほどよいわけではありません。「案内」「情報」「その他」は幅を節約しても、何があるかを利用者に予想させます。社内で慣れたサービス名も、初めて来た人には意味が分からない場合があります。逆に説明を長くしすぎると、スマホ画面に項目が並ばず、すべてをスクロールしなければなりません。何を区別する必要があるかを決めてから、短さを調整します。
パソコン版とスマホ版でラベルだけ変える場合、同じ行き先に二つの意味が付かないか確認します。パソコン版の「サービス一覧」がスマホ版の「事業」になると、商品や支援を探す人が別の内容だと思うことがあります。メニューに収めるためだけに語を替えず、両方の幅で理解できる基本の名前を探します。どうしても表記を変えるなら、違う用件の人が違うページへ誘導されないか試します。
用件・選択・迷いを一枚に記録する
次の表は架空の事業者サイトで使う確認票です。短い項目名を決める表ではなく、利用者がどの項目を選ぶと予想し、開いた先で用件を果たせるかを記録します。実在サイトの利用者調査や改善結果を示すものではありません。
表は左右にスクロールできます。
| 利用用件 | 現在の候補ラベル | 選んだ項目・迷い | 確認する行き先と修正案 |
|---|---|---|---|
| 費用の決め方を知る | 「案内」「料金」 | 「案内」にも条件があり迷う | 料金ページの範囲を示す語へ |
| 対応する仕事を調べる | 「事業」「サービス」 | 社内用語の「事業」を選ばない | 提供内容が分かる語へ |
| 依頼までの手順を見る | 「流れ」「相談」 | 相談ボタンとの違いが不明 | 手順と連絡先を分ける |
| 近い実績を探す | 「事例」「制作」 | 写真だけのページを予想 | 内容を説明する見出しへ |
| 問い合わせ条件を見る | 「連絡」「相談」 | 電話番号だけと誤認 | 受付条件があることを示す |
テスト票には、参加者の属性や事前に知っていたサービス名も必要です。同じ会社の社員だけで試すと、社内の略語が通じてしまいます。外部の利用者に聞けない段階なら、少なくとも初めて見る人を想定して、ページを知る担当と知らない担当を分けて記録します。「正しい」項目を教えてから選んでもらうと、迷いが見えません。用件だけを伝え、どの項目を最初に開くかを見ます。
確認中に参加者が「この言葉ならここにありそう」と話しても、すぐに正解を伝えず、実際に開いた先で何を見つけたか聞きます。ラベルを選ぶ前の迷いと、ページを読んだ後の不満は別です。選ばれなかった項目も記録すると、二つの語が近すぎるのか、一つの語が内容を過剰に広く見せているのかを検討できます。観察した発言は個人を特定しない形で残し、後からチームで解釈を確認します。
図は、用件を決め、現在のメニューから一つ選び、到着ページで用件が果たせるかを確かめ、名前と配置を直す流れです。タップ回数だけで良し悪しを決めません。メニュー名は分かったが到着先が空白なら、ページ内容の問題です。名前を変えても同じ迷いが続くなら、項目の階層や分け方、ページの重複も確認します。
W3Cのリンク目的の解説は、リンクの文言または文脈から行き先の目的が分かることを説明しています。メニュー内では短い語でも、周囲の階層や見出しと合わせて目的が伝わるか確認します。ただし読み上げ環境ではリンクだけを一覧にする使い方もあります。見た目の近さだけに頼り、「詳しく見る」が何度も並ぶ構成は避けます。この基準は特定のラベルを指定するものではありません。
親項目と子項目の関係を試す
階層型メニューでは、親項目を押すとページに移動するのか、子項目を開くだけなのかを明確にします。同じ見た目で片方だけ動きが違うと、利用者は目的ページへ行けないと思うことがあります。矢印だけを小さく置く場合、指で押せる範囲と、キーボードで開閉できるかも確認します。ラベルと開閉ボタンを別の操作にするなら、それぞれが何をするかが伝わる名前を付けます。
子項目を増やせば迷いが解消するとは限りません。「事業」という親の下に専門名称が十件並ぶと、初めての人は自分の用件に近いものを比べられません。サービスを探す人向けの入口と、課題から探す人向けの入口を分ける方法もあります。ただし、同じページを二つの場所から開ける場合は、名称が違っていても内容が同じと分かるか確認します。項目の複製で更新漏れが起きない運用も必要です。
「お問い合わせ」を常に画面下へ固定しているサイトでも、利用者が事前条件を見られるかを点検します。すぐ連絡したい人と、相談できるか確認してから連絡したい人がいます。ボタンだけを目立たせて利用条件や料金のページをメニューの奥へ隠すと、問い合わせ後の聞き直しが増える可能性があります。現状の問い合わせ内容を確かめ、必要な判断材料へ直接行ける言葉にします。成果の変化は測ってから判断します。
メニュー内の分類とページの見出しを揃えることも大切です。ラベルが「費用」なのに到着先が「プラン」だけで、料金がどこにあるか見えなければ、選択が合っていたと確信できません。ページ先頭で同じ用件に答え、必要な条件を見つけられるか確認します。検索からページへ直接来た人が、メニューで次の情報を探す時にも、名称の関係が分かるようにします。
幅を変えても用件を見失わないか
スマートフォンの縦幅では、開いたメニューの全項目が一画面に収まらない場合があります。初期表示に重要な入口が見えるか、スクロールできると分かるか、メニューを閉じた後に元の位置へ戻れるかを確認します。項目名の文字が折り返された時、隣の項目との区切りが失われないかも見ます。表記を短くする前に余白や行高、グループの数を調整できないか考えます。
中間幅のタブレットでは、パソコン用の横並びメニューがまだ表示され、最後の一項目だけ折れることがあります。逆にスマホ用メニューが広い画面で不自然に間延びする場合もあります。みやあじよの対象ページが示すように、PCとスマホの二点だけでなく切り替わる途中の幅を確認します。項目名を変更したら、最長の語と二行になる語を各幅で見る必要があります。
外部サイトから特定の下層ページへ直接来た人には、トップからの順路がありません。現在のページに対応するメニュー項目が開いているか、現在地が分かるかを確認します。メニューを開いた時に毎回最上位の分類へ戻されると、隣の情報を探し直すことになります。パンくずや見出しとの言葉の対応を見て、今いる場所から次に読むページを選べるか確かめます。表示できる項目数だけで構造を評価しません。
読み上げとキーボード操作では、メニューボタンの名前、開閉状態、移動順を確認します。目で見える文字と読み上げられる名前が違う場合、利用者が他人に操作を頼む時に説明しにくくなります。項目が開いたらフォーカスがどこへ進むか、閉じたら戻れるかを試します。視覚的なラベルの改善だけで操作が完了したと思わず、制作担当とブラウザで実際に確かめます。
用件テストは大人数の統計調査でなくても、まず迷う箇所を発見する材料になります。ただし、数人が迷わなかった結果を「誰でも使える」と書きません。選んだ項目、迷った理由、到着ページで果たせなかった用件を分けて記録します。複数の人が別の項目を選んだ時は、単語だけでなく分類そのものを見直します。修正後も同じ用件で再度試し、言葉を変えたことで別の人が迷わないか確かめます。
写真はメニューの語を検討する編集作業の補助イメージです。実際の利用者調査や改善成果を示すものではありません。
制作担当へ渡す改修範囲を明確にする
改修依頼には、現在のメニュー画面、対象URL、困っている用件、予想と違う選択、変更したいラベル候補をまとめます。項目名だけの差し替えで済むのか、階層変更、ページ見出し、内部リンク、スマホ用の開閉動作まで見直すのかを分けます。タッチ操作や読み上げの不具合があるなら、発生した画面幅とブラウザ、操作手順も添えます。修正範囲が大きい場合は、優先する用件から決めます。
公開前に、編集担当はラベルの意味と行き先を確認し、制作担当は表示と操作を確認します。ページを増やした後も、メニューで選べる言葉が古いままなら新しい内容へ到達しにくくなります。サイト内検索やフッター、パンくず、ページ内リンクにも同じ名称があるなら、どこを正本として更新するか決めます。検索結果のタイトルと到着先の見出しも、利用者の用件とずれないか見ます。
公開後は、メニューのクリック数だけで判断せず、目的ページへ到達した後の行動や問い合わせの内容を確認します。利用者が別経路で目的を果たした可能性もあります。数値の変化をラベル修正の成果と断定する前に、期間、流入、同時に変えたページを記録します。メニュー名は一度決めて固定するものではなく、サービス内容や利用者の用件が変われば見直します。
みやあじよへマルチデバイス対応を相談する際は、現在のメニュー、主要ページ、実際の問い合わせ、迷いが起きた画面幅を持ち寄れます。用件・選択・迷い・修正案の確認票を基に、言葉だけか階層や操作も直すか、改修範囲を具体化できます。
用件からスマホメニューの言葉を確かめる
マルチデバイス対応では、メニューのラベルと開閉、各幅での見え方を相談できます。
