ナビゲーション設計 (Navigation)

ナビゲーション

ナビゲーションは、構造のどの部分が画面上に恒久的な場所を獲得し、どの部分が別の方法で到達されるかを決定します。スロットは限られており、各サーフェスには、何がそのスロットを獲得するかの独自のルールがあります。

最初に必要なもの

入力	入手先	不足している場合
現状の全サーフェス	コードベースの場合、最初にルートとナビゲーションコンポーネント（ヘッダー、フッター、アプリスイッチャー、サイドレール、タブバー）を読みます。トップページだけで再設計しないでください。	スクリーンショット、またはサーフェスごとの項目のリストを依頼します。
その背後にあるツリー	サイトマップ、またはルート	自分で現在のツリーをマッピングし、その旨を伝えます。構造自体が間違っている場合は、停止して sitemaps を使用します。
トップタスク、ユーザーが失敗するタスク、利用状況	ユーザー、アナリティクス、検索ログ、繰り返されるサポート質問	質問するか、冒頭で自分の前提を述べます。利用状況を推定しないでください。もし入手できた場合にどの判断が変わるかを述べてください。

これらが一つも入手できない場合は、何が必要かを述べ、references/spec-template.md からエントリルールを記入した空の仕様書を生成します。

方法

1. すべてのサーフェスをマッピングします。 サーフェス、項目、遷移先、カウント。同じ遷移先が別の名前で存在するもの、どこにも遷移しない項目、そしてたまたま一つのサーフェスにしか存在しないものをマークします。

2. グローバルとローカルを分離します。

   	グローバル	ローカル
   役割	この場所全体が提供するもの	このページの周辺にあるもの
   表示	すべてのページで同じ	自分のセクション内のみ
   サーフェス	プライマリ、ユーティリティ、フッター	サイドレール、ページ内コンテンツ、パンくずリスト、関連リンク
   問題が発生する時	あるセクションの子項目を列挙している時	グローバル項目を繰り返している時

   3 レベル以上のナビゲーションが必要なセクションは、通常、独自のサイドレールまたは独自のホームページを必要とします。

3. 各サーフェスにエントリルールを設定し、すべての項目に適用します。

   サーフェス	属するもの	属さないもの	エントリルール
   プライマリ	ユーザーとビジネスにとって最も重要な 3〜6 の宛先	スロットを獲得していないもの	トップタスクまたは明示されたビジネス目標に役立ち、新規ユーザーにも理解でき、すでにある最も弱い項目よりも優れていること
   ユーティリティ	サインイン、アカウント、検索、言語、設定	マーケティング優先順位の項目	個人のセッションまたはツールに関するものであり、コンテンツそのものに関するものではないこと
   フッター	より完全なサイトマップ、法的情報、連絡先、二次的なコールトゥアクション	なんでも入れの引き出し（ユーザーもクローラーも読む）	どのページからでも誰かが必要とする、または法律で必要とされる。名前付きグループに適合すること
   コンテキスト	サイドレール、ページ内コンテンツ、パンくずリスト、関連リンク	グローバルなもの	ここでのみ意味を持ち、文書化されたルールによって配置されること
   アプリアップタブバー	最大 5 タブ。6 つ目は「もっと見る」になるか削除	ほとんど使われない宛先	プロダクト内で繰り返されるトップレベルのジョブであること

4. 割り当てます。 プライマリ項目が 7 つを超える場合は、そのうちのいくつかがスロットに値しないことを示しています。統合するか、フッターに移動します。ほぼ同じものを 1 つに統合します。人々が失敗するタスクすべてに 1 つの正規のホームを与え、他のエントリポイントはそこに遷移すると明記します。

5. 2 つまたは 3 つの配置案を提示します（タスク別、オブジェクト別、オーディエンス別）。それぞれのコストと負担がかかる点を示します。1 つを推奨し、その理由を述べます。

6. パターンを選択します。

   状況	使用するパターン	注意点
   1 つの項目に、さらに子を持つサブグループが 3 つ以上ある場合	メガメニュー	キーボードフォーカスとモバイル版は別作業として設計
   子が少ないフラットなリストの場合	プレーンドロップダウン、またはハブページへのリンク	多くの場合、ハブページの方が優れている
   階層が 3 レベル以上ある場合	パンくずリスト	各パンくずは実際のページです。1 ページ 1 トレイルで、ユーザーがたどったルートではなく、正規のホームに従うこと
   長いリファレンスページの場合	ページ内コンテンツ（目次）	ローカルのみ
   異なるロールが異なるスタート地点を必要とする場合	パーソナライズされたショートカット	ショートカットをパーソナライズし、マップはパーソナライズしないこと。全員が異なるメニューを見る場合、道案内ができず、サポートが場所を説明できず、分析が無意味になる

