information-architecture-navigation

情報アーキテクチャのナビゲーション

目的

エージェントが情報を見つけ、ナビゲートし、理解しやすくできるようにします。情報アーキテクチャは、構成、ラベリング、ナビゲーション、検索、メタデータ、コンテンツ構造、経路案内で成り立つプロダクトシステムとして捉えます。ビジュアルスタイリングよりも、ユーザーのタスクと理解しやすさを優先して最適化します。

このスキルを使う場面

次の依頼をユーザーから受けた場合に、このスキルを使います。

• ナビゲーション、メニュー、パンくずリスト、タブ、サイドバー、検索、フィルター、ファセット検索、カテゴリーページ、ドキュメント構造、コンテンツハブ、設定の情報アーキテクチャ、オンボーディングフロー、プロダクトダッシュボード、または情報量の多いページの評価や再設計。
• 情報モデル、サイトマップ、タクソノミー、ラベルセット、ナビゲーションモデル、コンテンツのグループ分け、検索 UX、メタデータスキーマ、または情報アーキテクチャのスタイルガイドの作成。
• 見つけやすさ、発見のしやすさ、経路案内、コンテンツの階層、相互リンク、または検索結果の品質の改善。
• コンテンツインベントリーやプロダクトの機能セットを、使いやすい構造に変換。
• ナビゲーションのランドマーク、検索フォーム、パンくずリスト、フィルター、検索結果リスト、メニュー、タブ、コンテンツテンプレートなど、情報アーキテクチャに関連するフロントエンドコンポーネントの実装。

このスキルを使わない場面

ユーザーの依頼が次の内容だけの場合は、このスキルをメインのスキルとして使わないでください。

• ナビゲーションや見つけやすさに影響しない、ビジュアルスタイリング、ブランド表現、色、イラスト、またはモーション。
• コンテンツ構造やラベルに関係しない、説得力のあるマーケティングコピー。
• UX レベルの要件を超える、バックエンドの検索ランキングアルゴリズム、データベースのインデックス作成、または IR の調整。
• 構造、見出し、ラベル、またはナビゲーションが関係しない、純粋なコンテンツ執筆。

基本原則

1. 見つけやすさと理解しやすさを一緒に設計します。 ユーザーが情報を見つけるのに役立つ構造は、プロダクトに何が含まれているか、今どこにいるか、次に何ができるかを理解する助けにもなる必要があります。
2. ユーザー、コンテンツ、コンテキストを起点にします。 会社の組織図だけをもとに設計しないでください。ユーザーのタスク、実際のコンテンツ、ビジネス上の制約、プラットフォームの制約、ガバナンス、語彙を確認します。
3. コンテンツに複数の側面がある場合は、複数の経路を用意します。 安定した相互排他的な構造には階層を使い、ユーザーが異なる切り口から同じコンテンツにたどり着く場合は、ファセット、タグ、検索ゾーン、コンテキストリンクを使います。
4. 見えない情報アーキテクチャを明示します。 メタデータ、統制語彙、別名、検索結果の調整、リダイレクト、編集者によるおすすめ表示は、ユーザーから見えない場合でもユーザー体験を形作ります。
5. ラベルは約束として扱います。 すべてのラベルは、その先にあるコンテンツやアクションを正確に予測できる必要があります。内部用語や気の利いたブランド表現より、ユーザーになじみのある言葉を優先します。
6. ユーザーが現在地を把握できるようにします。 すべての画面で、次の問いに答えられるようにします。今どこにいるのか。ここには何があるのか。どこへ行けるのか。何が変わったのか。どうすれば戻れるのか。
7. 検索はボックスではなくシステムとして扱います。 検索には、インデックス対象のコンテンツ、クエリ入力、候補表示、スペルや同義語のサポート、検索結果の表示、ランキング・並べ替え・フィルタリング、検索結果がない場合のリカバリー、分析が含まれます。
8. コンテンツはボトムアップで構成します。 見出し、コンテンツのまとまり、メタデータ、関連リンク、コンテンツテンプレートは、検索、通知、外部リンク、ソーシャル共有からコンテンツの深い階層に直接アクセスするユーザーにも役立つ必要があります。
9. 決定事項を記録して再利用できるようにします。 情報アーキテクチャは継続的に維持する必要があります。ラベルのルール、タクソノミーのルール、メタデータフィールド、ナビゲーションの配置ルール、例外をスタイルガイドまたはデザインシステムのガイダンスに記録します。
10. アクセシビリティは見つけやすさの一部です。 セマンティック構造、見出し、ランドマーク、キーボード操作、視認できるフォーカス、読みやすいラベル、スクリーンリーダー用の名前は、仕上げではなく情報アーキテクチャの要件です。

