mcpField
U
ux-information-architecture-audit

ux-information-architecture-audit

github.com/uxcel-labデザイン・UI36111 回インストール17 週間前に更新
リポジトリ

ux-information-architecture-audit について

ux-information-architecture-auditは、サイト構造、ナビゲーション、分類体系を評価するデザインスキルです。ユーザーの探し方に照らしてラベル、階層、見つけやすさを確認し、重要度、修正案、検証に使える調査方法を提示します。

主な機能

  1. 01分類方式とユーザーのタスクとの適合確認
  2. 02階層の幅・深さ・構造タイプの評価
  3. 03ラベルの一貫性と情報の手がかりの確認
  4. 04検索・閲覧・再発見の経路の検証
  5. 05重要度別の指摘と修正案・調査方法の提示

活用シーン

  1. 01サイトマップやナビゲーション構造の監査
  2. 02ディレクトリの分類や絞り込み経路の評価
  3. 03曖昧なラベルや孤立ページの発見
  4. 04カードソートや検索ログによる判断の検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/uxcel-lab/product-skills --skill ux-information-architecture-audit

インストール後、Claude Code で/ux-information-architecture-auditを入力して読み込まれたか確認します。

詳細

情報アーキテクチャ監査スキル

このスキルがデフォルトの動作と比べて変えること

デフォルトでは、Claude はカテゴリ名をざっと見て構造を批評します。組織化スキームがユーザーの実際の探し方に合っているか、ラベルがクリック前に情報の手がかり(scent)を伝えているか、階層の広さと深さの比率がクリックの迷路を強いているか、サイトの途中にランディングしたユーザーがそもそも現在地を把握できるか、といったことをほとんど検証しません。この監査では次の 4 点を徹底します。すべての指摘は違反した IA 原則を明示すること。ラベルは手がかり(「ユーザーは行き先を予測できるか」)、一貫性、語彙の適合性について検証すること。構造は、ホームページからの閲覧経路だけでなく、それが応えるべき探索モードに対してチェックすること。そして指摘は重大度評価付きで、具体的な修正案を伴うこと — 論争のある判断を決着させるためにどの調査手法(カードソート、検索ログ分析、フリーリスティング)が有効かを含めて。

これは評価型のスキルです。サイトマップ、ナビゲーション構造、カテゴリシステム、または複数画面のフローがレビューされるたびに自動実行され、コンテンツを構造化する生成型スキル(ux-navigation、ux-menus、ux-search)の後の検証ステップとしても実行されます。

スコープの規律。 直接呼び出された場合(ユーザーがこの監査を指定した場合)、この関心事のみをレビューします — 姉妹監査を引き込まないでください。他のレンズと並んで実行されるのは、オーケストレーター(ux-design-review)または生成型スキルが docs/orchestration-policy.md の下でこれを呼び出す場合のみで、そこではティア B — 提案に位置します。明示的なスコープが常に優先されます。


フレームワーク — 何をチェックし、違反がどのようなものか

1. 組織化スキームがユーザーのタスクに合っている

スキームは、厳密なもの(アルファベット順、時系列、地理的)または主観的なもの(トピック別、タスク指向、対象読者別、メタファー、ハイブリッド)です。厳密なスキームは、ユーザーが項目の名前を知っている場合にのみ機能します。主観的なスキームはブラウジングと発見を支えます。選択は、構築が最も簡単なものではなく、上位のユーザータスクから導かれます。

指摘すべき場合: ユーザーがカテゴリで閲覧するコンテンツにアルファベット順を適用している(スパのサービスを A–Z で一覧表示するなど)。ユーザーがトピックで探すのに時系列を適用している。ユーザーがメタファーを学ぶ必要があるメタファースキーム。ナビゲーションの深い階層で多くのスキームを混在させているハイブリッド(ホームページでは問題ないが、深い階層では混乱を招く)。

  • ❌ 記事タイトルで A–Z に並べられたドキュメント。
  • ✅ ユーザータスク別にグループ化されたドキュメント(「はじめに」「請求」「API」)で、補助として A–Z インデックスを用意する。
