情報アーキテクチャ は何をしますか？
情報アーキテクチャとは、システムのコンテンツと機能がどのようにグループ化され、ラベル付けされ、接続されるかであり、人々が必要なものを見つけ、何ができるかを理解できるようにするためのものです。すべての決定は、次のテストに合格するかどうかで判断されます。その構造は、目の前の人が、指示されなくても、迅速かつ適切な選択をするのに役立つか？
これは他のすべての上流に位置します。間違った構造は、居場所のないコンテンツ、余計なナビゲーションを発明しなければならないデザイン、URLが変更される検索、そして回避策の山と化すCMSに負担をかけます。
このスキルは、作業の範囲を定め、それに適用されるルールを保持します。作業自体は以下のスキルに含まれます。
1. 作業の選択
ほとんどのリクエストはツールキットの一部だけを必要とし、すべてを必要とするわけではありません。何を成果物として提供するかを明確にし、相手が何を得られるかを理解できるようにします。
| 作業 | 順に実行するもの |
|---|---|
| 既存コンテンツの再編成 | content-inventory, card-sort または taxonomies, sitemaps, アドレスが変わる場合は url-structure, tree-tests, redirect-maps |
| 新しいサイト、アプリエリア、セクション | sitemaps, navigation, url-structure, content-models |
| メニュー、ナビ、アプリスイッチャーの再考 | navigation, labeling, tree-tests |
| タグとカテゴリ | taxonomies |
| 機能していない名前 | labeling |
| 「ユーザーがXを見つけられない」 | findability、次に診断結果が指し示すスキル |
| サイトの移行または再構築 | sitemaps, navigation, url-structure, content-models, redirect-maps |
| 構築前の構造確認 | tree-tests |
| AI機能または製品 | ここでのセクション5、次に findability |
サイトマップだけでは飾りに過ぎません。サイト構築の場合、フルセットはサイトマップ、URLルール、ナビゲーション仕様、コンテンツモデル、そして再構築の場合はリダイレクトマップです。他の4つがなければ、誰もそれをもとに構築することはできません。
関連するスキルが利用できない場合は、以下のルールを使用してここでその部分を実行し、その旨を明記します。
2. 枠組みを設定し、現状をマッピングする
どのルートを取るにせよ、まず誰がこれを使用するのか、彼らが何をしようとしているのか、現在と2年後のコンテンツ量、ビジネスがそこから何を望んでいるのか、そして成功をどのように測定するのかを確定します。何かを変更する前に、それらの測定基準の今日の数値を記録しておかないと、後で比較する対象がなくなります。
次に、現在の状況を構築します。ホームページだけから再設計してはいけません。
- コードベース内の場合: ルート、ナビゲーションコンポーネント、
sitemap.xml、CMSスキーマ、カテゴリまたはタグテーブルを読みます。セクションごとにアイテム数をカウントします。空のセクションと過負荷のセクションは、それ自体が発見事項です。 - コンテンツフォルダ内の場合: 一度に1つのアイテムではなく、コーパス全体を調査します。それが何であり、誰にサービスを提供しているように見えるかを伝え、間違った解釈に基づいて構築する前に、相手に訂正させます。
- データベースまたはCMS内のコンテンツの場合: まずタイトル、タイプ、タグ、日付をエクスポートします。
- 非常に大規模なセットの場合: タイプごとに調査し、各タイプ内でサンプリングします。何をサンプリングしたかを明記し、サンプルを全数調査と誤認しないようにします。
また、人だけが知っている情報も求めます。つまり、オーディエンスとそのトップタスク、組織の方向性、アナリティクス、サイト検索ログ、サポートが答え続けている質問です。
3. 作業全体にわたるルール
- 組織図ではなく、人々が何をしようとしているかで構造化する。 「開発者向け、API」は「会社概要、エンジニアリング、API」よりも優れています。
- 各アイテムに1つの正規の居場所を与える。 他の場所からリンクすることはできますが、1つの場所に存在します。
- クリック数よりも手がかりを重視する。 各ステップが明確に目標の匂いをさせる場合、人々はさらにクリックします。3クリックルールは神話です。行き止まりと曖昧なラベルが真のコストです。
- 10倍のコンテンツを見越して設計する。 カテゴリが成長する場合は、今のうちにそのための設計をします。
- 複数のアクセス経路を提供する。 ブラウズ、検索、フィルター、関連リンク、パンくずリスト。
- 決定が行われる場所に手がかりを配置する。 良い手がかりは、人がすでに持っている質問に、選択する瞬間に、すでに見ている場所で、静かにそして安価に答えます。
- 次のより大きなコンテキストのために設計する。 ページはセクション内に、セクションはサイト内に、サイトはビジネス内に存在します。
4. AIとしてIAに取り組む
得意なこと: コーパス全体を数分で読み、代替スキームを提案し、タクソノミを何千ものアイテムに一貫して適用し、類似した用語を見つけ、どのカテゴリにも当てはまらないアイテムを特定します。
できないこと: 実際のユーザーによるカードソートやツリーテストの実行、または組織の戦略や政治を（指示されなければ）把握すること。したがって：
- 提案するが、決定はしない。 2～3のスキームとそれぞれのトレードオフを示し、1つを推奨し、その理由を述べます。単一の答えは決定を隠してしまいます。
- まずオーディエンスと方向性を得る。 誰のためのものか、製品の方向性がどこにあるのかを伝えられていない場合は、質問するか、または冒頭で自分の仮定を述べます。
- 依頼されたものはすべて配置する。 適合しないアイテムには、最も適していないホームとフラグを与え、それを移動、統合、または廃止する根拠は別の推奨事項とします。
- 要求されたアーティファクトはすべて提供する。 存在すべきでないと考える場合でも、とにかく提供し、別途その根拠を述べます。
- 調査データを捏造しない。 でっち上げの参加者数、成功率、チケット数、引用、頻度はありません。「毎時間使用されている」という事実としての記述はカウントされます。「おそらく」と言い、それを仮定としてリストします。
- プラットフォームの動作を推測しない。 ホストやCMSで何ができるかは様々です。期待することを述べ、相手に確認するよう伝えます。
- コンテンツを保護する。 コンテンツ、メタデータ、ルート、リダイレクトをその場で編集する前に、作業がバージョン管理下にあるか、バックアップされていることを確認します。
5. AI製品とエージェントコンテキストのためのIA
製品にAIを追加する前に、実際に何が障害になっているかを調べます。人々がシステムの仕組みを理解できず、カテゴリを区別できず、同じことを繰り返し質問しなければならない場合、より明確な構造、より優れたラベル、または適切に配置された手がかりが、通常はチャットボックスよりも安価に問題を解決します。ボタンとメニューには2つの役割があります。人々が行動できるようにすることと、人々にシステムが何をできるかを示すことです。オープンエンドのチャットは前者をゆっくりと行い、後者はまったく行いません。チャットはタスクが本当にオープンエンドである場合に使用し、それ以外の場合は構造化されたインターフェースの背後でAIを使用します。
エージェントのためのコンテキストもIAの問題です。モデルに適切な情報を適切なタイミングで提供します。つまり、より深いファイルを指し示す短いエントリファイル、各事実に1つの正規の居場所、一貫した名前、そしてタスクに不要なものはロードしないことです。
6. 作業が複数のスキルにまたがる場合
特に別のものを求められない限り、以下の内容を含む1つのドキュメントを返します。
- サマリー: 2～3文での推奨事項と、その主な理由。
- 現状: 現在のツリーとその中の問題点（カウント付き）。
- オプション: 2～3のスキーム。それぞれが誰にサービスを提供するか、コスト、およびどこに負担がかかるか。
- 提案: 推奨されるツリー（各ノードのテンプレートタイプを含む）、次にラベルとナビゲーション仕様、該当する場合はURLルールとコンテンツモデル。
- 移行: 何かが移動する場合の、古いものから新しいものへのマッピングと再タグ付けの注意事項。
- 前提条件と未解決の質問: 推測したすべての事項。
- 検証方法: ツリーテストのタスク（正解と目標を含む）、または最初に実行するカードソート。
作業に合わせて規模を調整します。 推奨事項を先頭に置き、各セクションは使用可能でありながら可能な限り短くし、長い表は最後に回します。ドキュメントが長いほど、より徹底しているとは限りません。
引き渡す前に、内容が自己矛盾していないか確認します。 合計を配置表と照合し、記載したすべてのルールを自分が書いた表と照合し、パス長に関する主張をツリーでトレースし、出荷可能なファイルが元の計画のすべての行を実装していることを確認します。
情報アーキテクチャをレビューするには（自分のものでも他人のものでも）、references/rubric.md で採点します。
7. 見かけたら名前を付けるべきパターン
- 組織図ナビゲーション: 部門にちなんで名付けられたセクション。
- 競合する2つのタクソノミ: サイドレール、パンくずリスト、URLがそれぞれ異なることを示しています。
- すべてが1つの傘の下に: すべてのセクションが
/services/<thing>、URL付きのジャンクドロワー。 - プレースホルダーセクション: 出荷される「近日公開」ページ。構築するか、除外します。
- 構造の代わりのチャットボックス: 明確なオプションがあれば、より速く質問に答え、システムの仕組みを人々に教えることができるオープンエンドのAIインターフェース。