各原則を再利用可能なカードとしてまとめたものは、references/principle-cards.md を参照してください。

デフォルトの推奨事項

ユーザーのプロダクトの状況から別の選択肢が明らかに優れている場合を除き、これらのデフォルトを使用してください。

製品の目標

まず、ユーザーの主なタスクとメンタルモデルを中心に整理し、その後でビジネス上の優先事項との整合性を取ります。

規制対象、アーカイブ、法務、または参照用のシステムで、正式なドメイン構造がユーザーの期待である場合は、この方針を変更します。

方針を変更する前に、次のように尋ねます。「この製品は主に、タスク主導型、参照・検索主導型、コマース主導型、コンプライアンス・アーカイブ主導型のどれですか？」

対象ユーザーと用語

まず、平易でなじみやすく、ユーザーを中心にしたラベルを使います。対象ユーザーがすでに使っている場合に限り、内部用語を使います。

対象ユーザーが専門家である場合、規制対象の場合、または専門分野に特化しており、初心者にとってのなじみやすさより正確さが重要な場合は、この方針を変更します。

方針を変更する前に、次のように尋ねます。「主な対象ユーザーは誰ですか。また、これらの概念について、すでにどのような用語を使っていますか？」

ナビゲーションモデル

まず、全体ナビゲーションは小規模に抑え、階層の深いセクションにはローカルナビゲーションを、関連コンテンツにはコンテキストリンクを用意します。階層が2段を超える場合は、パンくずリストを使用します。

単一目的のアプリ、階層のないマーケティングサイト、または場所のナビゲーションより進行状況のナビゲーションが重要なワークフローの場合は、この方針を変更します。

方針を変更する前に、次のように尋ねます。「ユーザーは通常、カテゴリ別に閲覧しますか、タスクを順番に進めますか、目的の項目を検索しますか、それとも多数の項目を比較・絞り込みますか？」

階層の深さ

まず、ユーザーを圧倒することなく主要な選択肢を示せるよう、幅広く浅い構成にします。カテゴリが安定していて予測可能な場合を除き、深い階層は避けます。

ドキュメント、ファイルシステム、ポリシー、カタログの分類体系など、ドメイン上自然に階層が必要な場合は、この方針を変更します。

方針を変更する前に、次のように尋ねます。「カテゴリは安定していて相互に排他的ですか。それとも、項目は自然に複数のグループに属しますか？」

コンテンツのグループ化

まず、各ビューでは、タスク、トピック、対象ユーザー、ライフサイクル、時系列、地域、形式、またはアルファベット順のうち、1つの主要な整理軸を使います。セクションが明確に分かれている場合を除き、同じメニューで複数の方式を混在させないでください。

「役割別」「タスク別」「トピック別」など、意図的に複数の入口を用意するランディングページの場合は、この方針を変更します。

方針を変更する前に、次のように尋ねます。「このユーザーにとって、今もっとも重要な入口はどれですか？」

ラベル

まず、遷移先には名詞、操作には動詞を使った簡潔なテキストラベルを使用します。主要なナビゲーションでは、アイコンとテキストを組み合わせます。

スペースが極端に限られ、アイコンが広く認知され、テスト済みで、アクセシブルな場合に限り、この方針を変更します。