2. 構造:広さ、深さ、種類

広く浅い方が、狭く深いよりも優れています — 余分な階層はそれぞれ強制的な推測を強いるからです。カテゴリは相互排他的であるべきです(限定的なクロスリスティングは問題ありませんが、どこにでもクロスリスティングされているなら、そのカテゴリは機能していません)。構造の種類はコンテンツに適合しなければなりません。トップダウンのブラウジングには階層、大規模で同種の集合(カタログ、ディレクトリ)にはデータベース/メタデータ、ステップバイステップのプロセスには逐次型、小規模サイトにはフラット。ハイパーテキストリンクは補助としてのみ使用し、主要な構造にしてはなりません。

指摘すべき場合: コンテンツが 4 階層以上深く埋もれている。1 つのカテゴリが項目の 80% を占め、兄弟カテゴリが 3% しかない。同じ項目がほぼどこにでもクロスリスティングされている。大規模なカタログにメタデータ/フィルタモデルがない。現在のコンテンツ量ですでにひずみが生じている構造(成長テスト:次の 50 項目はどこに行くのか?)。

  • ❌ 製品 > ソフトウェア > ツール > ユーティリティ > コンバーター > PDF(6 階層、1 経路)
  • ✅ 3 つのトップレベルカテゴリ + 同じ集合を価格、ブランド、種類で絞り込むファセットフィルタ。
3. ラベリングシステムの品質

ラベルは想定読者の語彙を使用し(専門用語を避け、メンタルモデルに一致させる —「メッセージリポジトリ」ではなく「受信トレイ」)、システムとして一貫している必要があります。つまり、スタイル、構文(動詞ベース、名詞ベース、疑問文ベースを混在させない)、粒度(「家電」が「スマートフォン」の隣に並ぶことはない)、および網羅性(「メンズシューズ」と「キッズシューズ」があって「レディースシューズ」がないと、ユーザーはシステム全体を信頼しなくなります)が統一されていることです。アイコンをラベルとして使う場合は、選択肢が少なく学習済みでない限りテキストが必要です。

問題とすべきケース: 同じ目的地が画面ごとに異なる名前で呼ばれている場合(「検索」/「ブラウズ」/「見つける」)、カテゴリ名がコンテンツについて何も語らない CTA 動詞(「探す」「発見する」「学ぶ」)になっている場合、ユーザーがスピードを求める場面での会話的なラベル(「税金を払いたい」→「税金を支払う」)、ラベルが冗長になるまで並列言語が強制されている場合、ラベルのない曖昧なアイコン。

  • ❌ ナビ: 「探す」・「発見する」・「もっと見る」
  • ✅ ナビ: 「コース」・「料金」・「ヘルプ」
4. 情報の匂い(インフォメーションセント)

ユーザーは、そのリンク先が自分の疑問に答えてくれそうかどうかを予測してリンクを選びます。すべてのリンクのラベル、要約、画像は目的地に関する約束です。弱い、あるいは誤った約束はクリックと信頼の両方を損ないます。ページには即座に文脈を示すもの —「ここで合っている」と確認できる見出しや説明 — が必要です。

問題とすべきケース: 「詳細を見る」/「ここをクリック」というリンク、リンク先ページの内容と一致しないリンクテキスト、一般的すぎるあるいは誤解を招くカテゴリ画像(「果物」に対するトマトの籠)、方向づけとなるテキストのない大きな画像だけのランディングページ、コンテンツが実際に何を扱っているかを示さない要約。

  • ❌ 「詳細を見る →」(目的地が推測できない)
  • ✅ 「漏水した蛇口の直し方 →」
5. 探索モードをまたぐ発見可能性

人はさまざまなモードで訪れます。既知アイテムの検索、探索的な探し回り、方向づけられた/半方向づけられた/方向づけられていないブラウジング、再発見、そして「自分が何を知る必要があるかわからない」という状態です。1 つのモードにしか対応しない構造は、それ以外の全員を失わせます。そのためには複数の分類パス(ブラウズ + 検索 + フィルター)、コンテンツが大規模な場合の検索、変化するニーズに対応する関連コンテンツリンク、そして人々が頻繁に再訪するため再発見のサポート(最近見たもの、履歴)が求められます。

