Product UI/UX Design（全プロジェクト共通）

いつ使うか

状況	主に読むもの
アプリ・ダッシュボード・社内ツール・データ画面の体験・視覚の再設計	本 SKILL
LP・コーポ・サービス紹介ページ（docs/site 運用）	site-build-orchestrator + b2b-site-strategy-and-ia + site-design-planner
実装レベルの Tailwind 統制	tailwind-product-ui-conventions
マーケ向け motion / セクション	shadcn-motion-ui-brief
実装後の品質確認	review-frontend / review-app-product

本 SKILL は「プロダクト体験の設計プロセス」、サイト専用オーケストレーションは 上表のとおり分岐する。

外部知見の要点（AI 補助デザインで共通する結論）

• 分担: AI はバリエーション生成・トークン適合・コントラスト確認・下書きに強い。戦略・ブランドの機微・IA・最終責任は人間（並列hq.com / 業界記事の合致: 設計システムに「接地」させないと出力は似通う）。
• 反復: 初回プロンプト一発完結を期待しない。2〜3 サイクルで意図に寄せるのが通常。
• システム接地: トークン・コンポーネント規約・禁止パターンを 文書化してから 実装へ渡すと「もっともらしいがズレ」が減る。

詳細ヒューリスティクスは reference-heuristics.md。

---

ハードゲート（コード）

• 内部構造・ディレクトリ・状態管理の詳細は、§0 のユーザーファーストと §1〜 の体験設計の後。 フロント実装に入る親エージェントは、本 SKILL（または product-ui-ux-designer 経由の成果物）で 画面の契約が先に立っていることを確認する。
• ユーザーが「デザイン承認」「仕様OK」相当を出すまで、本 SKILL に基づく作業は 設計ドキュメントとレビューに留める（リポのルールで 計画承認 が先ならそれに従う）。
• 設計のみ Subagent に渡す場合は product-ui-ux-designer（~/.cursor/agents/product-ui-ux-designer.md）を Task に渡す。

<SUBAGENT-STOP>
親エージェントは 本 SKILL を Read したうえで、設計フェーズを product-ui-ux-designer Subagent に委譲してよい。プロンプトに必ず含める: (1) ワークスペースルート (2) 対象プロダクトの一文説明 (3) 触ってよい docs/ パス（未指定なら docs/ux-design/） (4) 競合・参照アプリがあれば URL。
サブエージェント定義の全文は貼らず、役割名 + 上記でよい。
</SUBAGENT-STOP>

---

設計フロー（この順で出力）

0. ユーザーファーストの固定（必須）

• 先に Read: user-first-product-design のチェックリストを埋め、本 SKILL の §1〜8 と矛盾がないようにする。
• 圧倒的に使いやすいか（学習・迷い・取り戻し・待機）を §1 の成功指標に必ず接続する。

1. 文脈とジョブ

• 誰が（主ペルソナ 1〜2）、どんな状況で、何を達成したいか（JTBD 1 行）。
• 成功指標（例: タスク完了時間、エラー率、理解度、NPS は任意）。
• 非目標（やりたくないこと・スコープ外）。

2. 情報の優先順位（1画面あたり）

• Primary action（1 つに絞れるか）。
• Secondary / tertiary の並べ方（視線＝重要度と一致しているか）。
• Above the fold に載せる情報の上限（詰め込みすぎない）。

3. フローとナビゲーション

• Happy path のステップ数（3 タップルールは目安、硬直させない）。
• 迷子時の脱出（パンくず、戻る、キャンセル、ホーム）。
• URL / 画面名 とユーザー心理モデルの一致。

4. 状態設計（必須）

各主要画面について表形式で定義する:

状態	ユーザーに見せるもの	システムの振る舞い
初期 / 空
読込中
部分データ
エラー（回復可能/不可）
成功

空状態に説明だけで終わらせず、次のアクションを 1 つ置く。

5. ヒューリスティック・クイックパス

reference-heuristics.md の Nielsen を、今回の画面で危うい 3 点だけ列挙し、対策を 1 行ずつ。

6. 視覚方針（「生成 UI 臭」を避ける）

以下を 実際に決める（デフォルト禁止の羅列ではなく、案件で選択）:

• タイポ: 和文を主とするなら、読みやすい日本語ウェブフォントまたはシステム UI フォント＋英字のペアリング方針。
• 色: プライマリ 1、アクセント 1、意味のある色（成功/警告/危険）のルール。装飾グラデで階層を誤魔化さない。
• 密度: 「情報ダッシュ」と「余白のある説明」のどちらを基準にするか。
• 角丸・影: 1 段階か 2 段階か。コンポーネントごとに微妙に違う角丸を禁止。

ストレステスト: 見出しが 2 行に折り返す、数値が 桁増えする、ラベルが 長い日本語でもレイアウトが破綻しないかを文章で宣言する。

7. アクセシビリティ（実装前の約束）

• キーボードで主要フローを完走できるか。
• コントラスト方針（トークンで担保するか）。
• prefers-reduced-motion の扱い（アニメ前提の UI にしない）。

8. ハンドオフ（実装者向け）

• コンポーネント粒度の目安（ページに書き散らかさない単位）。
• 既存スタック（例: shadcn / Tailwind）が決まっているなら、どの primitive を使うかの地図。
• 受け入れ条件を Given–When–Then で 3 本以上。

実装フェーズに入ったら tailwind-product-ui-conventions と test-driven-development / review-frontend を読む。

---

成果物の置き場（推奨）

作業リポの docs/ux-design/（なければ作成）:

ファイル例	内容
README.md	本 SKILL のどのフェーズまで終えたか
brief.md	§1〜3
states.md	§4
visual-direction.md	§6
acceptance.md	§8

LP/サイト専用の正本は引き続き docs/site/（site-build-orchestrator）。

---

親エージェントの戻り値

設計セッションの最後に必ず:

1. 作成・更新した docs/ のパス一覧
2. 未決事項（ユーザー決裁が必要なもの）
3. ユーザーの 次の一行（例: 「デザイン承認 と返したら実装計画へ」）

---

注意

• Figma で画面を作り切る場合は ~/.cursor/skills/figma-mcp-design-orchestrator/SKILL.md に従い、/figma-ux-spec-lead → /figma-canvas-builder。Canvas 前に §0（user-first） と本 SKILL の設計フローを終えてから渡す。
• ユーザールールや リポの .cursor/rules と矛盾する場合は、ユーザーの明示指示を最優先。