方針を変更する前に、次のように尋ねます。「製品には、すでに検証済みの用語や維持すべき統制語彙がありますか？」

検索

コンテンツが大量で、変化が多く、多様である場合、またはユーザーが探すものを把握していることが多い場合は、まず検索を追加します。シンプルな検索ボックスを用意し、コンテンツの種類が異なる場合は、対象を絞った検索やフィルターを追加します。

整理が不十分であることを補うためだけに検索を追加しないでください。まずラベル、グループ化、メタデータを改善します。

検索を重視した UX を実装する前に、次のように尋ねます。「検索対象にするコンテンツは何ですか。また、別々に検索すべきコンテンツの種類はありますか？」

ファセットとフィルター

ユーザーが種類、トピック、日付、場所、対象ユーザー、ステータス、価格、形式、所有者、互換性など、安定した属性で多数の項目を絞り込む必要がある場合は、まずファセットを使用します。

項目数が少ない場合、属性データの信頼性が低い場合、またはフィルタリングによって空または意味のない組み合わせが生じる場合は、この方針を変更します。

ファセットを追加する前に、次のように尋ねます。「ユーザーは、検索結果から選ぶ際に、実際にはどの属性を使っていますか？」

メタデータと統制語彙

まず、重要度の高いフィールドには軽量な統制語彙を用意し、ユーザーがよく使う言葉に対応する別名や同義語も登録します。

コンテンツ量が少ない場合、短期間しか使われない場合、または手作業で十分に管理でき、正式な語彙管理の負担が価値を上回る場合は、この方針を変更します。

語彙を正式に整備する前に、次のように尋ねます。「公開後、用語、別名、メタデータフィールド、廃止されたラベルを誰が管理しますか？」

レスポンシブ対応とチャネル横断の動作

デバイスごとに表示や操作を調整しつつ、ウェブ、モバイル、その他のチャネルで概念的な構造を同じに保つことをデフォルトとします。

チャネルの文脈によってユーザーのタスクが変わる場合は、例外とします。たとえば、モバイルでの素早い検索とデスクトップでの一括管理では異なります。

チャネル間で情報アーキテクチャ（IA）を変更する前に、「ユーザーはすべてのプラットフォームで同じタスクを行う必要がありますか。それとも、各プラットフォームで異なる作業を行いますか？」と確認します。

アクセシビリティ

WCAGを意識したセマンティックな構造、視認できるフォーカス、キーボード操作、アクセシブルな名前、アイコンのテキストによる代替、適切な見出し順、動的な検索やフィルターの変更に関する状態の通知をデフォルトとします。

アクセシビリティが重要かどうかは尋ねないでください。法的または社内のコンプライアンス目標を明示する必要がある場合に限り、確認してください。

フロントエンドの状態

ウェブ製品では、ナビゲーション、検索クエリ、選択したフィルター、並べ替え順、ページネーションをURLで共有・復元できるようにすることをデフォルトとします。

プライバシーに配慮が必要な場合、一時的な状態の場合、またはネイティブアプリ限定のコンテキストでは、例外とします。

例外を適用する前に、「ユーザーはこのフィルターや検索の状態を共有したり、ブックマークしたり、後で同じ状態に戻ったりできる必要がありますか？」と確認します。

必須のユーザーへの質問

回答によってIAが変わる場合に限り、質問してください。質問ではデフォルトの案を推奨してください。

次のケースでは、question ツールまたは同等の手段を使用してください。

