idea-to-ui-design-brief

アイデアから UI デザインブリーフへ

概要

このスキルは、アイデアのワークフローにおける Full モードの任意の段階として使用します。プロダクトやデザインの方向性を、画像生成によるコンセプト、HTML プロトタイプ、または後続の Superpowers による実装作業の指針となる、実用的な UI デザインブリーフにまとめます。

ユーザーが UI デザインを明示的に求めない限り、このスキルを Lite モードで実行しないでください。Lite モードでは、従来どおりシンプルなアイデア記録を維持してください。

UI ブリーフは、プロダクトの検討と実装をつなぐものです。早い段階でコードのアーキテクチャを決めつけずに、インターフェースの見た目や雰囲気、動作を定義します。

使用するタイミング

ユーザーが次のことを求めた場合に使用します。

• アイデアに対する UI デザインの候補を検討する。
• アイデアのワークフローに専用の UI／デザイン段階を追加する。
• アプリのスクリーンショット、ダッシュボード、ランディングページ、プロダクトの画面向けの画像生成プロンプトを作成する。
• アイデアをコーディングエージェントに渡す前に、UI ブリーフを作成する。
• スクリーンショットがある既存アプリを評価または再設計する。
• デザインドキュメントを画面ごとの UI 要件に落とし込む。

次の場合は使用しないでください。

• ユーザーが簡単な Lite モードのアイデアメモだけを求めている。
• 対象ユーザーと主要な動作を特定できるほど、アイデアがまだ明確になっていない。
• ユーザーがすぐに本番用のフロントエンドコードを求めている。UI の方向性を選んだ後に、実装スキルを使用してください。
• ユーザーが正式なトークン仕様だけを求めている。利用可能な場合は design-md を使用してください。

成果物の配置

Full モードのアイデアパッケージでは、この成果物をデザインドキュメントの後、実装計画の前に追加します。

ideas/<idea-slug>/
  README.md
  00-idea-capture.md
  01-design-doc.md
  02-ui-design-brief.md
  03-implementation-spec.md
  04-agent-build-handoff.md
  05-spec-review.md

フォールバックルール：ユーザーがこの段階を省略する場合は、従来のワークフローの番号付けと動作を維持するか、実装仕様書で UI に関する決定事項を仮定として明記してください。UI ブリーフがないことだけを理由に、ワークフローを止めないでください。

必要な入力情報

UI ブリーフを作成する前に、次の情報を収集するか、推定してください。

• プロダクトの目的と対象ユーザー。
• 主要なユーザーフロー。
• 主な画面または利用面。
• 対象プラットフォーム：Web、デスクトップ、モバイル Web、ネイティブモバイル、または複数の利用面。
• 求める雰囲気：落ち着いた、コマンドセンターのような、遊び心のある、プロフェッショナル、情報量の多い、ミニマルなど。
• ビジュアル上の制約：ブランド、既存のリポジトリ／デザインシステム、アクセシビリティ要件、ダーク／ライトモード。
• 重要な状態：空、読み込み中、エラー、成功、初回利用、継続利用。

これらの情報が不足しており、ユーザーが進行を強制していない場合は、一度に簡潔な質問を一つだけしてください。

UI ブリーフの構成

02-ui-design-brief.md を次の内容で作成します。

# <Idea Title> — UI Design Brief

## Purpose

## Product Feel

## Design Principles

## Primary Surfaces / Screens

## Screen-by-Screen Notes

## Layout / Information Architecture

## Component Inventory

## Key User Flows

## States to Design

## Visual Direction

## Accessibility and Responsiveness

## Content / Copy Notes

## Optional Image-Generation Concepts

## Selected Direction

## Open Questions

## Handoff Notes for Implementation

任意の画像生成段階

画像生成は任意です。実装の唯一の正解ではなく、コンセプトを探るものとして扱ってください。

次の場合に画像生成を使用します。

• ユーザーがビジュアルの方向性をいくつか見たい。
• デザインの好みが曖昧である。
• アプリ／ダッシュボード／ランディングページについて、コーディング前にビジュアルを検討する必要がある。
• 2～3 種類の方向性を比較すると、ワークフローに役立つ。

デフォルトでは、3 種類のコンセプトプロンプトを作成します。

1. 保守的 — 親しみやすく、リスクが低く、実装しやすい。
2. 適合性重視 — プロダクトブリーフを最も的確に解釈したもの。
3. 大胆な別案 — より個性的で、好みの境界を見極めるのに役立つ。