問題とすべきケース: 大規模なコンテンツセットに対してブラウズが唯一の経路(検索がない)、欲しいものを名指しできないユーザー向けのブラウズ可能な構造のない検索のみ、探索的なユーザー向けの関連・文脈リンクがない、以前見たアイテムに戻ることを支援するものが何もない、初心者が持たないドメイン専門知識を前提としたナビゲーション(税務フォームを隠している「リソース」—「税務フォーム」と書くべき)。

  • ❌ カテゴリツリーだけでしかたどれない 5,000 商品のストア。
  • ✅ カテゴリツリー + サジェスト付き検索 + フィルター +「最近見たもの」。
6. すべてのページが玄関口

ユーザーは検索やリンクからサイトの途中に着地します。どんなページでも、自分がどこにいるかを把握し、主要エリアに到達し、復帰できる必要があります — 孤立したページや行き止まりは許されません。(それをどう描画するか — パンくずリスト、ヘッダー、ハイライトされたナビ状態 — は ux-navigation の領域です。この監査ではその能力が存在するかどうかを確認します。)

問題とすべきケース: 兄弟ページや親カテゴリへのパスがない詳細ページ、グローバルナビゲーションから切り離されたランディングページ、深いページのどこにも「ここはどこか」というシグナルがない。

  • ❌ カテゴリリンクもナビも関連アイテムもなく、Google から到達できる商品ページ。
  • ✅ パンくずリスト、カテゴリリンク、代替品を備えた同じページ — この商品が適切でない場合でも役立つ。
7. 選択肢と開示

一度に表示する選択肢は少なくし、詳細を段階的に開示します。IA は完全であっても、すべてを一度に提示すればユーザーを圧倒してしまいます。階層ツリー全体を露出するのではなく、主要なユーザータイプと主要タスクに資するリンクを優先します。

フラグを立てる条件: 60 個のリンクをグループ化せずに露出するメガメニュー、階層のあらゆるレベルが一度に表示される、主要タスクが組織の提供物すべてを網羅した A–Z の中に埋もれている。

  • ❌ 32 個の口座操作をすべて列挙したバンキングアプリのホーム。
  • ✅ 残高、振込、請求書支払いを前面に。そのほかは「すべてのサービス」の背後に。

緊張関係のメモ: 複数分類 vs. シンプルさ — 経路が多いほど多様なユーザーに役立ちますが、それぞれが表面積を増やします。経路は仮説ではなく、実際の探索モードに対してのみ追加します。一貫性 vs. 自然言語 — 自然な言い回し(「旅行ガイド」)のほうが明確な場合に、並列的なラベル(「旅行ガイドを読む」)を強制しないこと。そして相互排他性 vs. クロスリスティング — 一部の項目は正当に 2 か所に存在します。あらゆる判断にフラグを立てるのではなく、体系的 な曖昧さにフラグを立てます。


意見よりも証拠

所見が議論の余地のあるものである場合は、好みを主張するのではなく、それを決着させる方法を明示します。

  • オープンカードソート — ユーザーの自然なグループ分けと言語。カテゴリモデルの構築や疑問視のために。
  • クローズドカードソート — 既存のカテゴリが機能するかどうか。どれが紛らわしく、どれが冗長か。
  • 検索ログ分析 — ユーザーが実際に入力する語(用語の選択、長さ、専門用語 vs. 平易な言葉)。
  • フリーリスティング — ラベル候補のための低コストな語彙の引き出し。
  • コンテンツインベントリと監査 — コンテンツが何存在するか、何が冗長/古くなっているかを、その配置を判断する前に把握する。

「『リソース』の名称を変更する — クローズドカードソートで、ユーザーがその内容を予測できないことが示された」といった推奨は所見です。「別の名前にするだろう」はそうではありません。


重大度評価

各所見を 迷子コスト — ユーザーがそれに遭遇する頻度 × それがユーザーをどれだけ深刻に立ち往生させるか — によって評価します。