1. 目標が不明確な場合。 ユーザーが製品、機能、ユーザーのタスク、またはコンテンツ領域を提示していない場合。
2. 対象ユーザーが不明確な場合。 ラベルや分類体系が、専門家向けか一般向けかによって異なる場合。
3. ナビゲーションモデルが不明確な場合。 ユーザーが閲覧、検索、絞り込み、比較、または一連の手順の完了のどれを行うのか不明な場合。
4. コンテンツやモデルが不明確な場合。 コンテンツの種類、メタデータ、規模、ライフサイクル、または所有者を把握する必要がある場合。
5. 検索範囲が不明確な場合。 検索を追加または再設計する際に、インデックス対象のコンテンツが定義されていない場合。
6. ガバナンスが不明確な場合。 推奨内容に、分類体系、メタデータ、リダイレクト、または編集上の継続的な管理が必要な場合。
7. プラットフォームやアクセシビリティの制約がある場合。 ウェブ、ネイティブ、キオスク、音声、または支援技術のコンテキストで、実装が大幅に異なる場合。
8. レガシーの制約がある場合。 移行、既存のURL、分析、SEO、またはデザインシステムとの互換性が構造を制約する可能性がある場合。

ラベルを分かりやすくするべきか、デザインにアクセシビリティを確保すべきか、ユーザーがナビゲーションを理解できるようにすべきか、といった一般的な質問はしないでください。デフォルトを適用してください。

references/decision-prompts.md にある質問ツール対応のプロンプトを使用してください。

ワークフロー

A. 既存のIAまたはUIを評価する

次の順に確認します。

1. ユーザーの目標と入口。 ユーザーの目的、これまでの状況、想定されるアクセス経路（ホームページ、ディープリンク、検索結果、通知、広告、ブックマーク、内部ワークフロー）を特定します。
2. コンテンツの一覧とコンテンツタイプ。 主要なオブジェクト、アクション、メタデータ、状態、目に見える関係や暗黙の関係を列挙します。
3. 分類方式。 主なグループ分けの原則を特定します。分類が混在していたり、重複していたり、組織図に基づいていたりする場合は指摘します。
4. 階層と構造。 階層の深さ、幅、順序、親子関係がユーザーの期待に合っているか確認します。
5. ラベルと言葉遣い。 明確さ、一貫性、具体性、識別しやすさ、語彙の適合性を評価します。
6. ナビゲーションと現在地の把握。 グローバル、ローカル、コンテキスト、補助、プロセスの各ナビゲーションを確認します。画面が「自分はどこにいるのか、ここには何があるのか、どこへ行けるのか」に答えているか検証します。
7. 検索とコンテンツの発見。 クエリの入力、検索範囲、候補表示、検索結果、フィルター、並べ替え、ランキングの手がかり、スニペット、結果がない場合の状態、復帰経路を確認します。
8. メタデータと見えないIA。 不足しているフィールド、同義語、別名、コンテンツの管理責任者、リダイレクト、検索結果の調整、分析のニーズを特定します。
9. アクセシビリティとキーボード操作。 セマンティックなランドマーク、見出し、リンク／ボタン、フォーカス順序、メニューの動作、ARIA 名、動的な通知を確認します。
10. フロントエンドの実現可能性。 URL／状態の保持、コンポーネントの再利用、レスポンシブ動作、パフォーマンス、ローカライズ、デザインシステムとの適合性を確認します。
11. 修正の優先順位付け。 発見を妨げる問題と仕上げの改善を分けます。ユーザーのタスクを解決する最小限の構造変更を提案します。

評価結果は次の形式で出力します：指摘事項 → 根拠 → 影響 → 推奨事項 → 実装上の注記。

B. IA を作成または再設計する

次の順に進めます。

