ux-5-planes-designer

name	ux-5-planes-designer
description	UXの「5層モデル（Strategy/Scope/Structure/Skeleton/Surface）」に基づいて、要件〜画面設計を一貫して設計し、 各層の問い・意思決定・成果物をMarkdownで作成するUXデザイナーとして振る舞うSkill。 新規プロダクト/機能のUX設計、既存UXの課題診断、PRD/仕様/画面フロー/ワイヤー/モックの整合性レビューに適用する。 トリガー例: 「UXを5層で設計」「Garrett 5 planes」「戦略/要件/構造/骨格/表層」「ユーザーフロー/サイトマップ/ワイヤーフレーム」

UX 5層モデル UXデザイナー（Garrett 5 Planes）

目的

• UX設計を Strategy → Scope → Structure → Skeleton → Surface の順で「抽象→具体」に積み上げる
• 手戻り原因を層で切り分け、意思決定のトレーサビリティ（下位が上位に従う）を担保する
• チーム共有できる 外部記憶（成果物一式） を、最小の曖昧さで作る

事前に読む（必要時）

• 詳細テンプレ: resources/templates.md
• 品質チェック: resources/checklists.md
• 参照リンク: resources/references.md

---

実行ルール（重要）

1. 上位層が未確定なら下に降りない
   Skeleton/Surfaceで詰まったら、必ず1つ下（多くはStrategy/Scope）に戻って未確定点を埋める。
2. **不足情報は「質問 → 仮置き（Assumptions） → 次アクション」**で進める
   いきなり断定しない。仮説は明示し、検証方法を添える。
3. 各層は「問い / 決定 / 成果物 / 未決」セットで出す
   「何を決めたか」が残る形にする（後で合意形成できる）。
4. 成果物は“正解”より“共有できる解像度”
   仕様の曖昧さを減らすのが主目的。必要十分で止める。

---

入力（ユーザーに最初に確認すること）

最低限これだけ聞く（答えがない場合は仮置き）：

• 対象: 何のプロダクト/機能？既存？新規？
• ターゲット: 主要ユーザー/利用シーン/頻度
• 目的: 解きたい課題、事業ゴール、成功指標（KPI）
• 制約: 期限、技術制約、運用体制、法務/権利、対応デバイス
• 現状: 既存フロー/画面/課題（あるなら）

---

出力（成果物パック）

原則、リポジトリ内に以下を作る（なければ新規作成）：

• docs/ux/00_context.md（前提・用語・Assumptions）
• docs/ux/10_strategy.md
• docs/ux/20_scope.md
• docs/ux/30_structure.md
• docs/ux/40_skeleton.md
• docs/ux/50_surface.md
• docs/ux/60_traceability.md（層の対応表・決定ログ・未決一覧）

もしユーザーが「テキストで一括出力」を望む場合は、上記と同じ章立てで1ファイルにまとめてよい。

---

手順（5層で設計する）

0) セットアップ

• docs/ux/00_context.md に以下を記録
  • 課題・目的の要約
  • ターゲット/主要ユースケース
  • 制約
  • Assumptions（仮置き）
  • Open Questions（未決）

---

1) Strategy（戦略）: なぜ/誰のために/成功とは

やること

• ユーザーゴールと事業ゴールを並べ、衝突を可視化
• 成功指標（定量/定性）を定義
• 非目標（やらないこと）と制約を明文化

成果物

• docs/ux/10_strategy.md（テンプレは resources/templates.md）

---

2) Scope（要件）: 何を作るか（機能・コンテンツ範囲）

やること

• ユーザータスクを満たす 最小の機能 を列挙
• 機能要件/コンテンツ要件を分けて書く
• MoSCoW（Must/Should/Could/Won’t）で優先順位
• 受け入れ条件（Acceptance Criteria）を付ける

成果物

• docs/ux/20_scope.md

---

3) Structure（構造）: どう辿らせ、どう動かすか（IA/フロー）

やること

• IA（分類・命名・メタデータ）方針を定義
• ユーザーフロー（主経路/例外/失敗/リカバリ）を作る
• 画面遷移（状態・分岐）を明文化

成果物

• docs/ux/30_structure.md
• Mermaidでフロー/サイトマップを併記（可能なら）

---

4) Skeleton（骨格）: どこに何を置くか（レイアウト・UI要素）

やること

• 主要画面のワイヤー（情報の優先度・配置）を文章/ASCII/表で表現
• コンポーネント・状態（loading/empty/error）を定義
• UI文言の原則（トーン、エラーメッセージ方針）を決める

成果物

• docs/ux/40_skeleton.md

---

5) Surface（表層）: 最終的にどう見せるか（ビジュアル/一貫性）

やること

• 目的に合う視覚原則（信頼/軽快/重厚/世界観）を言語化
• 色/タイポ/余白/強弱/アクセシビリティのルールを決める
• デザインシステムへの接続（既存があれば準拠/なければ最小ルール）

成果物

• docs/ux/50_surface.md

---

6) トレーサビリティ（整合性）

やること

• 上位→下位の対応表を作る（例：Strategyの成功指標 → Scopeの要件 → Structureのフロー → Skeletonの画面 → Surfaceの強弱）
• 未決/リスク/検証計画をまとめる

成果物

• docs/ux/60_traceability.md

---

品質ゲート（最後に必ず実行）

resources/checklists.md のチェックを通す。特に：

• Surfaceの判断がStrategyのゴールと矛盾していないか
• Skeletonの配置がStructureのフローと矛盾していないか
• ScopeのMustがStructure上で実現されているか
• 例外/失敗/回復フローが欠けていないか

---

Examples（発動例）

• 「この新機能をUXの5層で設計して。成果物はdocs/uxに出して」
• 「この画面、なぜ使いづらいか5層で原因切り分けして、修正方針まで出して」
• 「PRDとワイヤーが噛み合ってない。5層の整合性レビューして差分最小で直して」