UI Design Concepts

このリポジトリで、実装前の UI 案を画像として作るための手順。 成果物は必ず docs/DESIGN/{YYMMDD}_{slug}/ の 1 フォルダにまとめる。画像数は 3 枚をデフォルトにし、ユーザー指示や検討状況に応じて増減する。prompts.md は常に残す。

Workflow

1. 要件を短く整理する。

   • 対象プロダクト、対象画面、ユーザー、主要 workflow、参考 UI、守るべきデザインシステム、言語、避ける表現を確認する。
   • 指示が不足している場合だけ、AGENTS.md、docs/PLAN、docs/DESIGN、既存 UI、README などからプロジェクト固有の制約を拾う。

2. 既存 UI の扱いを決める。

   • 既存 UI のブラッシュアップ、改善案、見た目の調整、情報設計の改善が目的なら、現在の UI のスクリーンショットを取る。
   • デザイン一新、まだ UI がない新規ページ、参考 UI だけを元にした探索では、現在 UI のスクリーンショットは不要。
   • スクリーンショットを使う場合は、残す構造、変える構造、崩してよい部分をプロンプトに明示する。
   • 新しい主要機能や操作軸を足す場合は、既存スクリーンショットへ部品を重ねるだけの案にしない。追加機能に合わせて、情報設計、操作の主従、パネル構成、余白、レスポンシブ時の逃がし方を再設計する。
   • 既存 UI を参照する目的は「現状の制約を理解すること」であり、「現状画像に注釈や矩形を足して成果物にすること」ではない。例外は、ユーザーが明示的に annotation / redline / overlay を求めた場合だけ。

3. 出力フォルダを作る。

   • 形式は docs/DESIGN/{YYMMDD}_{slug}/。
   • 例: docs/DESIGN/260615_eagle_ui_concepts/。
   • 既存フォルダがある場合は上書きせず、_v2 などの suffix を付ける。

4. 必要な場合だけ現在 UI を撮影する。

   • 既存 UI のブラッシュアップなら、生成案を作る前にスクリーンショットを取る。
   • スクリーンショットは同じ出力フォルダに current_ui.png などの名前で保存する。
   • prompts.md に参照元 URL、viewport、撮影日時を書く。

5. 方向性と枚数を決める。

   • ユーザーが枚数を指定していなければ 3 案を作る。
   • ユーザーが枚数、粒度、比較対象、モバイル/デスクトップ、状態差分などを指定した場合はそれを優先する。
   • 判断材料が少ない初回探索では 3 案を維持する。既に有力案があり細部だけ詰める場合は 1-2 案に減らしてよい。画面種別やペルソナが複数あり、比較が必要な場合は 4 案以上に増やしてよい。
   • 方向性は重複させず、同じ題材でも情報密度、ナビゲーション、選択状態、詳細表示、操作密度を変える。
   • 各案は「どこに部品を置くか」だけで差分を作らない。追加された操作が画面全体の workflow をどう変えるかを案ごとに変える。
   • 主要機能の UI 案では、選択済み、未選択、disabled / empty、狭幅時の配置を少なくともプロンプトで設計する。画像内にも自然な UI 状態として反映する。

6. 画像を生成する。

   • imagegen skill/tool を使う。
   • 1 プロンプトにつき 1 枚生成し、決めた枚数分だけ分けて実行する。
   • 生成後、画像ファイルを docs/DESIGN/{folder}/ にコピーまたは移動する。
   • ファイル名は concept_01_dense_library.png のように、番号と方向性が分かる名前にする。
   • 生成画像は実際のプロダクト UI として成立する画面にする。画像内に Concept 01、案名、説明文、矢印、囲み線、注釈ラベルなど、実アプリに存在しないレビュー用表示を入れない。
   • 既存スクリーンショットを素材に使う場合でも、最終画像は再構成された UI mockup として作る。スクリーンショット上に controls / badges / callouts を貼り付けた成果物で終わらせない。

7. prompts.md を作る。

   • 含める内容:
     • 作成日
     • 出力ファイル一覧
     • 現在 UI のスクリーンショットを使った場合は、そのファイル、URL、viewport
     • 各 concept の狙い
     • 画像生成に使ったプロンプト全文
     • 参考にした制約やデザイン前提
   • 後から再生成しやすいように、プロンプトは要約ではなく実際に使った文面を残す。

8. 検証して報告する。

   • ls -lh docs/DESIGN/{folder} で決めた枚数の画像と prompts.md があることを確認する。
   • 各生成画像を実際に開き、要件、操作の主従、可読性、参照からの意図した変更を確認する。生成成功やファイルの存在だけで完成とせず、目的を妨げる不備は修正する。
   • 最終報告ではフォルダ、各画像、prompts.md の絶対パスを示す。

Context Rules

プロンプトには、確認できた制約だけを入れる。

• Design system: 指定がある場合だけ、HeroUI Pro、Tailwind、shadcn/ui などの名前と作法を入れる。
• Theme: 指定がある場合だけ、Mouve light などのテーマ名、色調を入れる。
• Typography: 指定がある場合だけ、Noto Sans JP などのフォントを入れる。
• Product domain: 資料から確認できた業務、オブジェクト、状態、操作を画面内ラベルへ反映する。
• Existing UI: 既存 UI を改善する場合は、現在の構造を踏まえて崩す部分と残す部分を分ける。
• Feature impact: 追加機能がある場合は、その機能が既存の layout / navigation / inspector / toolbar / empty state / mobile layout に与える影響を書く。

参考 UI が指定された場合は、ブランドや見た目を丸写しせず、情報設計、密度、ナビゲーション、操作モデルだけを抽出する。

例: Eagle 風の UI 案なら、画像アセット管理ツールとして、左のコレクション/タグ、中央のサムネイルグリッド、右の inspector、上部の検索/フィルタ/表示切替を検討する。ただし、これは Eagle 指定時だけの参照パターンであり、他の UI 案に常に適用しない。