ryryo UI Design Concepts
このリポジトリで、実装前の UI 案を画像として作るための手順。
成果物は必ず docs/DESIGN/{YYMMDD}_{slug}/ の 1 フォルダにまとめる。画像数は 3 枚をデフォルトにし、ユーザー指示や検討状況に応じて増減する。prompts.md は常に残す。
Workflow
要件を短く整理する。
- 対象プロダクト、対象画面、ユーザー、主要 workflow、参考 UI、守るべきデザインシステム、言語、避ける表現を確認する。
- 指示が不足している場合だけ、
AGENTS.md、docs/PLAN、docs/DESIGN、既存 UI、README などからプロジェクト固有の制約を拾う。
既存 UI の扱いを決める。
- 既存 UI のブラッシュアップ、改善案、見た目の調整、情報設計の改善が目的なら、現在の UI のスクリーンショットを取る。
- デザイン一新、まだ UI がない新規ページ、参考 UI だけを元にした探索では、現在 UI のスクリーンショットは不要。
- スクリーンショットを使う場合は、残す構造、変える構造、崩してよい部分をプロンプトに明示する。
- 新しい主要機能や操作軸を足す場合は、既存スクリーンショットへ部品を重ねるだけの案にしない。追加機能に合わせて、情報設計、操作の主従、パネル構成、余白、レスポンシブ時の逃がし方を再設計する。
- 既存 UI を参照する目的は「現状の制約を理解すること」であり、「現状画像に注釈や矩形を足して成果物にすること」ではない。例外は、ユーザーが明示的に annotation / redline / overlay を求めた場合だけ。
出力フォルダを作る。
- 形式は
docs/DESIGN/{YYMMDD}_{slug}/。 - 例:
docs/DESIGN/260615_eagle_ui_concepts/。 - 既存フォルダがある場合は上書きせず、
_v2などの suffix を付ける。
- 形式は
必要な場合だけ現在 UI を撮影する。
- 既存 UI のブラッシュアップなら、生成案を作る前にスクリーンショットを取る。
- スクリーンショットは同じ出力フォルダに
current_ui.pngなどの名前で保存する。 prompts.mdに参照元 URL、viewport、撮影日時を書く。
方向性と枚数を決める。
- ユーザーが枚数を指定していなければ 3 案を作る。
- ユーザーが枚数、粒度、比較対象、モバイル/デスクトップ、状態差分などを指定した場合はそれを優先する。
- 判断材料が少ない初回探索では 3 案を維持する。既に有力案があり細部だけ詰める場合は 1-2 案に減らしてよい。画面種別やペルソナが複数あり、比較が必要な場合は 4 案以上に増やしてよい。
- 方向性は重複させず、同じ題材でも情報密度、ナビゲーション、選択状態、詳細表示、操作密度を変える。
- 各案は「どこに部品を置くか」だけで差分を作らない。追加された操作が画面全体の workflow をどう変えるかを案ごとに変える。
- 主要機能の UI 案では、選択済み、未選択、disabled / empty、狭幅時の配置を少なくともプロンプトで設計する。画像内にも自然な UI 状態として反映する。
画像を生成する。
imagegenskill/tool を使う。- 1 プロンプトにつき 1 枚生成し、決めた枚数分だけ分けて実行する。
- 生成後、画像ファイルを
docs/DESIGN/{folder}/にコピーまたは移動する。 - ファイル名は
concept_01_dense_library.pngのように、番号と方向性が分かる名前にする。 - 生成画像は実際のプロダクト UI として成立する画面にする。画像内に
Concept 01、案名、説明文、矢印、囲み線、注釈ラベルなど、実アプリに存在しないレビュー用表示を入れない。 - 既存スクリーンショットを素材に使う場合でも、最終画像は再構成された UI mockup として作る。スクリーンショット上に controls / badges / callouts を貼り付けた成果物で終わらせない。
prompts.mdを作る。- 含める内容:
- 作成日
- 出力ファイル一覧
- 現在 UI のスクリーンショットを使った場合は、そのファイル、URL、viewport
- 各 concept の狙い
- 画像生成に使ったプロンプト全文
- 参考にした制約やデザイン前提
- 後から再生成しやすいように、プロンプトは要約ではなく実際に使った文面を残す。
- 含める内容:
検証して報告する。
ls -lh docs/DESIGN/{folder}で決めた枚数の画像とprompts.mdがあることを確認する。- 必要なら
view_imageで画像が破損していないことを確認する。 - 最終報告ではフォルダ、各画像、
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 案に常に適用しない。