重大度意味
Criticalユーザーが主要なコンテンツを見つけられない、または主要タスクを完了できない(中核コンテンツが埋もれている、または誤ったラベルが付いている、支配的な探索モードに資する経路がない、行き止まりのエントリページ)
Major頻繁な方向喪失と無駄なクリック(狭く深い階層、情報の手がかりが乏しいナビゲーションラベル、一貫性のないラベル体系、大規模セットでの検索の欠如)
Minorユーザーが回復できる摩擦(二次メニューにおけるラベルの粒度の混在、弱い要約、低トラフィックセクションにおける最適でない分類体系)
Cosmetic仕上げ。これらでレポートを水増ししないこと

重複関係: 文レベルのコピーの明瞭さとトーンは ux-microcopy-audit に属します — この監査はラベルの 体系(一貫性、情報の手がかり、語彙の適合)を担います。ナビゲーションコンポーネントの配置とレンダリングは ux-navigation に属します。キーボード/スクリーンリーダーでのナビゲーション可能性は ux-accessibility-audit に属します。検索のインタラクション設計は ux-search に属します — この監査は、検索が 必要な場所に存在するか、および健全な構造によって支えられているかを確認します。


出力形式

## Information Architecture Audit — [Target]
Context: [product type · content volume · primary user tasks/seeking modes, if known]

### Critical
- [Issue] — what's wrong → fix (and the method that would settle it, if contested). (Principle)
### Major
- …
### Minor
- …
### Working well ✓
- …

**Top 3 priorities:** the highest lostness-cost fixes.

常に優先順位付けされた上位課題で締めくくります — 平坦なリストは誰の行動にもつながりません。


優れた監査の進め方

  1. まずコンテキストを確立する — コンテンツ量(50 ページ vs. 50,000 件では推奨のすべてが変わります)、主要なユーザータスク、オーディエンスのドメイン習熟度、そしてどの探索モードが支配的か。IA の価値は戦略的でもあります。構造が単に整理整頓されているだけでなく、ビジネスの主要なアクションに資するかを確認します。
  2. ホームページではなくエントリポイントから監査する — 深いページへの検索エンジン経由の訪問者として、既知項目の検索者として、そしてブラウザーとして歩いてみます。ホームページから下へ見る視点は、IA の失敗のほとんどを隠してしまいます。
  3. 実際のコストのみにフラグを立てる — ユーザーが問題なくナビゲートできる 12 ページのサイトにおける不完全な分類体系は所見ではありません。
  4. 緊張関係を尊重する — 同じレポートで、どこでどちらが優先されるかを示さずに、より多くの経路 と より多くのシンプルさを同時に要求しないこと。
  5. 修正は具体的に — 再グループ化を提案し、ラベルを書き直し、調査手法を明示します。「ナビゲーションを改善する」だけで済ませないこと。

よくある do/don't パターン

❌ しないこと✅ すること
カテゴリ名を好みで批評するラベルを、 scent、語彙の適合性、システムの一貫性の観点でテストする — そして、意見が割れる判断を決着させる方法を明示する
ホームページから下へたどる閲覧経路だけを監査する既知項目の検索、探索、ディープリンクでの入口、再発見の各経路をたどる
見た目が整った深い階層をほめる広さ/深さを確認する: 広く浅い方が優れる。主要コンテンツまでのクリック数を数える
検索を任意の付け足しとして扱う大規模な集合で検索が欠けていれば指摘する。閲覧手段がなく検索のみの場合も指摘する
「Explore」/「Discover」/「Learn more」を受け入れる行き先を予測できるラベルを求める
全員に一つの固定された分類を勧める実際の情報探索モードに合う複数の経路があるか確認する
コピーのトーンやアクセシビリティの詳細を再び導き出すux-microcopy-audit / ux-accessibility-audit に委ねる
次の50項目がどこに入るかを無視するすべての構造に成長テストを適用する
順位付けされていない課題の山を納品する迷いのコストで重大度を判定する + 上位3つの優先事項

出典レッスン (Uxcel)

コメント