1. 製品の課題を明確にする。 主なユーザー、上位タスク、コンテンツの範囲、ビジネス目標、プラットフォーム、制約、成功の指標を特定します。
2. 必要最小限で有用な構造を選ぶ。 シンプルで安定した領域には明確な階層を優先し、コンテンツの規模やユーザー行動に応じて、ファセット、検索、コンテキストリンクを追加します。
3. コンテンツオブジェクトを定義する。 各オブジェクトタイプの名称、必須フィールド、任意のメタデータ、状態、管理責任者、関係を定めます。
4. 分類方式を選ぶ。 表示ごとにタスク／トピック／対象ユーザーなどの分類方式を選びます。異なる分類方式を混在させる場合は、別々の入口セクションを設けます。
5. 階層とナビゲーションを下書きする。 主要ナビゲーション、ローカルナビゲーション、パンくず／プロセス手順、コンテキストリンク、補助情報を作成します。
6. ラベルを下書きする。 ユーザーの語彙、一貫した文法パターン、識別しやすいラベルを使用します。一般的な別の呼び方には別名を含めます。
7. 検索／発見の仕組みを設計する。 検索対象のコンテンツ、検索範囲、クエリのサポート、フィルター／ファセット、検索結果のスニペット、並べ替え順、結果がない場合の状態を定めます。
8. ボトムアップで構造を設計する。 ページテンプレート、見出し、関連リンク、メタデータ、「次に最適な」リンク、ディープリンクで訪れるユーザー向けのコンテンツのまとまりを追加します。
9. シナリオに照らして検証する。 少なくとも3つのタスク（既知項目の検索、探索的な閲覧、誤った経路／検索結果がない場合からの復帰）を実際にたどります。
10. フロントエンドの動作を仕様化する。 セマンティックなマークアップ、URL の状態、キーボード操作、フォーカス管理、読み込み／エラー／空の状態、分析イベントを定義します。
11. ガバナンスを文書化する。 ラベル、分類体系、メタデータ、リダイレクト、検索調整の管理担当者を記載します。

設計の推奨事項は、装飾的なレイアウトではなく、構造化されたIA提案として出力します。

判断の指針

次の場合は階層を選ぶ

• コンテンツに明確な親子関係がある。
• ユーザーが目次、ポリシー、ドキュメント、ファイル、カタログのような構造を期待している。
• 各項目はほぼ一か所に属している。
• 経路そのものがユーザーの領域理解に役立つ。

ファセットを選ぶ場合

• 項目を、互いに独立した複数の側面から説明できます。
• ユーザーが属性を比較、絞り込み、組み合わせます。
• コンテンツ量が多く、フラットなリストでは役に立ちません。
• メタデータの品質を維持できます。

検索を選ぶ場合

• ユーザーが対象の名前、ID、キーワード、場所、属性を把握していることがよくあります。
• コンテンツの変化が速く、手動でのナビゲーションだけでは対応できません。
• コンテンツの集合が大きすぎる、または多様すぎて、ブラウジングだけでは対応できません。
• 検索ログを使って、ラベルや同義語、検索結果の調整を改善できます。

コンテキストに応じたナビゲーションを選ぶ場合

• ユーザーが検索や外部リンクから、階層の深いページにアクセスします。
• 完全な階層構造よりも、関連コンテンツのほうが役に立ちます。
• ワークフローに「次のステップ」、「関連項目」、「適用対象」、「詳細はこちら」へのリンクが必要です。
• コンテンツモデルで関係性を確実に表現できます。

補助的なナビゲーションを選ぶ場合

• ユーザーに概要、別のアクセス方法、または問題からの復帰手段が必要です。
• システムにロングテールのコンテンツや、複数の対象ユーザーが存在します。
• A-Z 索引、サイトマップ、ガイド、用語集、オンボーディングツアー、ウィザードによって認知負荷を軽減できます。

実践的なルール

• 各ナビゲーション領域には明確な目的が必要です。繰り返しが位置の把握やタスクの完了に役立つ場合を除き、同じリンクを複数の領域に重複して掲載しないでください。
• すべての分類階層を一度に表示しないでください。階層の深さは段階的に示してください。
• 同じ階層にあるラベルは、文法と粒度をそろえてください。
• グループを説明するカテゴリラベルを使い、マーケティング上の優先事項を示すラベルは使わないでください。
• 「リソース」、「ソリューション」、「学ぶ」、「その他」は、含まれる項目に一貫性があり、ユーザーが何が含まれるかを予測できる場合を除き、避けてください。
• 頻繁に使われ、価値の高いタスクは見つけやすいナビゲーションに配置してください。検索、フッター、汎用メニューの背後に隠さないでください。
• パンくずリストは階層内の現在位置を示すために使い、ユーザーのクリック履歴を記録するために使わないでください。
• タブは同じオブジェクトの同格のビューに使い、無関係な移動先には使わないでください。
• フィルターは検索結果を絞り込むために使い、無関係なセクション間を移動するための主要なナビゲーションには使わないでください。
• 絞り込み時には、結果件数と適用中のフィルターの概要を表示してください。
• 結果が空の場合や、検索結果がない場合は、必ず復帰手段を用意してください。
• アナリティクスは根拠として使い、唯一の判断材料にしないでください。検索ログやクリックデータを、ユーザー調査やタスク分析と組み合わせてください。
• 移行時には、廃止するラベルとリダイレクトを記録してください。