各プロンプトでは、次の内容を指定してください。

• プロダクトのカテゴリと対象ユーザー。
• 画面の種類とプラットフォーム。
• 情報の階層。
• 情報密度と操作性の方針。
• ビジュアルスタイルとテーマ。
• 表示してはいけないもの。
• 出力はマーケティング用画像ではなく、UI コンセプトのスクリーンショットであること。

画像生成プロンプトのテンプレート

Create a high-fidelity UI concept screenshot for <product>. Platform: <desktop web/mobile/etc>. Screen: <main dashboard/onboarding/settings/etc>. Target user: <user>. Product feel: <feel>. Layout: <key layout>. Must show: <components/data/actions>. Avoid: generic SaaS filler, fake irrelevant metrics, stock photos, excessive gradients, unreadable tiny text. Style: <visual direction>. The image should be a realistic product UI mockup suitable for turning into a design brief.

画像生成後

画像の成果物が生成された場合：

1. 各画像のパス／URL を UI ブリーフに保存するか、参照を記載します。
2. ビジョン分析または手動レビューを使って、良い点と問題点を抽出します。
3. 選んだレイアウト、コンポーネント、ビジュアルルールを Selected Direction に反映します。
4. ビルドエージェントに画像をそのまま模倣するよう求めないでください。画像をテキスト要件、コンポーネント、トークン、受け入れ基準に変換してください。

ビルド後の再デザインループ

Superpowers などのコーディングエージェントがアプリを構築した後、このスキルを再び実行して、UI を磨き込むループとして使用できます。

1. 構築したアプリのスクリーンショットを撮影します。
2. スクリーンショットを UI ブリーフおよびプロダクトデザインドキュメントと比較します。
3. UI の不足点（階層、余白、ナビゲーション、文言、状態処理、レスポンシブ対応）を特定します。
4. 必要に応じて、代替の UI コンセプトを生成します。
5. 焦点を絞った再デザインブリーフと実装タスクリストを作成します。
6. 次の制約を付けてタスクリストを Superpowers に渡します：UI のみを改善し、明示的に承認されない限りバックエンドの動作は変更しないこと。

統合ルール

• この段階は、デフォルトでは Full モード専用です。
• ワークフローを必須にしたり、柔軟性を損なったりしてはいけません。
• スキップした場合は、従来の design-doc → implementation-spec → handoff の順序で進めます。
• ユーザーがスピードを重視する場合は、短い UI / UX Notes セクションだけをデザインドキュメントに追加します。
• 画像生成を利用できない場合は、画像生成用のプロンプトを作成し、テキストのみの UI ブリーフで続行します。
• 既存のリポジトリがある場合は、新しいデザインの方向性を考案する前に、現在の UI／コンポーネントを調査します。

よくある落とし穴

1. 画像を仕様書にしてしまう。 画像は参考資料です。正式な情報源は、文章で書かれた UI ブリーフと実装時の引き継ぎ資料です。
2. Lite モードを複雑にしすぎる。 要望がない限り、簡単なアイデアの記録にこの段階を追加しないでください。
3. ありきたりなダッシュボードの粗悪な仕上がり。 プロダクトが実際に必要としない限り、架空の指標、無関係なグラフ、装飾的なカードは避けてください。
4. 状態を考慮しない。 空の状態、読み込み中、エラー、成功、初回起動、モバイルの各状態は、ビルドの品質に関わります。
5. 成果物の番号付けを崩す。 この段階をパッケージに追加する場合は、README の成果物一覧を更新し、それ以降の段階番号も一貫性を保って変更してください。
6. 専有のデザインを模倣する。 特定のスタイル原則を取り入れてください。第三者の特徴的な UI をそのまま複製しないでください。

検証チェックリスト

• ワークフローが Full モードであるか、ユーザーが UI デザインを明示的にリクエストしている。
• 画面レベルで UI を決定できる程度に、プロダクト／デザインの方向性が明確である。
• この段階を実行した場合、02-ui-design-brief.md が存在する。
• 画像生成をスキップした場合でも、任意の画像生成用プロンプトがブリーフに保存されている。
• 画像を生成した場合は、それらを参考資料として扱い、テキストによる要件に落とし込んでいる。
• 実装時の引き継ぎ資料で、選択した UI の方向性を参照しているか、UI が仮定であることを明記している。
• この段階をスキップした場合でも、従来のワークフローが滞りなく続行される。