design-brief

このスキルは構造化された会話を通じてデザインブリーフを作成します。必要でなければ、ステップをスキップできます。

例となるプロンプト

• "オンボーディングフローのブリーフを書いて"
• "ビルドを始める前に設定ページを計画する必要があります"
• "マーケティングランディングページの方向性を定義するのを手伝ってください"
• "プロジェクトヘルスメトリクスを表示するダッシュボードについてブリーフを作成してください"

プロセス

1. ユーザーに対して、構築したいもの、それが誰のためのものなのか、すでに持っている制約やアイデアについて詳細な説明を求めます。

2. 既存のコードベースを探索して現在の状態を理解します。以下の項目について具体的にスキャンします。

   • CSS 変数 / トークン: tokens.css、variables.css、theme.css という名前のファイル、またはカスタムプロパティを持つ :root 宣言
   • Tailwind 設定: tailwind.config.js または tailwind.config.ts、theme.extend のカスタム値をチェック
   • UI フレームワークテーマ: Material UI の createTheme、Chakra の extendTheme、shadcn の globals.css と components.json
   • コンポーネントディレクトリ: components/、ui/、shared/ など、再利用可能な UI パーツを含むフォルダ
   • Storybook: .storybook/ ディレクトリまたはドキュメント化されたコンポーネントライブラリを示す *.stories.* ファイル
   • デザイントークンファイル: JSON トークンファイル (Style Dictionary 形式、Figma トークンエクスポート)
   • package.json の UI 依存関係: tailwindcss、@mui/material、@chakra-ui/react、@radix-ui、lucide-react、framer-motion など
   • フォント読み込み: HTML の Google Fonts リンク、@font-face 宣言、CSS/設定でのフォントインポート
   • 既存ページ/レイアウト: ルートファイル、レイアウトコンポーネント、確立されたパターンを示すページテンプレート
   • コンポーネントが存在する場合は、それを開始時の語彙として扱います。ブリーフは置き換えるのではなく拡張すべきです。

3. ユーザーにデザインのあらゆる側面について徹底的にインタビューし、共通の理解に達するまで進めます。デザインツリーの各分岐を歩き、依存関係を 1 つずつ解決していきます。各質問に対して、推奨される答えを提供します。

   最低限、以下をカバーしてください。

   • プライマリユーザーは誰で、彼らの JTBD は何で、何を達成しようとしていますか？
   • このインターフェースの成功とは何ですか？
   • 感情的なトーンは？ (落ち着いた、緊急、遊び心のある、権威的、温かい、臨床的)
   • このデザインはどの既存製品、サイト、またはスタイルに似ているべきですか？どんなものではないべきですか？
   • 厳しい制約は何ですか？ (デバイス、アクセシビリティ要件、パフォーマンスバジェット、ブランドガイドライン)
   • このインターフェースはどのようなコンテンツを含みますか？プレースホルダーと実データはどう区別されていますか？

4. 完全な理解を得たら、以下のテンプレートを使用してブリーフを作成します。

ファイル出力

ブリーフを .design/<feature-slug>/DESIGN_BRIEF.md に保存します。ここで <feature-slug> は、設計中の機能またはページから派生した短い小文字ハイフン区切りの名前です (例: onboarding-flow、settings-page、project-dashboard)。

このフォルダ構造により、異なる機能に対して設計フローを複数回実行しても、以前の作業が上書きされません。その後のすべてのスキル (information-architecture、design-tokens、brief-to-tasks、design-review) は、この同じサブフォルダから読み込み、そこに書き込みます。

例:

.design/
├── onboarding-flow/
│   └── DESIGN_BRIEF.md
└── settings-page/
    └── DESIGN_BRIEF.md

ブリーフテンプレート

# デザインブリーフ: [機能/ページ名]

## 問題

ユーザーが直面している問題を、ユーザーの視点から説明します。技術的ではなく、ビジネスメトリクスでもなく、人間の摩擦です。

## ソリューション

このインターフェースが問題を解決する方法を、機能リストではなくエクスペリエンスとして説明します。

## エクスペリエンス原則

最大 3 つの原則で、すべての設計決定を導きます。各原則は緊張を解決する必要があります。
例: 「事前複雑性より段階的開示」または「速度より自信」

1. [原則] -- [実践でこれが何を意味するか]
2. [原則] -- [実践でこれが何を意味するか]
3. [原則] -- [実践でこれが何を意味するか]

## 美的方向性

- **哲学**: [名前付きの哲学または説明されたトーン。/frontend-design スキルを参照してください。]
- **トーン**: [感情的なレジスター]
- **参考ポイント**: [このデザインがどのような既存製品、サイト、またはスタイルに似ているべきか]
- **参考外の例**: [このデザインがどんなものであってはいけないか]

## 既存パターン

コードベースにすでに存在し、このデザインが尊重または拡張する必要があるコンポーネント、トークン、規約。

- タイポグラフィ: [現在使用されているもの]
- 色: [現在のパレット/変数]
- 間隔: [現在のスケール]
- コンポーネント: [再利用または拡張される既存コンポーネント]

## コンポーネントインベントリ

この機能が必要とする UI コンポーネントのリスト。各コンポーネントについて、すでに存在するか、変更が必要か、新規かを記載します。

| コンポーネント | ステータス         | 備考     |
| -------------- | ------------------- | -------- |
| [名前]         | 既存 / 変更 / 新規 | [詳細] |

## 主要なインタラクション

重要なインタラクションパターン。ユーザーが何をしてインターフェースがどう応答するかを説明します。状態変化、トランジション、フィードバックに焦点を当てます。

## レスポンシブ動作

レイアウトがブレークポイント全体でどのように適応するか。モバイルでは動作 (単なるサイズではなく) が変わるコンポーネントに注意してください。

## アクセシビリティ要件

このインターフェースの最小要件。コントラスト比、キーボードナビゲーション、スクリーンリーダーの考慮事項、フォーカス管理を含めます。

## 対象外

このブリーフが明示的にカバーしないもの。具体的にしてください。これにより、ビルド中のスコープクリープを防ぎます。