アクセシビリティとインクルージョンの要件

• セマンティックなランドマークとして、header、nav、main、aside、footer を使い、ナビゲーション領域が複数ある場合は、内容を説明する aria-label の値を指定してください。
• 見た目のサイズだけでなく、コンテンツの構造を反映した論理的な見出し階層を使ってください。
• ナビゲーションには実際のリンクを、操作には実際のボタンを使ってください。
• フォーカス状態を視認できるようにし、キーボード操作の順序を予測可能にしてください。
• メニュー、コンボボックス、タブ、アコーディオン、開閉式のナビゲーションは、期待されるキーボード操作パターンに従ってください。
• アクセシブルなテキストラベルがあり、アイコンの意味が検証されている場合を除き、主要なタスクにアイコンのみのナビゲーションを使わないでください。
• 検索入力欄には、プログラムから認識できるラベルを付けてください。適切な場合は type="search" を使ってください。
• ページを再読み込みしない場合は、適切なライブリージョンを使って、動的な検索結果の更新、フィルターの変更、読み込み、エラーを通知してください。
• ラベルや説明は、色、位置、形だけに頼らないようにしてください。
• タッチデバイスでも、読みやすいターゲットサイズと間隔を維持してください。
• ローカライズに対応してください。翻訳で崩れるラベルを避け、カテゴリの順序、アルファベット順の索引、並べ替えのロジックはロケールによって異なることを想定してください。

フロントエンドの実装ガイダンス

セマンティック構造

• 主要ナビゲーション：リンクのリストを含む <nav aria-label="Primary">。
• パンくずリスト：現在のページを aria-current="page" で示す <nav aria-label="Breadcrumb"><ol>...。
• 検索：<form role="search"> またはラベル付きの検索フォームを使用し、表示ラベルまたはアクセシブルな名前を設定します。
• 検索結果：見出し、リストのセマンティクス、リンクになった検索結果のタイトル、意味のある抜粋、メタデータ、ソース／種類の表示を使用します。
• フィルター／ファセット：グループにはフィールドセット／凡例、複数選択のファセットにはチェックボックス、排他的な選択肢にはラジオボタンを使用し、動作に応じてフィルターの適用／解除にはボタンまたはリンクを使用します。
• ページネーション：ナビゲーションランドマークを使用し、現在のページには aria-current を設定します。

レスポンシブ動作

• ブレークポイントをまたいでも、概念的なナビゲーションを維持します。
• モバイルドロワーに重要な主要タスクを隠す場合は、同等の可視な導線を用意します。
• 複雑なサイドナビゲーションでは、現在位置と検索／フィルターへのアクセスを維持しながらセクションを折りたためるようにします。
• モバイルでは、フィルターの状態を表示するか、簡単に再開できるようにします。

状態と URL

• プライバシーまたはセキュリティ上の理由で不可能な場合を除き、共有可能なウェブ状態を実現するため、検索クエリ、選択したファセット、並べ替え、ページネーション、アクティブなカテゴリを URL に含めます。
• 情報アーキテクチャの移行時には、正規 URL とリダイレクトを使用します。
• ルート名とスラッグは、安定して読みやすく、可能な限りラベルに沿ったものにします。

コンポーネント化

次の再利用可能なコンポーネントを作成します。

