2017年12月11日に開催されたセミナー「HCDコンピタンス知識編『情報構造の設計・概論』」で使用したスライドです。 https://www.hcdnet.org/hcd/event/entry-1130.html

1. 情報構造設計の基礎知識
伊原 ⼒也⽒（ freee株式会社）
HCDコンピタンス知識編

2. A9「情報構造の設計能力」
コンピタンス解説資料
2017/12/11
NPO法人 人間中心設計推進機構
人間中心設計専門資格認定センター 伊原 力也
1

6. 2
「A9. 情報構造の設計能力」とは
要求仕様から構造設計、デザイン仕様に至るまでのプロセスを伝えること
• どのような構造を、どういった判断根拠で組み立てたか
• 「ユーザーが理解しやすく探しやすい」をどう客観的に担保したか
• どのようなスキーム／システムとして設計したか
• その結果がユーザーにとって、ビジネスとしてどうなったか
製品やシステム、サービスの使用に際し、
ユーザーが情報を理解しやすく、
またユーザー自身が情報を探しやすくなるような構造を、
要求仕様に基づいて設計できる能力のこと
「要件と構造のあいだ、構造と骨格のあいだ」の繋がりを示すこと

7. 3
「A9. 情報構造の設計能力」の具体的な内容
 ユーザーニーズとコンテンツの属性をもとに、
構造パターンを選択し分類方針を定める
 コンテンツの内容やシステムの動作を類推できるラベリングを行う
 ラベルやキーワードに一貫性を持たせるための命名規則を定義する
 類義語の整理や、ドキュメントの属性を分析を行い、メタデータを準備する
 構造と分類に沿いナビゲーションスキームや検索システムを設計する
 マルチデバイス・マルチチャネル対応や外部システムによる情報活用を
念頭に構造化データの出力方法やAPIを設計する

8. 4
●ユーザーニーズとコンテンツの属性をもとに、
構造パターンを選択し分類方針を定める
「ユーザーニーズ」≒A8の要求仕様に沿った構造（フロー）を検討し、
組織化スキームの理解をもとに分類方針を検討する。
• どういうステップで、どのような構造や分類を設計したのか？
• 構造の選択、分類、優先順位の検討における、
A1～A4での調査結果や要求仕様に基づく解釈や判断はどうだったか？
• 抽象的な構造や分類を適切に視覚化できているか？
A8. 製品・システム・サービスの
要求仕様作成能力
A9. 情報構造の設計能力
https://u-site.jp/lecture/ux-ui より引用、改変

9. 5
適切な構造パターン選択と分類方針定義のポイント
• 理解しやすい「パターン」を活用する
• Webサイトやスマホアプリにおける典型的な構造パターン
• 階層、ファセット、Web、ハブ＆スポーク、リニア……
• ユーティリティ、ナビゲーション、タブ、没入……
• LATCHや、タスク／オーディエンス／トピック型といった分類手法
• 客観性を担保する
• 競合等のサイト／アプリ／ドキュメントの構造や分類を参考にする
• ユーザー参加型カードソーティングで、どのようなまとまりを作り、
どのような名を付けるかを検証する
図版：書籍「デザイニングWebアクセシビリティ」より引用

10. 6
プロセスやアウトプットの例
ハイレベルサイトマップサイトストラクチャ
カードソーティング
画面遷移フロー
図版：書籍「デザイニングWebアクセシビリティ」より引用

11. 7
以下も「情報構造の設計」に含まれる
• マルチデバイスエクスペリエンス設計
• 一貫性：各デバイスで同一コンテンツ／コア機能を提供する
• 連続性：複数デバイス間を渡り歩きながら目的を達成可能にする
• 補完性：複数デバイスを同時に使って補い合う機能を設計する
• クロスチャネル設計
• （テレビ視聴中に）続きはWebで／アプリで参加
• イベント会場でアプリを起動
• Web問い合わせ→コールセンターでの引き継ぎ

12. 8
ユーザー
「コンテンツの属性をもとに」
＝コンテンツとユーザーを結びつけるアプローチも重要
コンテキスト
コンテンツ
コンテンツ探索軸や
キーワードの確認
A5. ユーザー体験の構想・提案能力
A6. ユーザー要求仕様作成能力
A8. 製品・システム・サービスの
要求仕様作成能力
コンテンツの棚卸しと
属性分析

13. 9
●コンテンツの内容やシステムの動作を類推できるラベリングを行う
各機能、各画面、情報の塊（チャンク）、UI要素に対して、
ユーザーが理解や類推できるラベルを設定する。
• A1~A4の調査結果を活用しつつ、他社や業界における慣例や、
UIガイドライン等の標準的なラベリングルールも参考にする
• 検討中のラベルをユーザーに提示し、類推される内容から調整を図る
• ラベルやキーワードに一貫性を持たせるための命名規則を定義する
ラベル・類義語リスト
図版：書籍「デザイニングWebアクセシビリティ」より引用

14. 10
今日のサイト／アプリ／ドキュメントにおいては
「検索、絞込み、並び替え、索引」などはもはや前提機能である。
（シロクマ本でも「構造は常にファセットとなる」と断じている）
そのため、要求仕様から導き出すアプローチだけでなく、
「コンテンツの属性から構造を導く」アプローチも必須となる。
1. コンテンツをたな卸しする。分散を整理し統廃合も行う
2. コンテンツの属性から、探索の切り口を検討する
3. A2・A3での調査結果（特にアクセスログや、既存の検索キーワード、
インタビュー中に得られた「言い換え」など））を突き合わせる
4. ユーザーの情報の探し方に適した分類軸を検討する
5. 類義語の整理とメタデータの準備を行う
コンテンツの「探索の切り口」から構造を設計する

15. 11
アウトプットの例
ラベル・類義語リストコンテンツインベントリ
メタデータリスト
図版：書籍「デザイニングWebアクセシビリティ」より引用

16. 12
●構造と分類に沿いナビゲーションスキームや検索システムを設計する
構造・分類・ラベル・メタデータを、ユーザーの探索をゴールに向かわせる
「スキーム」や「システム」として提供するための設計を行う。
• どのようなナビゲーションパターンを組み合わせるか
• 検索の補助機能や詳細オプションをどのように提供するか
• 検索の再現率と適合率をどのようにチューニングするか
• 探索の行き詰まりを減らすためにどのようなアプローチをとるか
http://www.uxbooth.com/articles/designing-for-mobile-part-1-information-architecture/
モバイルのナビゲーションパターン 検索軸や補助機能、絞込み機能の設計
図版：書籍「デザイニングWebアクセシビリティ」より引用

17. 13
●マルチデバイス・マルチチャネル対応や外部システムによる
情報活用を念頭に、構造化データの出力方法やAPIを設計する
昨今では、以下のような「情報構造の拡張」への対応が前提とされつつある。
このような状況に対応することも「情報構造の設計」の重要な側面である。
• 構造化された情報をAPIで取得し、
多様なプラットフォーム
（Web、アプリ、サイネージ等）が
それぞれの表現形態に合った形で出力する
• APIを一部開放し、他社に
マッシュアップ／インテグレーション／
連携サービスによるレシピ化を行ってもらう
• 検索エンジン（Google等）に
構造化データを示すことによって
自サイトと検索エンジンとの境界を薄くする
ワイヤーフレームを基にしたAPIの設計書
図版：書籍「デザイニングWebアクセシビリティ」より引用