majiayu000 iOS Information Architecture & Navigation Design
iOSアプリの情報設計（IA）と画面遷移を、Apple HIGの原則に基づいて設計するスキル。
ミッション
ユーザー提供のドキュメント（PRD、要件、ブランド、既存仕様）を根拠に：
- 情報階層（トップレベル〜詳細の粒度）
- 画面構成（スクリーン一覧と役割）
- 画面遷移（push/modal/tab/splitのルール）
- 例外系（ログイン、ディープリンク、復帰、空状態）
をiOSのナビゲーション原則に一致する形で設計し、未確定情報は質問で埋めて設計を前進させる。
ワークフロー
Phase 0: 事前確認（必須）
以下をユーザーに確認してから設計を開始：
1. 入力ドキュメントの確認
- 要件ドキュメント（PRD、ユーザーストーリー、機能一覧）
- コンテンツ定義（扱う情報の種類、属性、関係）
- 運用制約（権限、課金、規約、オフライン要否）
- 既存資産（現行アプリ/サイト、分析データ）
- プラットフォーム条件（iPhone/iPad、最小iOS）
2. 初期質問（Blocker解消）
最低限以下を確認：
| # | 質問 | 影響範囲 |
|---|---|---|
| 1 | 主要ユーザーは誰？ | ペルソナ、タスク優先度 |
| 2 | アプリを開いてやるTop3タスクは？ | トップレベル構造 |
| 3 | 扱う主役の情報（エンティティ）は？ | コンテンツモデル |
| 4 | 一覧→詳細で見る？作業（編集/作成）が主？ | 遷移パターン |
| 5 | トップレベルに分けるべき領域は？ | タブ/サイドバー設計 |
| 6 | ログイン必須？匿名でどこまで？ | 認証フロー |
| 7 | iPadを主要ターゲットにする？ | Split View設計 |
| 8 | 通知・外部リンクで特定画面に直接入る？ | ディープリンク |
Phase 1-7: 設計モジュール実行
各モジュールを順次実行し、成果物を生成：
| Module | 目的 | 主要成果物 |
|---|---|---|
| 0 | ドキュメント根拠化 | Evidence Map、用語集 |
| 1 | タスクモデル化 | 主要タスクTop3-7、タスク分解 |
| 2 | コンテンツモデル | エンティティ、関係、階層候補 |
| 3 | トップレベル設計 | タブ/サイドバー構成、責務定義 |
| 4 | 遷移設計 | 遷移種別ルール（push/modal） |
| 5 | 状態保持設計 | タブごとの状態保持ポリシー |
| 6 | iPad適応 | カラム割り当て、並列表示方針 |
| 7 | ディープリンク | ルーティング表、状態復元規則 |
詳細は references/modules-detail.md を参照。
Phase 8: 成果物統合
すべてのモジュール成果物を統合し、最終ドキュメントを生成。
最終成果物
A. IA成果物
- A1. コンテンツモデル - エンティティ、属性、関係（YAML形式）
- A2. 情報階層マップ - サイトマップ（Mermaid図）
- A3. 命名規則 - タブ名・画面タイトルの語彙（表形式）
B. 画面＆遷移成果物
- B1. 画面インベントリ - 画面ID、目的、主要要素、入口/出口（表形式）
- B2. 遷移ルール表 - from→to、トリガ、遷移種別、戻り方（表形式）
- B3. ユーザーフロー - 主要タスク別（Mermaid sequence図）
- B4. iPhone/iPad適応方針 - カラム構成、縮退時挙動（表形式）
C. 不確定管理
- Open Questions - 優先度、仮定、影響範囲（表形式）
テンプレート詳細は references/output-templates.md を参照。
規範資料（設計根拠）
| 資料 | 用途 |
|---|---|
| Apple HIG - Navigation | 遷移原則 |
| WWDC22「Explore navigation design for iOS」 | タブ設計、push/modal使い分け |
| WWDC22「The SwiftUI cookbook for navigation」 | NavigationStack/SplitView実装 |
主要原則は references/hig-navigation-principles.md を参照。
質問プロトコル
不足情報の分類
| 分類 | 定義 | 対応 |
|---|---|---|
| Blocker | 未回答だと構造が決まらない | 即時質問 |
| High-impact | 後で直せるが手戻り大 | 早期質問 |
| Detail | 後回し可能 | 暫定仮定で進行 |
質問形式
質問は「選択肢＋影響」を添える：
Q: トップレベルはA/Bどちらが自然ですか？
- A案: タブ3つ（Home/Search/Profile）→ シンプル、検索が独立
- B案: タブ5つ（上記+Notifications/Settings）→ 直接アクセス可、タブ多め
影響: 検索導線の置き場所、タブバーの密度
暫定仮定
返答がない場合は仮定で進め、ログに残す：
assumption:
id: A001
content: "iPadはセカンダリターゲットとしてSplit View対応"
impact: "変更時はModule 6再設計が必要"
status: unconfirmed
設計品質ゲート
トップレベル設計チェック
- タブが情報階層を反映している
- 機能重複がない
- タブ強制移動を前提にしていない
- 各タブの責務が明確
遷移設計チェック
- push/modalの使い分けが一貫
- すべての画面に「出口」が定義
- 親状態の保持方法が明確
- modalの積み重ねを抑制
iPad適応チェック
- Split View対応が構造として成立
- Compact時の縮退が自然
- カラム間の関係が明確
ディープリンクチェック
- 全ルートが定義済み
- 直リンクでも現在地が説明可能
- 戻り方が破綻しない