skills/superstone-han/dotfiles/ux-5-planes-designer

ux-5-planes-designer

SKILL.md

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層の整合性レビューして差分最小で直して」
Weekly Installs
1
First Seen
Mar 1, 2026
Installed on
amp1
cline1
opencode1
cursor1
continue1
kimi-cli1