7. モバイルとキーボードを今設計します。 モバイルでは、プライマリがどのように折りたたまれるか、何が表示されたままになるか、各メガメニューがどうなるかを記述します。キーボードでは、すべての項目が視覚的な順序で到達可能で、フォーカスが可視であり、Escape キーで Enter キーで開いたものが閉じ、ホバーだけで動作するものがないようにします。詳細は references/mobile-and-keyboard.md にあります。開くメニューがある場合は必ず読んでください。

8. 判断の場に手がかりを配置します。 良い手がかりは、ユーザーがすでに抱いている質問に、選択する瞬間に、すでに見ている場所で、静かにかつ低コストで答えるものです。車の燃料計の横にある給油口の位置を示す矢印がモデルです。現在位置をアクティブ状態で示します。

9. 項目がどのように削除されるかを計画します。 リンクを削除することは、ページを削除することではありません。

   ステップ	作業内容
   運命を決定	統合、フッターまたはユーティリティへ移動、検索のみでの到達可能、または削除
   ページがなくなる場合	リダイレクトマップに追加
   ページが残る場合	別のパスがまだそこに到達できることを確認
   ユーザーに通知	サインインプロダクトの場合、古い場所に 1〜2 リリースの間ポインタを残し、古いパスを記載したヘルプ記事、ツアー、メールを修正
   単語は残す	古いラベルは検索の同義語として残し、検索とサポートを監視

10. 検証は tree-tests に引き継ぎます。 計画とタスクを作成します。今回の作業のきっかけとなった各問題、確信が持てなかった配置、および提案された回答を渡します。目標：成功率 70% 以上、トップタスクは 80% 以上、パス比は最大 1.5。

成果物: navigation-spec.md

以下の順序で作成します。

1. 推奨事項： 2〜3 文と主な理由。
2. 現状： 各サーフェス、その数、問題点。
3. オプション： 配置案ごとに 1 行、コストも記載。
4. 仕様： サーフェスごとにラベルと遷移先、各プライマリ項目がスロットを獲得する理由。次にパンくずパターン、モバイル、キーボード、アクティブ状態。
5. 正規のホーム： 問題となるタスクごとに、その唯一のホームとそこに至るエントリポイント。
6. Before / After： 現在の全項目とその移動先（廃止されたものとその方法を含む）。
7. エントリルール： 新しいトップレベル項目が合格すべきテスト。
8. 前提と未解決の質問。
9. tree-tests への引き継ぎ事項： 問題タスク、確信が持てない配置、提案された回答。

規模を適切に縮小します。メニューの再考には、診断、新しいツリー、問題タスクごとの 1 つのホーム、tree-tests への引き継ぎが必要です。コンテンツモデルや URL ポリシーは必要ありません。長いドキュメントがより徹底しているとは限りません。すべての項目を配置するよう依頼された場合、すべての項目にホームが割り当てられます。

確認項目

スクリプトはありません。これらのチェックは短く、仕様を読む必要があるため、手動で行い、失敗した箇所を修正します。

• プライマリ項目の数をカウント（最大 7、推奨 3〜6）、タブの数をカウント（最大 5）。
• すべての現在の項目が Before/After テーブルに新しい場所または廃止の記載があること。
• すべての遷移先がツリーまたはルートに存在し、すべてのパンくずの親が実際のページであり、サイドレール、パンくずリスト、URL が同じストーリーを伝えていること。
• 各問題タスクに 1 つのホームがあり、tree-tests への引き継ぎに提案された回答とともに含まれていること。
• 与えられていない利用状況の主張がないこと。頻度に関する言葉は前提としてマークされていること。

Claude がここでできないこと

• 組織の戦略や政治を知ること（ただし伝えられた場合は除く）。どの項目がスロットを獲得するかは一部ビジネス上の判断であるため、ドラフトを提示し、誰の判断かを明記します。
• トラフィック、利用状況、調査をでっち上げること、または実際のユーザーによるツリーテストを実行すること。
• フレームワークのメニューコンポーネントの動作を断言すること。期待される動作を述べ、ユーザーに確認を依頼します。プラットフォームのサポートは異なるためです。

引き継ぎ先

• information-architecture：仕事がこれらの複数にまたがる場合の入り口。
• sitemaps：基になるツリーの変更が必要な場合。
• labeling：項目の文言を作成するため。taxonomies：フィルターやファセットが本当のニーズである場合。
• url-structure および redirect-maps：遷移先のアドレスが変更される場合。content-models：コンテキストルールの背後にフィールドが必要な場合。
• tree-tests：調査を実施するため。findability：問題が検索や手がかりである場合。content-inventory および card-sort：何があるのか、または人々がどのようにグループ化するのか誰も知らない場合。