• 主要ナビゲーション
• セクション／ローカルナビゲーション
• パンくずリスト
• オブジェクトのサブビュー用タブ
• 検索フォーム
• 候補／オートコンプリート
• 検索結果リスト／カード
• ファセット／フィルターグループ
• アクティブなフィルターチップ
• 空の状態／検索結果なしの状態
• 関連コンテンツのモジュール
• メタデータ用スロットを備えたコンテンツテンプレート

パフォーマンスと保守性

• 巨大なナビゲーションツリーやファセットリストを、制限なく描画しないでください。仮想化、ページネーション、グループ化、長いリスト内の検索を利用します。
• 現在位置が明確に保たれる場合に限り、二次ナビゲーションを遅延読み込みします。
• 分類と語彙のデータは慎重にキャッシュし、編集更新時に無効化します。
• 検索クエリ、検索結果がないクエリ、フィルターの使用状況、上位の離脱先、行き止まりとなるナビゲーションを計測します。

品質チェックリスト

情報アーキテクチャの推奨事項を確定する前に、次の点を確認します。

• 構造が、既知の項目を探すタスク、探索的なタスク、問題から復帰するタスクをそれぞれ少なくとも1つずつサポートしている。
• 主要ナビゲーションが、社内部門だけでなくユーザーの優先事項を反映している。
• ラベルが互いに区別でき、予測可能で、一貫している。
• ユーザーのメンタルモデルが異なる場合に、複数の経路からコンテンツを見つけられる。
• 直接アクセスしたユーザーが、ホームページに移動せずに自分の位置を把握できる。
• 検索範囲、インデックス対象フィールド、検索結果の表示、検索結果がない場合の復帰方法が定義されている。
• ファセットが信頼できるメタデータを使用し、意味のない空の状態を多数生み出さない。
• アクセシビリティのセマンティクスとキーボード操作が仕様化されている。
• フロントエンドの状態、URL、レスポンシブ動作、デザインシステムの再利用が考慮されている。
• 保守の責任範囲が明確になっている。

完全なチェックリストは references/checklists.md を参照してください。

避けるべきよくある間違い

• ユーザーのタスクやコンテンツの種類を理解する前に、サイトマップを設計する。
• ホームページやメインメニューを情報アーキテクチャ全体として扱う。
• 組織図をナビゲーションにそのまま反映する。
• ブランドスローガンや社内プロジェクト名をラベルに使う。
• 分類とラベルの問題を修正する代わりに、検索を追加する。
• ユーザーが必要とする前に、高度な検索コントロールを表示する。
• トップレベルの項目や階層のレベルを増やしすぎる。
• トピック、対象者、タスク、形式、ライフサイクルのラベルを、同じ区別のないメニューに混在させる。
• ホバーのみのメニューに依存する。
• 検索結果なしや空の状態を設計しない。
• 移行時にリダイレクト、別名、非推奨の用語を忘れる。
• コンテンツテンプレート内のボトムアップ型の情報アーキテクチャを無視する。

アンチパターンの完全な一覧は references/anti-patterns.md を参照してください。

• ガバナンスなしで分類体系を作成する。

推奨事項をユーザーに説明する方法

IA の推奨事項は、タスクを中心とした表現で説明します。

• ユーザーの課題から始めます。「ユーザーは、社内の商品分類を知らなくても、価格や機能でプランを比較できる必要があります。」
• 構造上の選択を示します。「タスクを優先したメインナビゲーションと、一覧ページでのファセット検索を採用します。」
• それが役立つ理由を述べます。「特定のカテゴリ経路を強制することなく、閲覧と絞り込みの両方に対応できます。」
• トレードオフに触れます。「プランの種類、対象ユーザー、機能セットに関する信頼性の高いメタデータが必要です。」
• 実装への影響を示します。「選択したフィルターを URL に保持し、アクセシブルなチェックボックスグループとして提供します。」
• 検証方法を明らかにします。「既知の項目の検索、探索的な閲覧、結果がない場合の復帰方法をテストします。」

ユーザーのタスク、コンテンツ、制約に結び付けずに、「これはベストプラクティスです」とだけ述べるのは避けてください。